Created attachment 414212 [details] My emerge --info Hi! Yesterday I upgraded OpenRC to version 0.18. However, when I disconnect from internet (e.g. when I suspend or restart the NetworkManager daemon), X crashes, and even I had a kernel panic once. This did not happen in 0.17 or earlier versions. Here I attach my emerge --info. Thanks!
I believe that your X server crashing and the kernel panic is merely a symptom. I have observed that /etc/init.d/netmount incorrectly attempts to unmount a local (non network) zfs filesystem if /etc/init.d/net.eth0 (or similar) is restarted. Do you happen to have a zfs filesystem on root? If no, can you please nopaste your /etc/fstab and check whether restarting the network tries to unmount local filesystems via netmount? (Do this by changing to the framebuffer so that you have a chance to see something).
(In reply to Matthias Maier from comment #1) > I believe that your X server crashing and the kernel panic is merely a > symptom. > > I have observed that /etc/init.d/netmount incorrectly attempts to unmount a > local (non network) zfs filesystem if /etc/init.d/net.eth0 (or similar) is > restarted. > > Do you happen to have a zfs filesystem on root? If no, can you please > nopaste your /etc/fstab and check whether restarting the network tries to > unmount local filesystems via netmount? (Do this by changing to the > framebuffer so that you have a chance to see something). Well... that's weird because I don't have any zfs filesystem on my installation. If it helps, there's my fstab. http://nopaste.linux-dev.org/?782248
For the record, it is a btrfs: > http://nopaste.linux-dev.org/?782248 /dev/sda7 / btrfs noatime,defaults 0 1
Yes, it is, so what's the matter with that? May it fails if so?
(In reply to jorgicio from comment #4) > Yes, it is, so what's the matter with that? It is something else than ext4. And the nopaste might not be preserved over a long time. All, it seems that /etc/init.d/netmount in openrc-0.18 goes on rampage when trying to unmounting network filessystems: * Unmounting network filesystems ... * Unmounting /usr ... * Unmounting /srv ... * Unmounting /home ... * Unmounting /sys/fs/cgroup/net_prio ... * Unmounting /sys/fs/cgroup/perf_event ... * Unmounting /sys/fs/cgroup/net_cls ... * Unmounting /sys/fs/cgroup/freezer ... * Unmounting /sys/fs/cgroup/devices ... * Unmounting /sys/fs/cgroup/blkio ... * Unmounting /sys/fs/cgroup/cpuacct ... * Unmounting /sys/fs/cgroup/cpu ... * Unmounting /sys/fs/cgroup/cpuset ... * Unmounting /sys/fs/cgroup/openrc ... * Unmounting /sys/fs/fuse/connections ... * Unmounting /sys/fs/cgroup ... * Unmounting /sys/kernel/debug ... * Unmounting /sys/kernel/security ... * Unmounting /dev/shm ... * Unmounting /dev/mqueue ... * Unmounting /run ... * Unmounting / ... * Unmounting /sys ... * Unmounting /dev/pts ... * Unmounting /dev ... * Unmounting /proc ... Above particular instance is triggered by the following /etc/fstab #kvm gentoo1 ~ # cat /etc/fstab UUID=76dc534c-3826-4f72-be58-53d6970d7d6a /boot ext2 defaults 0 0 And a zfs file system mounted as root and otherwise default configuration but I believe this happens with just about every file system! Further, line 56 of /etc/init.d/netmount seems fishy: do_unmount umount ${fs:+--fstype-regex} $fs --netdev I assume this must read: do_unmount "umount ${fs:+--fstype-regex} $fs --netdev" Without the quotes, netmount just unmounts everything without any contraints... Is this related to an attempted bug fix of bug #427996 ?
To be precise: With stock openrc-0.18: * Unmounting /usr ... umount /usr With quotes: do_unmount "umount ${fs:+--fstype-regex} $fs --netdev" * Remounting /usr read only ... umount --fstype-regex ^(afs|ceph|cifs|coda|davfs|fuse|fuse.sshfs|gfs|glusterfs|lustre|ncpfs|nfs|nfs4|ocfs2|shfs|smbfs)$ --netdev /usr
Tried by myself with and without quotes. With quotes: fails both in 0.17 and 0.18. Without quotes: fails in 0.18 only. 0.17 works fine.
Bisected to: #kvm gentoo1 openrc-9999 # git bisect good 5f4f2420364098835522da868a9e75205c9e4f9c is the first bad commit commit 5f4f2420364098835522da868a9e75205c9e4f9c Author: William Hubbs <w.d.hubbs@gmail.com> Date: Mon Oct 5 10:18:00 2015 -0500 mountinfo: fix --netdev and --nonetdev on Linux On Linux, the --netdev and --nonetdev switches were not working. They were both returning false. After this change, they operate based on the presence or abscence of the _netdev option in mount options. :040000 040000 7a3c1e9838b726e84c6511eb39198e73010866d7 9fc623d79819f82d646521eaa66c57d1ee4212ac M src
Given a basically empty /etc/fstab, getmntfile() will return NULL every time. That means netdev isn't initialized, which could cause problems. It also means that you could get some really random behavior -- any time getmntfile() returns null, netdev will retain the last filesystem's setting. I am not comfortable enough testing this on my host OS, but I think simply putting line 308 back in has a good chance of fixing this?
(In reply to Mik from comment #9) > I am not comfortable enough testing this on my host OS, but I think simply > putting line 308 back in has a good chance of fixing this? Correct, the following patch resolves the issue: diff --git a/src/rc/mountinfo.c b/src/rc/mountinfo.c index 53f2890..3f1dfb6 100644 --- a/src/rc/mountinfo.c +++ b/src/rc/mountinfo.c @@ -305,6 +305,7 @@ find_mounts(struct args *args) buffer = xmalloc(sizeof(char) * PATH_MAX * 3); while (fgets(buffer, PATH_MAX * 3, fp)) { + netdev = -1; p = buffer; from = strsep(&p, " "); to = strsep(&p, " ");
Created attachment 414496 [details, diff] The patch Yes, indeed, the patch fixes the issue. Just tried, rebooted, disconnected internet, and working. No hanging. As the ebuild has the epatch_user, you can put the patch in /etc/portage/patches/sys-apps/openrc.
This is fixed in commit b81317b which will be back-ported to openrc-0.18.1.
