Oops, there was also this reply: Pascal Hambourg <pas...@plouf.fr.eu.org> writes:
> On 18/04/2025 at 03:39, Nicholas D Steeves wrote: >> Pascal Hambourg <pas...@plouf.fr.eu.org> writes: >>> On 11/04/2025 at 03:21, Nicholas D Steeves wrote: >> Would you please share what you think are useful (and/or not useful) >> criteria for these heuristics? > > I am not authoritative for this in any way. Here are some observations: > - /bin, /sbin, /lib* and /usr contents may be in a separate filesystem. > - os-prober detects GNU/Linux systems with /lib/ld*.so + /boot or > /usr/lib/ld*.so and various distribution-specific files in /etc. > - rescue-mode reads /etc/fstab in order to mount separate /boot, > /boot/efi, /usr but systemd does not require it. > - rescue-mode tries to bind-mount the usual pseudo-filesystems on /dev, > /proc, /sys, /run. > > I guess a criterium may be the presence of a minimum number of standard > top-level system directories or symlinks such as /boot, /etc, /usr, > /proc, /sys, /run... Hm, yes, I agree this feels like too much complexity for rescue-mode (also, kibi NACKed it). >> Also, can you point me towards any documentation about the arcane d-i >> design? > > I do not know any other documentation than the one included in the > debian-installer binary package and <https://d-i.debian.org/doc/>. Some > d-i packages may include README files. Oh! https://d-i.debian.org/doc/ Thank you. Is there any reason why the DebConf and BOF docs that are in the source aren't published somewhere? One thing I'm looking for is a way to preselect a mount option that will disable a harmful feature in linux-6.2 and newer; it's only harmful for <=2013 era hardware. >> If you mean a custom set-default-subvolume, then this is not supporting >> "reasonably standard" Debian installations either, because it's the >> definition of overriding a default, as well as an established consensus. > > I do not see why it should not be supported. It could be convenient that > the rootfs subvolume is set as the default subvolume so that it does not > require rootflags/mount options. Yes, but it's also a footgun that introduces some complications elsewhere, and users aren't going to get away from somewhat complex fstab options for btrfs any time soon. It's bad enough that there is software in the archive that only supports one layout, and other software that only supports another (incompatible) layout. Yes, I'm open to rehashing and reevaluating the set-default-subvol feature, but can we defer that discussion to after the complexity of user-defined subvolume layout in D-I has been introduced? >>> Patch: <https://salsa.debian.org/pham/rescue/-/tree/pham/btrfs_subvol> >> >> Thanks, I've merged and updated. > > Where ? I do not see any rescue update on salsa. Sorry, my laptop battery fell out between sending the email and pushing to salsa and I lost 60sec of work. I lost the commit and .git metadata but the workspace was mostly fine (changelog had missing bits). >>> It should work with most standard Debian systems installed with d-i. >> >> There are only two standard cases, and now they're now covered. > > Do you mean pre-bullseye Debian (without @rootfs) and post-bullseye > Debian (with @rootfs) ? Yes, and that's a problem I caused. >>> PS: There is a flaw in partman-btrfs @rootfs creation. If using an >>> existing filesystem whose default subvolume is not the top level >>> subvolume, then @rootfs is created in the default subvolume instead of >>> the top level subvolume. If another @rootfs subvolume does not already >>> exist in the top level subvolume, then mounting @rootfs silently fails >>> and d-i writes target files in its own rootfs. >>> I admit that this is an edge case and probably nobody has ever hit it, >>> but the fix seems trivial: mount the top level subvolume instead of the >>> default subvolume before creating @rootfs. Patch available. >> >> Yes, there was consensus against supporting custom default-subvolumes, > > Do you have pointers ? Sorry to be terse, but search engines. To be fair, we're not disabling their use; it's a "you break it, and you get to keep the pieces" liberty. >> so I chose not to spend time supporting this foot-gun. Asamu Aoki had a >> system with the unsupported preconditions for what you're describing, >> and d-i aborted with an error as it should; however, the error was >> opaque. > > Maybe when d-i rootfs was full, or when some component (grub ?) failed > to resolve the rootfs block device ? Maybe? I'm sorry, I don't remember; it's somewhere on the BTS. >> We don't attempt to support custom default-subvolumes at this time, and >> d-i should error usefully and abort. > > IME it does not error during partitioning. But my point here is that d-i > does not need to support custom default subvolume, it is just as easy to > not rely on the default subvolume. IIRC Osamu Aoki's bug required something more, but I could be wrong (it was more than a year ago, I think). > IMO the current code in mount.d/btrfs is needlessy complicated and > fragile. It removes the subvol=* option from all btrfs mounts, not only > /, and only adds a hardcoded one for /. This is wrong because mount.d > scripts should mount filesystems with the exact same options as passed > from the generated fstab, so that if something is wrong (non-existent > subvolume) a mount failure will happen immediatly and not later during > when rebooting into the installed system. > > For all the above reasons, here is how I would rewrite it: > <https://salsa.debian.org/pham/partman-btrfs/-/tree/pham/subvol_rootfs> Agreed, and you're right. Thank you, I've been struggling with D-I for years. (of course I didn't commit pseudo-code to salsa) I believe you'll be ok with significantly reducing the maintenance burden, so I'm going to upload the simple case. If you would like to take over development of user-defined subvolume layout (or a selection of optional predefined recipes or elements) during installation, please let me know and I'll stop studying D-I and leave it to you! Honestly, I don't enjoy working on D-I, but no one else was working on btrfs integration then. Cheers, Nicholas
signature.asc
Description: PGP signature
