hibernate + no separate /boot - data corruption possibility?

[Zucca]

Data corruption fear paranoia suddenly struck me:

While I was implementing function for restoring machine state from hibernation for my initramfs init script I payed close attention to in which order things are executed so that nothing touches partitions on the hard drive before the point where resuming occurs.
The I realized: I have no separate /boot. It's only a btrfs subvolume. Everything is on single btrfs filesystem except for /boot/efi (darn UEFI *shakes fist*).
Now when booting, boot manager is loaded from the EFI partition. Then it loads (efi stub) kernel and initramfs from /boot. Meaning it touches the root filesystem. See? This is the point which might do something bad. I might worry too much here. I think filesystem drivers of bootmanagers (and/or -loaders) make sure to only read from the disk.

BUT, if I were to have separate /boot which would normally stay unmounted (except when updating kernel etc), would it be a little safer when waking from hibernation?
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[eccerr0r]

Now I found that btrfs seems to do some weirdness to vfs last I recall, but what you describe seems to sound like the same problem exists if s/btrfs/ext4fs/ ... ?

Anyway, as long as the volume is mounted read only you're fine. Mounting is not the problem, modifying the disk is the problem.

I do have hibernate to swap file on ext4fs working, and seems that this would be the same problem. It works, the key being I have to be careful not to mount the ext4fs partition rw, ever.

However if btrfs compulsively modifies the disk even if you mount readonly, all bets are off... and btrfs is bad....
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Zucca]

[Hu]

As eccerr0r says, the problem is that no modifications to the mounted filesystem can be made by the pre-resume environment. The tricky part is that, for some journaling filesystems, and ext4 is definitely in this group, mount -o ro device path may, if the filesystem is unclean (as would be the case if you hibernated while the filesystem was read-write), cause the pre-resume environment to write to the device while recovering the journal. Once the recovery is done, the filesystem becomes visible as a read-only filesystem at the requested path. That journal recovery is what gets you in trouble. So the question is, if you hibernate while btrfs is mounted, does it leave the filesystem in a state that a journal replay will occur before you can resume? There are a few ways the answer could be no (which is the answer you want):

• If the filesystem is unmounted before hibernate, it should be clean; and even if it isn't, the post-resume environment should have no remembered state, and should therefore not care about any changes that were made during hibernation
• If the filesystem is mounted at hibernate time, but is mounted read-only, the kernel may (depending on filesystem, and maybe even implementation details) leave the filesystem in a "clean" state. If it does, then mounting read-only from the pre-resume environment should be fine because there is no journal to replay, so the pre-resume environment will not write anything to the device. Mounting read-write from the pre-resume environment would still be bad.
• If the pre-resume environment performs its read-only accesses in a way that never tries to replay journals, then you are fine. This could be the case if the pre-resume pre-Linux environment uses its own, read-only, reader to load the files, and never lets the Linux kernel try to access the filesystem. I think this is why resuming from a swap file works: there are tricks used to avoid mounting the containing filesystem, and instead the resume goes from direct block access. (Note: I've never read anything that explicitly says this, but based on what I know of how to configure hibernate/resume from a swap file, I think this is how it would work.)

I don't know enough about btrfs or your particular loader to know whether any of these bullet points will apply to your setup.

[Zucca]

Thank you both.

I use rEFInd to boot efistubbed Linux.
There are so many "if"s there.

• how does boot loader/manager handles reading the filesystem
  
• how does kernel read initramfs from the filesystem
  
• ... repeat all the above with different filesystem types

So, if I want the safest bet I'd need to have separate /boot and have some hook with hibernation process which makes sure /boot gets unmounted before going to hibernate.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[eccerr0r]

Dang what the hell was I thinking... kernel is on ext2/fat(EFI) boot partition that's always unmounted, swapfile is not accessed through filesystem, no problem...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Hu]

The kernel does not read the initramfs from the disk. The kernel may have an embedded initramfs that, for this purpose, we can consider to be built into the kernel and to travel with the kernel's code. This initramfs is "free" in that, once the bootloader has placed the kernel in memory, that initramfs is also loaded. The kernel may be given a separate initramfs by the bootloader. Regardless of which of these two applies, the question is what the bootloader does to read the filesystem to obtain the kernel and, if configured, to obtain the external initramfs. So while yes, you still need to answer how the bootloader handles this, at least you can avoid the question of how the kernel handles obtaining the initramfs.

[eccerr0r]

I'd be surprised if grub knew how to replay the journal, so you're fine. As long as your initramfs isn't mounting a filesystem to access a swapfile, this should be fine.

Honestly, I'm still not certain how your system is set up. I would hope luks, lvm, and the like don't do writes...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[GDH-gentoo]

As far as I can tell:

• rEFInd reads filesystems using its filesystem drivers. The BTRFS driver in this case. \EFI\refind\drivers_x64\btrfs_x64.efi is the pathname in the ESP, I think.
  
• EFI stub kernels apparently can read an initramfs from disk, specified with an initrd= parameter. rEFInd automatically constructs an initrd= parameter if the filesystem that contains the kernel has a file with a suitable name, assuming it is a corresponding initramfs.

[eccerr0r]

Ah okay, this makes more sense now. For the EFI situation, yes the EFI kernel stub can read the ESP for initramfs - But it's not using the kernel drivers, it's using the EFI drivers. EFI and the stub don't know how to deal with anything but FAT and also don't write to the ESP (unless you tell it to) so it should be fine here too. Of course additional drivers could be added but that's up to them not to muck with the disk.

Is this the ultimate issue?

Again as long as the file needed to resume isn't actually on a filesystem that requires the kernel to touch the disk to mount (versus just using EFI routines) it should be fine.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Zucca]

[eccerr0r]

Ok, I would hope that the rEFInd btrfs is as simple as possible and doesn't know how to write... or especially... REPLAY the journal if your latest initramfs happens to be in the journal... This is the reason why there's a potential for ambiguity for journalling filesystems.

But ultimately in EFI boot, EFI routines read the initramfs and the kernel, so at least the kernel does not get a chance at mounting the partition and data is safe.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Zucca]

Well. If I go paranoid enough, I'll mount ESP to /boot.
Feels so "unholy" to put Linux kernel on a FAT filesystem...
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[eccerr0r]

For my EFI machines, that's where I put my kernels, grub, and initramfs! No sense in wasting disk space...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?