Support for fsck of separate /usr

[KevinMKorb]

Apparently some (maybe all) distros that are now requiring an initramfs to provide /usr before init loads expect the initramfs to handle the fsck of /usr. In fact unlike / e2fsck will refuse to fsck a read only mounted /usr

So, essentially, anyone using this initramfs to get /usr pre-mounted can't fsck their /usr without booting from some live environment.

Personally, I would like to see e2fsprogs get modified to allow the fsck of a read only mounted /usr but they appear to have taken down their bug report/feature request link so I am asking here :(

[slashbeast]

I will try to get additional package for e2fsprogs so you can optionaly include it in initramfs

Or maybe running e2fsck from rootfs within initramfs before mounting /usr, like chroot /newroot fsck /dev/XXX. I need to think about it more.

[KevinMKorb]

I did also make a suggestion to modify e2fsck to allow for this but so far no response:
https://sourceforge.net/p/e2fsprogs/discussion/7053/thread/326cf8f9/

[slashbeast]

Hi,

Providing fsck for all the major file systems would make the initramfs by far bigger than it should be. I can accept additional lebuilds for the tools but I won't make them build by default, so user would need to adjust bootstrap config to add them. I am open to patches/pull requests.

Meanwhile allow me to close it as I won't support the fsck, unless 3rdparty provide the lebuilds for tools and possible hooks that could be dropped in contrib/ dir.

[cambell-prince]

I'm working on adding e2fsprogs support. I'm currently using v1.42.8 which builds.

Higher builds have an issue with fallocate64 not being available in uclibc. These functions were added to uclibc in this patch. So upgrading to the latest e2fsprogs will be possible when uclibc is updated.

[slashbeast]

So I migrated better-initramfs to musl now (devel branch). I will work on fsck static builds that can be added, and maybe releasing them in a basic and full binary releases later.

[ExecutorElassus]

This is a rather old thread at this point, but can you please explain how to do the initial pre-mount/fsck on separate /usr and /var with this? I have both residing inside an LVM and need to check them before remounting them as "real" root.

Cheers

[KevinMKorb]

I never found a way to modify the system as is. Since it is rare for /usr to have any issues (I haven't seen /var have this problem) I just decided to use SystemRescueCD if there is ever a problem with /usr and there hasn't been. Someday it will make me mad and I will probably just end up combing / with /usr even though I won't like it.

[ExecutorElassus]

OK, then let me ask a further question: when I boot with this initramfs, it doesn't create the /var mountpoint, and consequently the subdirectories of it on which certain services depend are not getting mounted. Is there some config I need to set up for it to work properly?

[KevinMKorb]

I don't think that has anything to do with this. If it is a mount point it needs to exist. It needs a mkdir on the root filesystem. Maybe there is a boot system out there that handles this for you but it would be news to me.

[ExecutorElassus]

hrm, odd. What might be causing services on /var to fail to start, when they start fine on my current initramfs?

[slashbeast]

the initramfs will not mount your /var prior to switching root to /newroot. If you would like it to mount it for you on initramfs level, you will need to extend the code for it in emount function and add emount /newroot/var like emount /newroot/usr already exist there.

[ExecutorElassus]

Thank you! Where do I make this change?

[KevinMKorb]

Note that doing this would cause /var to be not fsck-able like /usr is. You will find minor issues needing fsck a lot more often in /var than /usr.

[ExecutorElassus]

understood. Are you still working on static fsck that can be loaded as part of the initramfs for this purpose?

[slashbeast]

I wasn't looking much into it in a long time but it shouldn't be hard. Especially with the updated sysroot that is on devel branch. I can look into it, but I myself did not needed one in a very long time, so it has low priority, lower than adding systemd-udev as mdev replacement that actually is what I need and recently it started to be compatible with musl libc