On 18/05/2025 at 01:00, Nicholas D Steeves wrote:

Pascal Hambourg <[email protected]> writes:

However it may not work with a system installed from Debian live with
Calamares which appears to set a different btrfs subvolume layout (see
#1104552). (...) so would it be desirable to add
(trivial) support for this case in d-i RC2 ?

Note: this is a one-liner patch. I am ready to open a MR.

I'm CCing Debian's Calamares maintainer, because I think this is an
upstream Calamares bug. I hypothesise that the nature of the Calamares
bug is that upstream assumes Ubuntu-style subvolume layout that we never intended to support in Debian.

Thank you, it would be good to know whether this layout comes from
Calamares upstream, the Debian package or Debian Live configuration.

In case anyone missed the following reply to that bug:

Have you been able to track down those discussions where we decided on
@rootfs?

To be honest, I am not so interested in past discussions. I am more
concerned about the current inconsistent state and interested in
aligning partman and Calamares btrfs layouts in one way or the other and
having rescue mode support both layouts in the meantime.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Pascal Hambourg <[email protected]> (2025-05-18):

On 18/05/2025 at 01:00, Nicholas D Steeves wrote:

However it may not work with a system installed from Debian live with Calamares which appears to set a different btrfs subvolume layout (see #1104552). (...) so would it be desirable to add
(trivial) support for this case in d-i RC2 ?

Note: this is a one-liner patch. I am ready to open a MR.

If that's easy to support and doesn't risk breaking anything (given the previous patch, that looks more than plausible), that looks very much OK
to me.


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgp2PQACgkQ/5FK8MKz VSCa0xAAnfm68MnnqPi4Wl4k3eQeCXpD7d3MsLZtUSEmsw1OI+fg+tRAVyDlN2Te njk+6v7F3d6dPJV1L0ph/RMLWM41wVdYTpan/nlFQCqArwM+wp7PPkBYaRQXoStH sWyh9jmAe4Bc1ly1aCVKuHu1fu1/+EhqKwzCE6ILFTxtufw6YtHMGf20LNdVHe7J kImpPGYmeCxsLSLnq/JfCYMeyf1l3NgFz4tGlUKXlVsbGmmiE5pQN3o2YP3vxsiH cNJ6VEfQxQYDZGAvCbtpJmv2lJmLwc0TuzxJF2mW+UyqMOSH6g6wbr7FPbMMJYK9 EkUZOYBpxqgGFOTHs5nCRJoRmXVpUW3pvQRL6cepDTue8/IJ7sqckN4Q/jidp6ho 6FFiGI4KH6ii+XTE76dqCFi/6NCRzHxmIr2FI6nO2K9E8vql/UD4Q3VMoYOtaeuj 3moe2Cin2vMikmKi1ZRyjoWG9A5kAWrz1Fh1f5lo/LQdhWh7uZ+N4cBuoPplzJfo lGMJf1bcInVtLMNt3xMnjXM8/VV5ebWXb37nMWBiu36QfnkTHBZw9UDKwH4SJyxx zHqJrJYEvxn69P71DqE1yIn/22rgi0EMHgiAnFkzeA66qgcgyjRgp2TI9+Levlch IZO8JmC8kKOJyWeTs4fwyQXd9gdTIKTOKKhAycQWQnYc+dC2L2Q=
=eST7
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On 18/05/2025 at 14:56, Cyril Brulebois wrote:

Pascal Hambourg <[email protected]> (2025-05-18):

On 18/05/2025 at 01:00, Nicholas D Steeves wrote:

However it may not work with a system installed from Debian live with
Calamares which appears to set a different btrfs subvolume layout (see >>>> #1104552). (...) so would it be desirable to add
(trivial) support for this case in d-i RC2 ?

Note: this is a one-liner patch. I am ready to open a MR.

If that's easy to support and doesn't risk breaking anything (given the previous patch, that looks more than plausible), that looks very much OK
to me.

MR opened:
<https://salsa.debian.org/installer-team/rescue/-/merge_requests/6>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sorry for accidentally sending from @gmail rather than @debian.org (I'm
still debugging my notmuch setup).

Pascal Hambourg <[email protected]> writes:

On 18/05/2025 at 01:00, Nicholas D Steeves wrote:

Pascal Hambourg <[email protected]> writes:

However it may not work with a system installed from Debian live with
Calamares which appears to set a different btrfs subvolume layout (see
#1104552). (...) so would it be desirable to add
(trivial) support for this case in d-i RC2 ?

Note: this is a one-liner patch. I am ready to open a MR.

I'm CCing Debian's Calamares maintainer, because I think this is an
upstream Calamares bug. I hypothesise that the nature of the Calamares
bug is that upstream assumes Ubuntu-style subvolume layout that we never
intended to support in Debian.

Thank you, it would be good to know whether this layout comes from
Calamares upstream, the Debian package or Debian Live configuration.

I cloned everything that seemed relevant, and fairly quickly searched
and scanned, and what I found was that Calamares' btrfs layout can be configured with a "mount.conf", but it sounds like only if one defaults
to btrfs. We default to ext4, so it falls back to hard-coded. As I hypothesized, upstream Calamares appears to hard-code Ubuntu-style
layout

src/modules/mount/main.py
143: btrfs_subvolumes = [dict(mountPoint="/", subvolume="/@"), dict(mountPoint="/home", subvolume="/@home")]

In case anyone missed the following reply to that bug:

Have you been able to track down those discussions where we decided on
@rootfs?

To be honest, I am not so interested in past discussions. I am more concerned about the current inconsistent state and interested in
aligning partman and Calamares btrfs layouts in one way or the other and having rescue mode support both layouts in the meantime.

TLDR: By doing this we would be supporting the Ubuntu layout becoming a
defacto bug-for-bug standard; this wastes the time and effort of
everyone who has already implemented flexible, configurable software,
and rewards supporting static "@, @home" systems to the exclusion of all
else. That's wrong, unjust, and not what Debian is supposed to do.

If the priority is the inconsistent state, lets:

1. Fix Calamares (#1104552 reassigned; MR submitted)
2. Decide if we're going to share the "@home" namespace with Ubuntu
and SUSE. If yes, and the priority is consistency, then we need to
start creating and mounting "@home" (which will sometimes already
exist).
3. Convert bugged installs to standard installs (this is easy, safe, and
revertible)


Cheers,
Nicholas

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgp68MQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYaIjD/4pdzv28wmNgNN8NQR+w7SwEykDb+jQBGE7 b6u/ATOYA1T58ZsFuhcl3AelUzXQftqVEap0cgX+GceB3ygzkPFEInqJLTY0dkyq DcnnoZHzH9sIsUi8Cl4B/ypf3F3rn4EOpmXF/b9U/2+ZrBuFQLJjD9fLZorG+0Qc Mi1RBn/P442I/zz3C9VF3FEgfndu0jEFTRQmAuquv0ZxTrJt5DXZCmu7c8eQ6jKu frRbCMabsfP9CgaUWfiOytdD5QyJf9LuSvfxTuOEA/Vm1jeH6/Y9ZApzIdtUh1d9 IY6yAPFtuWkSS4YW9C/1R6IH+44KX46Ix/j7M6gFF5DNzLr4reY6CBh7WvDOMTr0 RxxnmmXZsq9K6WhXzq3KhsqnaUrln5PJuenJ2DiWb1XW565jzyw3oUmxx0/R9wGU s/3o4mLKw5yVIKkl9Sm6e5zyapRmoZmFddTZWsde5e/99uIgRruNhGZjKE+9JGun Z3AKOGlApRXhDfx6D9KwfeUyKStZy6GNEZavcegZ76BiTDLgPRsi5JDirrq34NmO ZsftZs1NTA3xtfdAU81QojhtLCq/M5lkPxWz1d5SaZ1rT3pwGgcmINvCGNSe9w9X 8xzf5M4GqZGcWih0BGuaqVifbhltYcXFuXOp8fAEm2V+6L/4XnATn2WD3mGlm6OV +yWsc2aiVA==iOrJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/05/2025 at 16:16, Nicholas D Steeves wrote:

Pascal Hambourg <[email protected]> writes:

However it may not work with a system installed from Debian live with
Calamares which appears to set a different btrfs subvolume layout (see >>>> #1104552). (...) so would it be desirable to add
(trivial) support for this case in d-i RC2 ?

(...)>> it would be good to know whether this layout comes from

Calamares upstream, the Debian package or Debian Live configuration.

I cloned everything that seemed relevant, and fairly quickly searched
and scanned, and what I found was that Calamares' btrfs layout can be configured with a "mount.conf", but it sounds like only if one defaults
to btrfs. We default to ext4, so it falls back to hard-coded. As I hypothesized, upstream Calamares appears to hard-code Ubuntu-style
layout

src/modules/mount/main.py
143: btrfs_subvolumes = [dict(mountPoint="/", subvolume="/@"), dict(mountPoint="/home", subvolume="/@home")]

(...)

TLDR: By doing this we would be supporting the Ubuntu layout becoming a defacto bug-for-bug standard; this wastes the time and effort of
everyone who has already implemented flexible, configurable software,
and rewards supporting static "@, @home" systems to the exclusion of all else. That's wrong, unjust, and not what Debian is supposed to do.

I understand your point of view, but it is also wrong and unjust to not
support installations done with the Debian Live installer. Also I doubt
that so many people use the Debian installer rescue mode to repair
Ubuntu installations.

If the priority is the inconsistent state, lets:

IMO the priority for Trixie is to support existing installations with
rescue mode. The hard freeze period has started, and I am afraid it is
too late for deeper changes.

1. Fix Calamares (#1104552 reassigned; MR submitted)
2. Decide if we're going to share the "@home" namespace with Ubuntu
and SUSE. If yes, and the priority is consistency, then we need to
start creating and mounting "@home" (which will sometimes already
exist).

IIUC the rationale for a @home subvolume is to exclude user data from
"system" snapshots. IIRC openSUSE also creates subvolumes for /var/log
and other parts of the filesystem. If Debian wants to do the same
without colliding with other distributions subvolume namespace, it could
use "@homefs".

Also I believe this topic exceeds the installer scope and should be
discussed more widely with other Debian developers.

3. Convert bugged installs to standard installs (this is easy, safe, and
revertible)

Really ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)