#304 e4defrag doesn't recognize root parition

[Anonymous]

From "sudo e4defrag -c -v /dev/sdb5" I get "Filesystem is not mounted". But it's where root is.

I boot without initrd with "kernel /vmlinuz root=/dev/sdb5 rootfstype=ext4" line in grub.

dmesg has:
EXT4-fs (sdb5): mounted filesystem with ordered data mode. Opts: (null)

"mount" shows this:
/dev/root on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
with "/dev/root" instead of "/dev/sdb5". there is no "/dev/root".

kernel config has:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

I don't know how e4defrag checks that it's mounted and whether it's devtmpfs or udev's fault that it's weird, but e4defrag should still deal with it.

[Robert White]

This is not a problem with e4defrag, this is an artifact of the "earily user context" and the way some initrd and/or initramfs systems work. In particular use of pivot_root() and initrd is deprecated in favor of using an initramfs and the sequence of commands memorialized in busybox's "switch_root" command.

The actual sequence of commands that should now happen in an initramfs is equivelent to:
mount /dev/whatever /new_root
(low-level program does a diropen() of "/")
mount --bind /new_root /
(low-level program cleans out the initramfs using the "at" versions of unlink, open, etc (see "man -S 2unlinkat")
(this is what the "switch_root" busybox component does.)

The short verison is that using pivot_root leaves behind a /dev/root phantom device in the mount tables because the "initial ram disk" is still there but the root filesystem has been abnormally spliced into it.

A fully modern/conforming system will have entries such as I paste here from my system:

rootfs / rootfs rw 0 0
/dev/sda3 / ext4 rw,relatime,data=ordered 0 0

The artifact from the "rootfs" psudo-filesystem (as opposed to a ramdisk device) is unavoidable and harmelss. It's hard-coded into the kernel as part of "earily user context", e.g. the new way of doing things,which is short-circuited for ramdisk based initrd(s) in the name of backward compatibility.

Check out the bash-plus-busybox initramfs builder I have put in http://underdog.sourceforge.net (that's all that's there so far really 8-) for building smart(er) (I hope) initramfs images.

[Robert White]

My bad... you were booting "wihtout initrd"... My other statements are not fully applicable to you... sorry...

The /dev/root device is the magic text used for the post resolution of root= when it happens in the kernel. It's orghogonal partner is /dev/nfsroot for network booting.

/dev/root is an in-kernel-boot-text alias that is no actually created in /dev by default because there is no default permissions meme associated with major/minor device numbers. The whole boot-time recognition of /dev/whatever is a hack in the kernel (since /dev, by definition hasn't been mounted before there is a root mounted to mount /dev on).

Regardless, there is no actual way to turn /dev/root into a real device name at runtime -unless- you have really good udev support in your distro. (I use gentoo and there is a /dev/root to the relevent partition in my system). I don't think it happens via devtmpfs, and I presume it doesn't from your text, but you -could- also have something clobbering it...

Have you checked that the topmost device on /dev is your devtmpfs and that your distro hasn't over-mounted it with a regular tmpfs etc?

Anyway, I use the underdog thing (mostly because I am developing it and I use LVM and encryption etc. very early in my bootup) so all I can tell you about your distro is that if you had devtmpfs mouted and you were using udev-182 you should have a /dev/root... 8-)