On Mon, Nov 30, 2020 at 6:42 AM Jorge Fábregas <jorge.fabregas@xxxxxxxxx> wrote: > > On 11/30/20 8:50 AM, Jorge Fábregas wrote: > > This was just a test on a scratch VM so no need to troublshoot it further. > > Gave it a 2nd thought prior to scratching the VM... > > It turns out I applied a bunch of updates (including the kernel). As > /boot is not part of the snapshot I took (since it's an ext4 filesystem > by default) ...the system booted with the recently installed kernel (and > not the one I had when I took the snapshot) so I had an inconsistency > there. Once I selected the previous kernel from the GRUB menu the > system booted seamless. > > I see we put /boot as a separate filesystem during installation (default > settings) but really..is it necessary these days considering GRUB > supports BTRFS? If I had /boot as a directory of the BTRFS root > subvolume, a simple snapshot of the root filesystm would suffice :( There's a bunch of reasons why it's still on ext4 and they have more to do with resources and logistics than anything else. A separate $BOOT file system is still needed when the main file system is encrypted. Fedora is unlikely to enhance Anaconda to do the GRUB setup work to support an encrypted $BOOT volume for various reasons, including i18n and a11y limitations in GRUB. The UI/UX just gets pretty ugly. Another hiccup applies on non-UEFI firmware systems, where the grubenv file is on Btrfs. I address this here: https://ask.fedoraproject.org/t/will-fedora-use-btrfs-for-boot-in-the-future/10383/4?u=chrismurphy And still another hiccup are questions surrounding the BootLoaderSpec. We're trying to follow the spec, but strictly following it has a few difficulties still but it's not clear to me yet what the "grand bargain" is going to be. Or if it's the spec itself that needs to be more flexible. And of course any time there are changes, it causes a certain amount of disruption for everyone. So...yeah. > Chris: do you have /boot as part of BTRFS? In the earlier example, yes. In the case of home and root subvolumes on Fedora (the default) while you can snapshot and rollback root as I've described, it's quite a heavy hammer. It will rollback everything: logs, journal, configuration files in etc, caches in var, VM images also in var. So the logical thing is to add some subvolumes so that it's possible to *not* snapshot some things, while still snapshotting others. The difficulty there is, the more granular you make this, the more difficult it is to keep track of without a helper program like snapper or timeshift. Another factor in all of this is whether it's desirable to have a Btrfs equivalent of the Discoverable Partition Spec. https://systemd.io/DISCOVERABLE_PARTITIONS/ So what would that look like? One suggestion is to make it xattr based, just stuff a GUID into an xattr for each subvolume. Another idea is to just have a standardized subvolume naming convention. Such a naming convention would be more flexible and self-describing. But either of these requires a design, and (ideally) expand the spec to cover this case. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
