root entry in /etc/fstab: first field (fs_spec) ignored

catkin · 04-30-2012, 04:15 AM

This may be well-known to some but I was surprised.

Apparently the first field for the / file system in /etc/fstab is ignored, replaced by the root= kernel parameter.

Using legacy GRUB and booting this stanza:

Code:

# Stanza 3
title       Slackware64 13.37 (backup, -c1, 640 GB HDD, Linux partition 6)
root        (hd0,5)
kernel      /boot/vmlinuz-2.6.37.6-c1 root=/dev/sdb6 vga=791 vt.default_utf8=1 acpi_enforce_resources=lax ro

The fstab has this line for root

Code:

# <file system> <mount point>     <type> <options>            <dump> <pass> 
/dev/sda13      /                 jfs    noatime,errors=remount-ro 0 1

After booting

Code:

c@CW8:~$ df /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/root      jfs    13G  7.5G  5.0G  60% /
c@CW8:~$ ls -l /dev/root
lrwxrwxrwx 1 root root 4 Apr 30 14:05 /dev/root -> sdb6

aus9 · 04-30-2012, 07:48 PM

hi

I don't use Slackware but on my grub2 system, df command looks correct.

1) have you tried a more recent kernel?

2) have you tried grub2 or interested in ?

I am leaning towards this post....I am looking at the mount command

http://www.linuxquestions.org/questi...xt2-fs-797354/

I am often wrong so forgive me if you just reporting and not asking.

catkin · 04-30-2012, 09:32 PM

Thanks aus9

Which OS are you using and do your kernel parameter root= and fstab / entry first field values differ?

I am planning to use the new GRUB (why is it called GRUB2 when it's actually GRUB 1.99?) but have deferred the plan until it is convenient to re-partition the HDD because the Arch WIKI says regards MBR partitioning "Usually the post-MBR gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 32 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB2's core.img ([2]). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of core.img)".

Actually I think the boot loader is irrelevant to what happens after it has loaded the kernel image and passed it the kernel parameters.

The linked thread is interesting but is about ext2/3/4 file systems; as the OP shows the / file system is JFS.

aus9 · 05-01-2012, 05:32 AM

I am on debian sid....but use a liquorix kernel

my field don't vary....well I am actually using a UUID fstab but it truly links to correct /dev/sda1 structure

b) and what I was trying to say in my vague manner is

run the command mount and see what it reports

mine is ok and consistent but me thinks you might have a gremlin when you run mount?

catkin · 11-28-2012, 05:29 AM

Update: the behaviour is diffferent and more misleading under Slackware64 14.0 which has the 3.2.29 kernel.

Using legacy GRUB and booting sda3 with this stanza ...

Code:

title       Slackware64 14.0 (1 TB HDD, Linux partition 3)
root        (hd1,2)
kernel      /boot/vmlinuz root=/dev/sda3 vga=791 vt.default_utf8=1 acpi_enforce_resources=lax ro

... when etc/fstab on /dev/sda3 contains this mismatched entry (sda14 instead of sda3) for / ...

Code:

/dev/sda14      /                  jfs    noatime,errors=remount-ro 0 1

... after booting, there are some confusing outputs about the root file system:

Code:

root@CW8:~# /bin/df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda14            12944784   7144732   5800052  56% /
[snip]
root@CW8:~# cat /etc/mtab 
/dev/sda14 / jfs rw,noatime,errors=remount-ro 0 0
[snip]
root@CW8:~# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / jfs rw,noatime 0 0
[snip]
root@CW8:~# /bin/ls -l /dev/root
/bin/ls: cannot access /dev/root: No such file or directory
root@CW8:~# mount /dev/sda3 /mnt/hd/sda3
root@CW8:~# mount /dev/sda14 /mnt/hd/sda14
root@CW8:~# /bin/df / /mnt/hd/sda3 /mnt/hd/sda14
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda14      12944784 7144732   5800052  56% /
/dev/sda3       12944784 7144732   5800052  56% /mnt/hd/sda3
/dev/sda14      12944752 6965476   5979276  54% /mnt/hd/sda14

Maybe it works something like this:

The root=/dev/sda3 kernel parameter causes /dev/sda3 to be mounted as / by the kernel
The kernel runs the boot scripts from /dev/sda3
udev(?) creates /dev/root as a symlink to /dev/sda3 in the normal way.
The boot scripts remount / rw
The kernel logs /dev/root as the / device, later visible via /proc/mounts
The boot scripts run mount -a which actions the erroneous fstab line for /. This does not change the file system mounted at / but does remove the /dev/root symlink and writes an erroneous entry to /etc/mtab.

catkin · 06-23-2013, 04:08 AM

The phenomenon seems to be a bug in df or wherever it gets its information from but there is one command which correctly detects which partition is mounted as root, lsblk. /proc/mounts is unhelpful.

Illustrating ...

After booting via this GRUB stanza ...

Code:

# Stanza 3
title       Slackware64 14.0 backup (640 GB HDD, Linux partition 7)
root        (hd0,6)
kernel      /boot/vmlinuz root=/dev/sdb7 vga=791 vt.default_utf8=1 acpi_enforce_resources=lax ro

... here's the output of the commands mentioned.

Code:

root@CW8:~# df /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda14     jfs    13G  8.8G  3.7G  71% /
root@CW8:~# cat /proc/mounts | grep ' / '
rootfs / rootfs rw 0 0
/dev/root / jfs rw,noatime 0 0
root@CW8:~# ls -l /dev/root
ls: cannot access /dev/root: No such file or directory
root@CW8:~# lsblk | grep -E 'sda14|sdb7'      
└─sdb7                 8:23   0  12.4G  0 part /
├─sda14                8:14   0  12.4G  0 part

Notes:

The information from df is wrong (sda14).
/proc/mounts does not say which partition is /
Only lsblk correctly identifies sdb7 as /

sdb7 is a backup clone of sda14, taken by dd. At the time of my initial post they had identical UUIDs and I thought that could be the cause of the problem but the symptoms are the same after changing sda14's.

GazL · 06-23-2013, 07:18 AM

Slackware's rc.S populates the missing entries of /etc/mtab after the root filesystem is remounted read-write using the "mount -f" fake-mount option. Specifically it does a /sbin/mount -f -w / which assumes that the fstab is correct and as such any inconsistency will be propagated to /etc/mtab and through it to all the other utilities such as 'df' that refer to it.

Of course, if you keep your fstab entry correct this isn't a problem, but perhaps pulling the root device from /proc/mounts rather than fstab would be more reliable when encountering untidy people who have the wrong value in their fstab.

Something along the lines of:
/sbin/mount -f -w "$(grep -v '^rootfs' /proc/mounts | grep '^[^ ]\+ / ' | cut -f1 -d ' ')" /

catkin · 06-28-2013, 03:59 AM

Thanks GazL

Appreciated.

grep -v '^rootfs' /proc/mounts | grep '^[^ ]\+ / ' | cut -f1 -d ' ' yields /dev/root.

Testing on Slackware64 14.0 (booted from /dev/sda14 which matches its fstab line for /) showed there is no /dev/root ...?

On Slackware64 13.37 /dev/root was a symlink to the /dev/sd[[:lower:]] that was mounted as /

IDK if the absence of /dev/root is usual or a strange feature of my personal computer. I browsed /lib/udev/rules.d/* files, looking for a rule that would create /dev/root but did not find. I could have missed it -- there are a lot of rules.

EDIT:

After posting that I looked for how /dev/root (the symlink and the /proc/mounts entry) are created. No clear picture emerged. The most illuminating pages were on the Gentoo Forums and lkml.org.

catkin · 09-29-2013, 04:36 AM

This code could be used to reliably (?) find the root file system device file (fs_spec in fstab terminology) for use in the fake mount command:

Code:

buf=$(lsblk -o 'NAME,MOUNTPOINT' | grep '/$' | sed -r -e 's|[[:space:]]+/$||' -e 's/^[^[:alnum:]]+//')
case $buf in
    *'(dm-'* )
        fs_spec=/dev/mapper/${buf%% *}
        ;;
    * )
        fs_spec=/dev/$buf
esac
/sbin/mount -f -w "$fs_spec" /