[bug?] Using generic kernel fails when using btrfs subvolumes in 14.2

moesasji · 10-01-2016, 05:18 PM

Installing a Slackware 14.2 system using btrfs subvolumes similar to the guide available here http://www.yodaconditions.com/dokuwi....install.btrfs doesn't work on 14.2. It fails to boot with a "No /sbin/init found on rootdev" error.

The reason this happens is that the mkinitrd script ignores the rootflags that are needed to mount the correct subvolume. The patch given in the following topic appears correct and fixes this problem for me: http://www.linuxquestions.org/questi...en-4175553213/

Could this fix be applied please as all guides for using btrfs as root for Slackware recommend the generic kernel, which doesn't work for 14.2 and the solution isn't that obvious.

atelszewski · 10-02-2016, 06:15 PM

Hi,

Per kernel-parameters.txt, rootflags is a kernel parameter and so should be handled by the kernel and not init.

Did you try appending rootflags= to the kernel command line?

Grepping the kernel source indicates that the parameter is actually used:

Code:

Documentation/kernel-parameters.txt:	rootflags=	[KNL] Set root filesystem mount option string
fs/hfsplus/inode.c:	if (perms->rootflags & HFSPLUS_FLG_IMMUTABLE)
fs/hfsplus/inode.c:	if (perms->rootflags & HFSPLUS_FLG_APPEND)
fs/hfsplus/inode.c:				(file->permissions.rootflags |
fs/hfsplus/hfsplus_raw.h:	u8  rootflags;
fs/hfsplus/catalog.c:		perms->rootflags |= HFSPLUS_FLG_IMMUTABLE;
fs/hfsplus/catalog.c:		perms->rootflags &= ~HFSPLUS_FLG_IMMUTABLE;
fs/hfsplus/catalog.c:		perms->rootflags |= HFSPLUS_FLG_APPEND;
fs/hfsplus/catalog.c:		perms->rootflags &= ~HFSPLUS_FLG_APPEND;
fs/hfsplus/catalog.c:					(file->permissions.rootflags |
fs/ubifs/super.c: * flags. However, when a "rootflags=" kernel boot parameter is used, they may
init/do_mounts.c:__setup("rootflags=", root_data_setup);

and having a really quick look at init/do_mounts.c shows that rootflags= seems to be handled (i.e. it is passed to sys_mount()).

--
Best regards,
Andrzej Telszewski

moesasji · 01-05-2017, 05:52 AM

Quote:

Originally Posted by atelszewski

Hi,
Did you try appending rootflags= to the kernel command line?

I had forgotten about this topic until it bit me once again today on another btrfs on root install. I actually have those rootflags in my lilo config, but doing that doesn't help as also reported in the topic I linked to in my first post: http://www.linuxquestions.org/questi...en-4175553213/

I'm pretty sure it is a bug if I look at /boot/init-tree/init itself. The mount command used in that file is

Code:

 mount -o ro -t $ROOTFS $ROOTDEV /dev

.

From that you can see that the information needed to select the correct btrfs subvolume isn't included as in my case the mount command would have to be

Code:

 mount -o ro,subvol=system -t $ROOFTS $ROOTDEV /dev

. The patch I linked to should fix it, but I tend to be lazy and just fix that mount command after a clean run of mkinitrd. With that fix the system boot as expected.

In other words just passing the rootfs and rootdevice isn't enough for a btrfs drive with volumes as rootflags don't get passed on.

chemfire · 01-05-2017, 12:45 PM

I'll second what moesasji said. I to use a btrfs subvolume as root and the only dependable fix I have found is to fix the mount statement in the initrd's init script. Its pain, would be nice if these patch which looks good and I will test next time I update my kernel could get rolled into the mainline!

rbn14 · 05-29-2017, 01:40 AM

I've patched the init script and I'm still getting

Code:

modprobe: ERROR: could not insert 'btrfs' : Cannot allocate memory

Code:

mount: can't find /mnt in /etc/fstab
ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.

moesasji · 05-29-2017, 05:01 AM

Quote:

Originally Posted by rbn14

I've patched the init script and I'm still getting

Code:

modprobe: ERROR: could not insert 'btrfs' : Cannot allocate memory

Your problem here is that it fails to load the btrfs module, which I haven't seen before. Are you booting of a generic kernel** that includes the btrfs module in initrd?

**) The huge kernel doesn't work in my experience. The steps to follow are pretty much as described here: https://saivnoba.wordpress.com/2012/...th-btrfs-root/ with the patch applied to the init script.

rbn14 · 05-29-2017, 10:36 AM

Yes, I saw that blog in my searches and it is very close to what I did. My steps were:
Format /dev/sda1 with mkfs.btfs
mount /dev/sda1 and create subolumes
unmount and mount the root subvolume
install Slackware
create initrd-tree by running

Code:

mkinitrd

patch the init script
then run mkinitrd with my options

Code:

mkinitrd -k 4.4.14 -f btrfs -r /dev/sda1 -m btrfs -u -o /boot/initrd.gz

install grub and generate grub.cnf
edit /etc/fstab
reboot

moesasji · 05-29-2017, 10:58 AM

I always run the mkinitrd both times with the options included, i.e. first

Code:

mkinitrd -c -k 4.4.14 -f btrfs -r /dev/sda1 -m btrfs -u -o /boot/initrd.gz

edit or patch and then run it again using

Code:

mkinitrd -k 4.4.14 -f btrfs -r /dev/sda1 -m btrfs -u -o /boot/initrd.gz

I have many more modules included if I run the mkinitrd_command_generator.sh, but that shouldn't impact on this.

btw) I use lilo so I am using a separate /boot partition that isn't on the btrfs volume. That might indeed not be needed for grub, but I've never tried.

rbn14 · 05-29-2017, 11:22 AM

I was wondering if that could be the cause, running mkinitrd with no options first. I unfortunately don't have a good understanding of how mkinitrd works. I think I tried that in one iteration but I'll give it another shot and check back in.
As for a separate boot partition, that shouldn't be needed with grub and is why I have chosen to use it. I'll try an iteration using a separate boot partition and lilo as well just to see.
Thanks for the input thus far.

rbn14 · 05-29-2017, 06:06 PM

Okay, seems that grub was writing the config to default to the huge kernel. Once I switched it it the generic i seem to be good on the modprobe of btrfs. I still get this though:

Code:

mount: can't find /mnt in /etc/fstab

It seems to be unrelated to btrfs though. I may start a new thread for it.

chemfire · 05-30-2017, 06:48 AM

I have had the same problem. I have to run mkinitrd and than edit init in the initrd-tree, than run mkinitrd or just use cpio directly to build the image with the edited file. Its an extra step but as rarely as I change kernels its not been a serious issue.

Thanks for the patch moesasji