Update initramfs to respect the rootflags option and prevent fsck for non-ext based filesystem

[yknivag]

I’ve been playing around with the idea of running OSMC on btrfs instead of ext4 and whilst I’ve got that working with an initramfs generated on the pi itself following this post I’d like to be able to do that with the official initramfs if I can so I have embarked on a project to rework that to be compatible.

There are a few changes that are needed for this that I think will benefit other scenarios also so I’ve submitted them here for review to be considered as a request in their own right.

1. The OSMC initramfs doesn’t currently respect the rootflags option in cmdline.txt (necessary in btrfs for setting the subvolid, but also useful in other cases to change mount options). I know that users can remount with new options in /etc/fstab but that shouldn’t be necessary the option were processed.

2. OSMC’s initramfs tries to fsck all filesystems with e3fsck without first checking the filesystem type. It’s possible I know that this can be stopped by adding nofsck to the cmdline.txt file but it would be cleaner if the check were automatic. It would have solved this post for example.

I’ve made an attempt at resolving this here and would be really grateful of some feedback on the approach before I proceed further. The commit diff shows lots of changes to the init file, but most of them are just extra tabs to indent a block of code inside a new condition (there are actually only 9 new lines added incl comments).

I have followed this post by Sam regarding testing, but I’m not entirely sure where to put the generated initramfs to test it as the default is embedded in the kernel isn’t it?

Plus I only have Rpi1 and RPi2 so I can’t test this on the Vero hardware so I don’t know if it would break anything.

Like i said, any feedback (and help with testing) would be most appreciated.

If these pre-requisites are proven to work with no problems, I’ll look at the rest of the requirements to meet my ultimate goal which is rootfstype=btrfs

[sam_nazarko]

I think the demand for non ext4 filesystems is low, but we can certainly add support.

It’s best to build the kernel as one unit (which will embed your initramfs changes) and then dpkg -i the image, instead of building an external initramfs.

[yknivag]

Hi Sam,

I have no doubt that you’re right about limited appeal, though I suspect that’s because a high percentage of users don’t care what fs is used so long as it works.

I just like btrfs because of the ability to take snapshots and online backups.

Thanls for the tip abput building the whole kernel. I’ll try that tomorrow when I get back to the pc.

[sam_nazarko]

You can use btrfs to do apt rollbacks which is nice. The only downside is I suspect this takes up a lot of disk space, so I’m not sure how practical it is.

Sam

[yknivag]

Xbian have been using btrfs for a long time (too long really as it wasn’t fully stanle when they started) and it does make their support process easier as they programatically take snapshots before running each upgrade plus they automate weekly and monthly snspshots and thus users can rollback after catastrophic errors (like apt-get upgrade) without having to reinstall.

That said the conversion process causes headaches on sd cards. I have a how-to ready to go for anyone who would like to, but I’d really rather not post it until it can be done without the user rebuilding initramfs as that doesn’t survive upgrades which is why I’ve proposed this and planning another proposal to support btrfs in the default initramfs.

[sam_nazarko]

Let me know how you get on

Rollback support would be great, but we need to see how reliable it is (/boot would need special care), and we would have to see how much space this takes

[yknivag]

Let me get the initramfs sorted first and then I’ll run it here for some time and monitor the disk space. Snapshots only record diffs so space shouldn’t be too much of a problem, especially on a reasonably sized sd card.

[yknivag]

@sam_nazarko I’m trying to build a kernel with my modified initramfs so that I can test this interim stage to ensure it doesn’t break anything but I can’t build it.

Using a spare SD card I’ve set up a fresh instance of OSMC and updated it to the newest version, then run

sudo apt-get install armv7-toolchain-osmc build-essential git
cd ~
git clone https://github.com/yknivag/osmc
cd osmc
git checkout initramfs_rootflags_fsck_cleanup # to change to my changed branch
sudo mount --bind $(pwd)/osmc /opt/osmc-tc/armv7-toolchain-osmc/mnt
sudo chroot /opt/osmc-tc/armv7-toolchain-osmc
cd /mnt/package/kernel-osmc
./build.sh rbp2

And then I get:

Building Linux kernel
sudo rm -f *.deb > /dev/null 2>&1
sudo rm -rf files-image >/dev/null 2>&1
sudo rm -rf files-headers >/dev/null 2>&1
Updating sources
Sources updated successfully
Package kernel-package is not found on the system, checking APT
Can't find the package in APT repo. It needs to be built first or you need to wait for upstream to add it

I’m now at a loss as to how to move forwards as I’ve never done this before. Any ideas why the package isn’t where it should be? Sources were updated successfully.

[sam_nazarko]

All that is needed is

cd package/kernel-osmc
make rbp2

You do not need to bind or chroot yourself.

[yknivag]

Hmm, after about 6 hrs it failed with:

gcc: error: drivers/net/ifb.mod.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
scripts/Makefile.modpost:114: recipe for target 'drivers/net/ifb.mod.o' failed
make[2]: *** [drivers/net/ifb.mod.o] Error 4
make[2]: *** Waiting for unfinished jobs....
Makefile:1116: recipe for target 'modules' failed
make[1]: *** [modules] Error 2
make[1]: Leaving directory '/mnt/package/kernel-osmc/src/linux-4.4.27'
debian/ruleset/targets/common.mk:295: recipe for target 'debian/stamp/build/kernel' failed
make: *** [debian/stamp/build/kernel] Error 2
exec make kpkg_version=13.014+nmu1 -f /usr/share/kernel-package/ruleset/minimal.mk debian DEBIAN_REVISION=7  APPEND_TO_VERSION=-7-osmc  KPKG_STEM=rbp2 

[…]

crypto/.crypto_user.o.cmd:1: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:2: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:3: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:4: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:5: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:6: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:7: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:8: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:9: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:10: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:11: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:12: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:13: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:14: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:15: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:16: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:17: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:18: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:19: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:20: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:21: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:22: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:23: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:24: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:25: warning: NUL character seen; rest of line ignored
crypto/.crypto_user.o.cmd:26: warning: NUL character seen; rest of line ignored
arch/arm/oprofile/../../../drivers/oprofile/.timer_int.o.cmd:2: *** missing separator.  Stop.
Makefile:959: recipe for target 'arch/arm/oprofile' failed
make[1]: *** [arch/arm/oprofile] Error 2
make[1]: *** Waiting for unfinished jobs....
fs/nfsd/.nfs4acl.o.cmd:1: warning: NUL character seen; rest of line ignored
fs/nfsd/.nfs4acl.o.cmd:1: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
scripts/Makefile.build:403: recipe for target 'fs/nfsd' failed
make[2]: *** [fs/nfsd] Error 2
make[2]: *** Waiting for unfinished jobs....
Makefile:959: recipe for target 'fs' failed
make[1]: *** [fs] Error 2
make[1]: Leaving directory '/mnt/package/kernel-osmc/src/linux-4.4.27'
debian/ruleset/targets/common.mk:295: recipe for target 'debian/stamp/build/kernel' failed
make: *** [debian/stamp/build/kernel] Error 2
Building kernel headers package failed
Makefile:8: recipe for target 'rbp2' failed
make: *** [rbp2] Error 1
make: Leaving directory '/mnt/package/kernel-osmc'
Makefile:8: recipe for target 'rbp2' failed
make: *** [rbp2] Error 2

Any ideas? The only changes I made were the ones documented here. Not sure how these would stop the fs/nfsd target to fail.

[sam_nazarko]

Nothing obvious

Try make clean and dos2unix on the patches you changed

Sam

[yknivag]

Thanks for the quick reply…

Changed them on my linux box so they should be ok and weren’t related to the modules that failed, but will try it tomorrow and see what happens.

[sim909]

Fairly old thread, but I think I found a way to implement the feature. My objective was to enable native btrfs support, but I think I also achieved the objectives of the OP.

The good thing is that the current kernel already supports btrfs, so we don’t need to tinker with the kernel. Also, from what I understand, chck.btrfs is very different from chck.extN and it is very dangerous to try and fix a btrfs, it is better if no checks are run at all, therefore no need to add btrfs-progs in the initramfs (although of course it can be done). End result: all that is needed are a couple of mods in the init file.

So all I did was:

• ensure that if rootfs is btrfs then fsck is disabled, even if force-check is enabled
• read mount options from rootflags

That’s all. And it works (tested on RPi2 with rootfs on a btrfs subvolume). I think the mods are so small and unrelated to ext4 installations, that it is safe to implement.

The additions to the init file are as follows (init taken straight from git):

sim909@playpi:~> diff init.original init.patched
90a91,94
>               if [ "$OPTION_FILESYSTEM" =  "btrfs" ] ; then OPTION_DO_FSCK="0" ; fi
>               ;;
>         rootflags=*)
>               OPTION_MOUNT_OPTIONS=",${option#*=}${OPTION_MOUNT_OPTIONS}"
108a113
>               if [ "$OPTION_FILESYSTEM" = "btrfs" ] ; then OPTION_FORCE_FSCK="0" ; fi

I’d really appreciate it if the osmc developers would implement this solution… btrfs support could still be classified as experimental, but I am sure it would appeal to many users.

[sam_nazarko]

As we currently only support fsck for ext4 filesystems, I think it’s probably better that instead of checking for btrfs; we check if the filesystem specified is not ext4, and then disabled filesystem checks.