After upgrade from version 2.18-r1 to sys-apps/util-linux-2.19 the remount of the nfs root-fs in the boot process of the nfs booted client failed with following errors: "mount.nfs remote share not in host:dir format" "Root filesystem could not be mounted read/write" After replace /bin/mount with the old version/downgrade to version util-linux-2.18.r1 all works properly again. Reproducible: Always Steps to Reproduce: 1. emerge sys-apps/util-linux-2.19 2. reboot nfs-rooted client 3. Actual Results: root device is not mounted writable and so errors occur sequence Expected Results: root device should be mounted writable
Created attachment 262837 [details] emerge --info
please post the relevant mount line from /proc/mounts and /etc/mtab and /etc/fstab further, what version of nfs-utils do you have installed ? that provides `mount.nfs` now ... although i'm not sure of its usage off the top of my head in the remount scenario ...
(In reply to comment #2) > please post the relevant mount line from /proc/mounts and /etc/mtab and > /etc/fstab > > further, what version of nfs-utils do you have installed ? that provides > `mount.nfs` now ... although i'm not sure of its usage off the top of my head > in the remount scenario ... > I have tested first with /sbin/mount.nfs and replace it with the version of 1.2.2-r2 but no success and no change of the error messages (the current version of nfs-utils is 1.2.3-r1). nz23050 hg # ls -ls /etc/mtab 0 lrwxrwxrwx 1 root root 12 9. Apr 2008 /etc/mtab -> /proc/mounts nz23050 hg # cat /etc/fstab # fake root entry to make e.g. checkroot happy (and to have / appear in mount) #netroot / none bind 0 0 proc /proc proc defaults 0 0 shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 /ram/media /media none bind 0 0 ::: Please note the first line (netroot ...) is commented! If I activate the first line, the boot process looks like this: * Remounting root filesystem read/write ... mount: warning: / seems to be mounted read-only. ok The pxe boot statement is the following: nz00101 ~ # cat /export/tftpboot/onesis/boot/pxelinux.cfg/master-vm ::: kernel vmlinuz-2.6.35-gentoo-r15-vm append ip=dhcp root=/dev/nfs nfsroot=10.231.0.101:/export/tftpboot/onesis- master-vm acpi=off noapic ::: Is there a way to mount the nfs-root read-only bypass, because it's not really necessary, and to immediately mount read-write?
you didnt post the /proc/mounts line ... new util-linux probably doesnt like when you symlink /etc/mtab to /proc/mounts you can put "rw" or "ro" on the kernel command line to control the boot time mount state if you put "ro" into the fstab, baselayout will ignore it while remounting
seems to me that the issue is with your /etc/mtab -> /proc/mounts. default mount wont include "proto=tcp" and so the mtab wont have it and so the remount wont include it. but the /proc/mounts will always list it, and nfs mount doesnt like having that in its mount lines. proto=tcp causes the mount() syscall to return EINVAL
Created attachment 263417 [details] /proc/mounts
(In reply to comment #5) > seems to me that the issue is with your /etc/mtab -> /proc/mounts. default > mount wont include "proto=tcp" and so the mtab wont have it and so the remount > wont include it. but the /proc/mounts will always list it, and nfs mount > doesnt like having that in its mount lines. > > proto=tcp causes the mount() syscall to return EINVAL > Thanks for your input! I have tested now first with a non-symlink /etc/mtab, reboot 2 times, upgrade util-linux, but no success, the error messages are the same as before. Second I have tested with "rw" in the kernel command line and the master client booted properly with read-write access, also with a symlink for /etc/mtab again.
there might be something specific to doing it via nfsroot=, but it'd take me some time to find out what you should run `strace -f -s 4096 -v -o log` on both the old mount and the new mount, and post both logs as attachments
(In reply to comment #8) > there might be something specific to doing it via nfsroot=, but it'd take me > some time to find out what > > you should run `strace -f -s 4096 -v -o log` on both the old mount and the new > mount, and post both logs as attachments > I am not sure that I have understand you correctly. I have done the following: boot without "rw" and with "rw"in the kernel command line and run the command strace -f -s 4096 -v -o /ram/log_without_rw mount / strace -f -s 4096 -v -o log_with_rw mount. I hope that was what you wanted.
Created attachment 263663 [details] strace -f -s 4096 -v -o /ram/log_without_rw mount
Created attachment 263665 [details] strace -f -s 4096 -v -o log_with_rw mount
could you give 2.20 a spin ? it has had a bunch of fixes to mount added to it since the 2.19 release ...
(In reply to comment #12) > could you give 2.20 a spin ? it has had a bunch of fixes to mount added to it > since the 2.19 release ... here is the boot-test without "rw" in the kernel command line and version 2.20 (udev-171-r1): ::: * Starting udevd ok ::: * Waiting for uevents to be processed ... ok * devfs: waiting for udev (50 seconds) * devfs: waiting for udev (41 seconds) ::: * devfs: waiting for udev (5 seconds) * devfs: timed out waiting for udev ::: * Remounting root filesystem read/write mount.nfs: remote share not in 'host:dir' format * Root filesystem could not be mounted read/write :::
