switch_root: old root filesystem is not an initramfs: SUCCESS

hoschi · 2014-04-02 01:17:54

Hello!

I'm compling and using my own custom-kernel, which worked in the past and still works with kernel "3.14".
How I do it basically:

$ make oldconfig
$ make -j5
# make modules_install
# cp arch/x86_64/boot/bzImage /boot/vmlinuz-custom 
# mkinitcpio -k 3.14.0-CUSTOM -g /boot/initramfs-custom.img -S autodetect

And the grub.cfg looks like this:

...
	menuentry 'Arch Linux, with Linux custom' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-custom-advanced-91b42bc5-6a8c-4628-947b-8053d24cec43' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_gpt 
		insmod ext2
		set root='hd0,gpt2'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  91b42bc5-6a8c-4628-947b-8053d24cec43
		else
		  search --no-floppy --fs-uuid --set=root 91b42bc5-6a8c-4628-947b-8053d24cec43
		fi
		echo	'Loading Linux custom ...'
		linux	/boot/vmlinuz-custom root=UUID=91b42bc5-6a8c-4628-947b-8053d24cec43 rw  quiet
		echo	'Loading initial ramdisk ...'
		initrd	/boot/initramfs-custom.img
	}
...

But during bootup the system print this message since the release of kernel "3.14.0":

switch_root: old root filesystem is not an initramfs: SUCCESS

Source:
https://git.kernel.org/cgit/utils/util- … oot.c#n184

Okay. The old root filesystem is not an initramfs, but why!? This worries me! Even if it is an overall "Success".

// Update
It doesn't happen with a kernel form the old "3.13.x" series. I didn't changed anything like that in the configuration.

// Update
dmesg looks good:

[    0.305840] Unpacking initramfs...
[    0.497537] Freeing initrd memory: 3676K (ffff8800378c2000 - ffff880037c59000)

Last edited by hoschi (2014-04-02 01:34:07)

WonderWoofy · 2014-04-02 02:07:13

I have no idea why this would be happening, but if the initramfs is bieng reported as 'not an initramfs' don't you think it might be necessary to include some information about what you do to build your initramfs?

That is, do you need to be running an initramfs? Are the modules necessary for booting now compiled into the kernel? Are you using mkinitcpio? And so forth...

jasonwryan · 2014-04-02 03:17:59

I get this with my custom kernel and the Arch vanilla 3.14.

Moving to [testing] now that 3.14 has hit that repo...

fredbezies · 2014-04-02 06:19:13

Got it too, with official kernel. Weird !

Could it be related to this ?

https://mailman.archlinux.org/pipermail … 34929.html

linux: Re-add CONFIG_UNUSED_SYMBOLS
I don't know what this will break and I don't have the time to care
about it, so keep it for now.

Last edited by fredbezies (2014-04-02 06:24:33)

hoschi · 2014-04-02 07:44:41

jasonwryan wrote:

I get this with my custom kernel and the Arch vanilla 3.14.
Moving to [testing] now that 3.14 has hit that repo...

Thank you! At least I'm not alone and can calm down.

WonderWoofy wrote:

I have no idea why this would be happening, but if the initramfs is bieng reported as 'not an initramfs' don't you think it might be necessary to include some information about what you do to build your initramfs?
That is, do you need to be running an initramfs? Are the modules necessary for booting now compiled into the kernel? Are you using mkinitcpio? And so forth...

I didn't mention any special configuration, i.e. /etc/mkinitcpio.conf, because it is the plain default. I don't need the initramfs itself, because the my own kernel has everything necessary built-in. Creating the initramfs for my custom kernel is sheer convenience and absolutely superfluous, which I could avoid! I just create the initramfs to fullfill the - possible - default expectations of other stuff from the repositories, i.e. bootloader-configuration could be automatically generated.

Last edited by hoschi (2014-04-02 08:27:47)

hoschi · 2014-04-02 08:36:50

fredbezies wrote:

Got it too, with official kernel. Weird !
Could it be related to this ?
https://mailman.archlinux.org/pipermail … 34929.html
linux: Re-add CONFIG_UNUSED_SYMBOLS
I don't know what this will break and I don't have the time to care
about it, so keep it for now.

Hmm. I can't imagine a relation, especially because I don't modified it itself.

I've written a mail to Thomas and the authors of switch_root.c inside util-linux.

brain0 · 2014-04-02 08:42:52

I only use systemd in initramfs, and that boots fine. Does your system still boot?

The error indicates that switch_root believes your / is not initramfs, so it refrains from recursively deleting all its contents. It's a safety measure.

brain0 · 2014-04-02 08:58:25

Also please open a bug report and tag it with [linux] [util-linux] so we don't forget to get to the bottom of this. The impact right now is that you waste a small amount of memory since all initramfs files are sitting in rootfs, which you have no access to.

hoschi · 2014-04-02 09:01:50

I'm currently using the default of Archlinux, /etc/mkinitcpio.conf:

HOOKS="base udev autodetect modconf block filesystems keyboard fsck"

Do you think it is a sane leap into the feature to change it to:

HOOKS="systemd autodetect modconf block filesystems keyboard (fsck)"

systemd = replace base and udev -> https://wiki.archlinux.org/index.php/mk … time_hooks
systemd = superseeds fsck if boot command line uses ro -> https://bbs.archlinux.org/viewtopic.php … 5#p1307895

// update: removed obsolete udev, fsck see follow-up postings

Last edited by hoschi (2014-04-03 21:42:21)

brain0 · 2014-04-02 09:14:44

You can replace base AND udev with systemd. Keeping both systemd and udev is broken. You should also keep fsck.

HOOKS="systemd autodetect modconf block filesystems keyboard fsck"

Anyway, this should be fixed, since not everyone can use systemd-initramfs yet. Hence, I'd appreciate if you open a bug report as I mentioned.

hoschi · 2014-04-02 09:23:28

Thanks. I will do so today evening! Furthermore I will care about the bug report, if not somebody else will do that in meantime. I'm currenty not at home.

Can you tell me, why I should still (?) use the fsck hook? I fullquote falconindy to give you the context:

falconindy wrote:

I don't understand why this is so complicated. There's two players involved, and it's always been this way regardless of the versions involved (at at least as long as the fsck hook has existed):
1) mkinitcpio offers you to option to fsck your root device before mounting it via the fsck hook. If you do this, you should mount root read-write via the appropriate 'rw' option on the kernel commandline. Historically, you mounted root read-only so that it could be fsck'd later on in the bootstrap. If root has already been fsck'd, why would you mount it read-only just to be remounted read-write later on?
2) systemd will fsck all filesystems assuming three things are true: the filesystem has a fsck pass number greater than 0 (either from /etc/fstab or a user-supplied unit file), the filesystem is not already mounted read-write, and you've not elected to disable fsck entirely via the kernel commandline option fsck.mode=skip.
In short, these are the only 2 logical setups:
1) Use the 'fsck' hook, use 'rw' on the kernel commandline.
2) Don't use the 'fsck' hook, use 'ro' on the kernel commandline.
Both of these options result in your root device being checked exactly once. The unlisted option 3 which most people seem to be running into isn't harmful (which is why it's simply a warning). Again, mkinitcpio is pointing out that root might be fsck'd again. mkinitcpio has no way of knowing for sure what will happen after it calls switch_root and it's only rightfully warning you that your config is strange.
Editorial snark: If your bootloader makes this change difficult for you, maybe it's time to consider a different bootloader.

https://bbs.archlinux.org/viewtopic.php … 5#p1307895

Option "2" could be interpreted like "use systemd hook, set ro on boot cmd, drop fsck hook".

Last edited by hoschi (2014-04-02 09:27:32)

brain0 · 2014-04-02 09:53:11

Alright, I always use 'rw' on the command line (no remount needed, so a bit faster). I am unsure how systemd behaves when using the fsck hook AND ro, I think it has the same double-fsck behaviour.

progandy · 2014-04-02 11:06:23

Maybe linux has the device id for the initramfs is set wrongly or fstat is not working correctly? This error message looks like the error message from the util-linux implementation.
The switch_root implementation in util-linux compares it to "makedev(0,1)".
-> https://github.com/karelzak/util-linux/ … oot.c#L178
Why does our busybox not include switch_root? Maybe this works better:
-> http://git.busybox.net/busybox/tree/uti … root.c#n94
Systemd which is used in an initramfs with systemd hook does this:
-> https://github.com/systemd/systemd/blob … root.c#L60
-> https://github.com/systemd/systemd/blob … il.c#L5142

Last edited by progandy (2014-04-02 11:14:21)

hoschi · 2014-04-02 11:17:59

fredbezies wrote:

Got it too, with official kernel. Weird !
Could it be related to this ?
https://mailman.archlinux.org/pipermail … 34929.html
linux: Re-add CONFIG_UNUSED_SYMBOLS
I don't know what this will break and I don't have the time to care
about it, so keep it for now.

I mailed with Thomas in the meantime (very fast response!). Looking at the documentation of CONFIG_UNUSED_SYMBOLS, it is unlikley involved. It should only hit external (ugly) drivers, which are mostly closed-source (NVIDIA-Binary, AMD-Binary and so on).

hoschi · 2014-04-02 11:39:45

util-linux got an update in testing, anyone tested it?

Last edited by hoschi (2014-04-02 11:43:02)

brain0 · 2014-04-02 13:40:20

That update fixes another (possibly loosely related) util-linux bug with 3.14. The switch_root problem needs some further investigation, but it isn't critical at the moment.

brain0 · 2014-04-02 13:41:28

progandy wrote:

Maybe linux has the device id for the initramfs is set wrongly or fstat is not working correctly? This error message looks like the error message from the util-linux implementation.
The switch_root implementation in util-linux compares it to "makedev(0,1)".
-> https://github.com/karelzak/util-linux/ … oot.c#L178
Why does our busybox not include switch_root? Maybe this works better:
-> http://git.busybox.net/busybox/tree/uti … root.c#n94

What busybox does in this case seems saner (check for ramfs or tmpfs magic instead of checking an explicit undocumented device id). We switched to util-linux's switch_root a while ago, since it has some more features than the busybox one.

clfarron4 · 2014-04-02 20:59:21

fredbezies wrote:

Got it too, with official kernel. Weird !

Same here... This is my partition layout:

NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                       8:0    0 931.5G  0 disk  
├─sda1                    8:1    0   199M  0 part  /boot
├─sda2                    8:2    0 634.4G  0 part  
│ └─Storage             254:0    0 634.4G  0 crypt 
│   ├─Storage-lrootvol  254:1    0    30G  0 lvm   /
│   ├─Storage-lvarvol   254:2    0    10G  0 lvm   /var
│   ├─Storage-lhomevol  254:3    0   300G  0 lvm   /home
│   └─Storage-lsteamvol 254:4    0   100G  0 lvm   /home/steam
├─sda3                    8:3    0   293G  0 part  
└─sda4                    8:4    0     4G  0 part 
sr0                      11:0    1  1024M  0 rom

And here is the HOOKS line from mkinitcpio.conf:

HOOKS="base udev autodetect modconf block encrypt lvm2 filesystems keyboard fsck fglrx"

brain0 · 2014-04-02 23:21:28

Your partition layout doesn't matter. It happens for everyone, except those that use systemd in initramfs.

Possible fix submitted by Dave: http://www.spinics.net/lists/util-linux … 09062.html - we'll need to wait what Karel has to say about it.

hoschi · 2014-04-03 08:15:59

I'm sorry but I didn't manage to do anything yesterday evening (to much work). Looking forward for today evening.

hoschi · 2014-04-03 22:22:43

brain0 wrote:

Alright, I always use 'rw' on the command line (no remount needed, so a bit faster). I am unsure how systemd behaves when using the fsck hook AND ro, I think it has the same double-fsck behaviour.

Thanks!
I've removed the hooks base and udev and replaced booth with the hook systemd. I decided to keep the hook fsck and the boot-flag rw, like suggested by you. It works and I don't get the warning message anymore. I've also tested the combination with the hook systemd and without the hook fsck and changed accordingly the boot-flag to ro, which also works fine.

The basic reason why I stay with fsck and the boot-flag rw is, it is the default for GRUB. I can't tell if this combination is actually faster, than the hook systemd and the boot-flag ro. Probably my SSD mitigates any difference.

Last edited by hoschi (2014-04-04 09:01:42)

clfarron4 · 2014-04-03 22:30:48

I was going to switch to the systemd hook, but I use LVM on LUKS and the Wiki says the following for the systemd hook:

ArchWiki wrote:

As of systemd 207, this hook does not work as intended when combined with lvm2 and may break your boot. You also may wish to still include the base hook (before this hook) to ensure that a rescue shell exists on your initramfs.

Has there been any updates on this?

brain0 · 2014-04-03 23:03:04

The sd-lvm2 and sd-encrypt hooks are your friends. However, the kernel commandline syntax of sd-encrypt is different, see the systemd-cryptsetup-generator manpage. You may also want the sd-vconsole hook to get the correct keyboard layout.

Anyway, the underlying bug here is being worked around in a new kernel package and there will be a fix in the util-linux package soon, hopefully.

hoschi · 2014-04-03 23:16:10

brain0 wrote:

Also please open a bug report and tag it with [linux] [util-linux] so we don't forget to get to the bottom of this.

Done. I've also opened a upstream-bug on the kernel-bugtracker.

Good night

Last edited by hoschi (2014-04-03 23:16:22)

jasonwryan · 2014-04-04 01:56:14

Seems to be fixed in Arch Vanilla 3.14.0-3...

Arch Linux

#1 2014-04-02 01:17:54

switch_root: old root filesystem is not an initramfs: SUCCESS

#2 2014-04-02 02:07:13

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#3 2014-04-02 03:17:59

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#4 2014-04-02 06:19:13

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#5 2014-04-02 07:44:41

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#6 2014-04-02 08:36:50

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#7 2014-04-02 08:42:52

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#8 2014-04-02 08:58:25

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#9 2014-04-02 09:01:50

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#10 2014-04-02 09:14:44

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#11 2014-04-02 09:23:28

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#12 2014-04-02 09:53:11

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#13 2014-04-02 11:06:23

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#14 2014-04-02 11:17:59

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#15 2014-04-02 11:39:45

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#16 2014-04-02 13:40:20

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#17 2014-04-02 13:41:28

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#18 2014-04-02 20:59:21

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#19 2014-04-02 23:21:28

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#20 2014-04-03 08:15:59

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#21 2014-04-03 22:22:43

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#22 2014-04-03 22:30:48

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#23 2014-04-03 23:03:04

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#24 2014-04-03 23:16:10

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

#25 2014-04-04 01:56:14

Re: switch_root: old root filesystem is not an initramfs: SUCCESS

Board footer