Upgraded to openrc-0.11 yesterday, everything seems fine as my system was running. I had an issue from resuming from suspend that make a hard reboot necessary. After that, everything was so slow to death and I could not launch any xterm because of a missing devpts mount. Well, `mount` would have shown that shm and devpts was mounted which wasn't actually mounted. In fact, to be able to run any xterm application I had to mount devpts manually. This WAS an annoying issue because some applications failed to load shared libraries as librsvg which caused too many hassles. I was lost on rebuilding linked libraries (to svg) to no avail: svg images weren't rendered at all in Enlightenment DE. Downgrading to openrc-0.10.5 solved the issue. Sorry to not provide any meaningfull log/error message because I was sik of this issue (I was thinking to reinstall everything so to speak quite an annoying issue!). I do remember that an error related to mounting shm was shown on startup but as shm was mounted, well only seemed actually, because `mount` would wrongly(?) show it, I did not pay any attention to it. Reproducible: Always
Same problem
If mount shows that devpts and /dev/shm are mounted, they are, so there isn't enough information in this bug for me to even begin to troubleshoot this. Please upgrade again, set rc_logger="YES" in /etc/rc.conf, then reboot and attach the following information: 1) emerge --info 2) /var/log/rc.log. 3) the error message that shows up early in the boot process. Without that information at least, there is no way for me to troubleshoot this issue. Thanks, William
I just was pointed to the #openrc channel on irc, and found a discussion there. I version bumped udev-init-scripts. Please upgrade to openrc-0.11, *and* udev-init-scripts-17. Let me know if the issue goes away after you do that.
Is everyone getting this issue also running stable udev?
I am seeing this same issue. This is a full ACCEPT_KEYWORDS="~amd64" desktop. I have tried the new udev-init-scripts-17 and it is showing the same behavior. # qlist -ICv udev udev-init-scripts openrc app-admin/openrc-settingsd-1.0.1 sys-apps/openrc-0.11 sys-fs/udev-194 sys-fs/udev-init-scripts-17 # uname -a Linux ris-ben 3.6.2-gentoo #1 SMP Mon Oct 15 18:07:42 CDT 2012 x86_64 Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz GenuineIntel GNU/Linux # I haven't looked into these scripts at all yet to see what's going on, but if you have some ideas for things to test, or you need more system info, I would be happy to provide.
Created attachment 326966 [details] emerge --info I am currently unable to get rc logging working, even though my rc.conf has simply: unicode="YES" rc_sys="" rc_tty_number=12 rc_logger="YES" But here's emerge --info attached
I am seeing this on my ~amd64 box (in virtualbox, have not wanted to update my actual install yet). I cannot open an xfce4 terminal (getpt failed: no such file...) - devpts, shm and also my nfsv4 mounts are not being mounted with openrc-0.11, before or after the udev-init-scripts version bump. udev itself is v194 rc-logging has only logged my shutdown while running 0.10.5, and does not seem to log anything to /var/log/rc.log while running openrc-0.11
I have the same problem, uptodate ~amd64 system. Upgrading from sys-fs/udev-init-scripts-16 to -17 did not help. Symptoms are as described by the others: /dev/shm and /dev/pts are not mounted correctly, which means that KDE konsole and quadkonsole start up, but the bash prompt never appears. umount /dev/pts says it is not mounted. Doing mount -t devpts none /dev/pts fixes konsole / quaskonsole. During boot I have seen some error messages during "Remounting filesystems" that remounting /dev/shm was not possible. Was is strange: /etc/mtab and /proc/mounts say that both things are mounted, I will attach both files.
Created attachment 326970 [details] Contents of /etc/mtab, says /dev/pts is mounted, but its not
confirm. same problem. rc.log was empty.
Created attachment 326972 [details] Contents of /proc/mounts, also says that /dev/pts is mounted, but as written: "umount /dev/pts" errors
What is the output from: # rc-update | grep devfs
# rc-update | grep devfs devfs | sysinit # rc-status sysinit Runlevel: sysinit dmesg [ started ] sysfs [ started ] devfs [ started ] udev [ started ] tmpfilesd.sysinit [ started ]
What I guess is happening: First /dev/shm and /dev/pts get mounted correctly -> lines 4+5 from my /proc/mounts. But then udev deceides to mount a new devtmpfs over /dev and hides these mounts again: line 8: udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=1526432,mode=755 0 0 Could this be related: CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y I'm using kernel 3.7-rc1, but before the upgrade to openrc-0.11 it worked fine for me, so I don't think that is the root cause. rc.log also only contains the shutdown messages, but I'm trying to find out what goes wrong there...
Confirmed, same problem on mine PC
(In reply to comment #14) > What I guess is happening: > First /dev/shm and /dev/pts get mounted correctly -> lines 4+5 from my > /proc/mounts. > But then udev deceides to mount a new devtmpfs over /dev and hides these > mounts again: line 8: udev /dev devtmpfs > rw,nosuid,relatime,size=10240k,nr_inodes=1526432,mode=755 0 0 Same conclusion here. > Could this be related: > CONFIG_DEVTMPFS=y > CONFIG_DEVTMPFS_MOUNT=y > > I'm using kernel 3.7-rc1, but before the upgrade to openrc-0.11 it worked > fine for me, so I don't think that is the root cause. > > rc.log also only contains the shutdown messages, but I'm trying to find out > what goes wrong there... sys-fs/udev-194 sys-fs/udev-init-scripts-17 3.6.2(-zen), but with CONFIG_DEVTMPFS=y # CONFIG_DEVTMPFS_MOUNT is not set
openrc-0.11 breaks vservers too: cgroups get mounted even if rc_controller_cgroups="NO" in /etc/rc.conf and no services requiring net are able to start in any vserver. Should keep much more attention in releasing init system updates...
My system have not been touched with problems mentioned above, but net.lo pay attention of carrier now, so system cannot start with unattached network cables. Add "return 0" in begin of _wait_for_carrier() in net.lo or you can be surprised after reboot... I'm sure net.lo shouldn't take care of ethernet carrier until user will intentionally set wait_carrier_ethx=5 for example. (=timeout_in_seconds, =-1 or unset for not taking care if cable is attached or not)
(In reply to comment #18) > My system have not been touched with problems mentioned above, > but net.lo pay attention of carrier now, so system cannot start > with unattached network cables. > > Add "return 0" in begin of _wait_for_carrier() in net.lo > or you can be surprised after reboot... > > I'm sure net.lo shouldn't take care of ethernet carrier until > user will intentionally set wait_carrier_ethx=5 for example. > (=timeout_in_seconds, =-1 or unset for not taking care if > cable is attached or not) You stated yourself that this is a separate issue, so please open another bug. Thanks, William
Couldn't find a way to 'subscribe' to see if anyone finds a workaround/fix. I'm hitting this too, ~amd64 as well. Masked openrc-0.11 here as well. By any chance, are any of the other people running either a custom initrd, or at least not a genkernel initrd? I discovered this 'bug' while testing out a new version of mine, which is really the only reason I think this is a possible cause. Maybe our initrds aren't correctly preparing root for switch-over?
(In reply to comment #20) > Couldn't find a way to 'subscribe' to see if anyone finds a workaround/fix. > I'm hitting this too, ~amd64 as well. Masked openrc-0.11 here as well. By > any chance, are any of the other people running either a custom initrd, or > at least not a genkernel initrd? I discovered this 'bug' while testing out > a new version of mine, which is really the only reason I think this is a > possible cause. Maybe our initrds aren't correctly preparing root for > switch-over? In the future please note the "add me to CC" checkbox near the top on the right side ;-)
All, with some assistance from several devs today, namely chainsaw, robbat2 and creffett, the solution has been found. I am committing the fixes now and will post back here once that is done.
I'm having the same bug tonight. I fixed that problem with this line inside my /etc/fstab none /dev/shm tmpfs nodev,nosuid,noexec 0 0 devpts /dev/pts devpts defaults 0 0 I saw when I boot about a OpenRC error that says that /dev/shm and /dev/pts were unable to create or something similar.
This bug really covered two issues: The first issue was the dependencies on the dev and dev-mount virtuals in OpenRC's init scripts. The need and use dependencies were not correct, because there is no guarantee that a provider for dev or dev-mount will be installed on every system. Commits 2a9de2d and e8acdc6 changed these to before and after where necessary. This is much more accurate since the affected init scripts do not *require* a dev or dev-mount provider. The other issue was that udev-mount was never being added to a runlevel, and had never been. The udev init script was making udev-mount start using a need dependency instead of udev-mount being added to a runlevel. This works because the need dependency does not consider runlevels. The long and short of this is, you should upgrade to openrc-0.11.1. If you are using ~arch udev, you should make sure you are running at least udev-init-scripts-17-r1. If you are running stable udev, you should run udev-171-r8. Once you have all of the correct software, make sure to run these commands: rc-update add udev sysinit rc-update add udev-mount sysinit Once all of this is done, report back to the bug and let us know if things are working.
Created attachment 326992 [details] emerge --info Upgraded to openrc-0.11.1 and udev-init-scripts-17. Issue persists. Console ouput at boot shows devfs starting normally, but failing when remounting the filesystems: Starting service devfs Mounting /dev/pts ... [ok] Mounting /dev/shm ... [ok] ... ... Starting service root Remounting root filesystem read/write ... [ok] Remounting filesystems... /dev/shm Mount: /dev/shm not mounted or bad option." #mount rootfs on / type rootfs (rw) /dev/root on / type reiserfs (rw,noatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc) cpu on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu) udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=1014441,mode=755) /dev/sda7 on /home/james type reiserfs (rw,noatime,nosuid,nodev,user) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nodev,noexec,nosuid) Pseudo Terminals still not able to run at this point, even though devpts and shm claim to be mounted. Mounting devpts manually, #mount /dev/pts adds a second mount entry for devpts and now working pseudo terminals. devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) #cat /etc/rc.conf rc_interactive="YES" rc_shell=/sbin/sulogin rc_logger="YES" unicode="YES" rc_tty_number=12 (rc_logger appears to be broken, entries in /var/log/rc.log only logs shutdown.)
(In reply to comment #25) > Created attachment 326992 [details] > emerge --info > > Upgraded to openrc-0.11.1 and udev-init-scripts-17. Issue persists. I guess we posted close to the same time. Try udev-init-scripts-17-r1.
lol, I should have waiting 5 minutes.... Updated to udev-init-scripts-17-r1 and added udev-mount to sysinit. Working beautifully. Thanks William.
I also had thos problem and it's fixed now, but as someone else stated there is also a problem with NFS filesystems not being mounted. This problem persists even after these changes.
I still get messages saying Could not create /dev/pts! Could not create /dev/shm! during startup. I'm running openrc-0.11.1 and udev-init-scripts-17-r1 Portage 2.2.0_alpha141 (default/linux/x86/10.0, gcc-4.6.3, glibc-2.15-r3, 3.6.2-gentoo i686) ================================================================= System uname: Linux-3.6.2-gentoo-i686-Intel-R-_Core-TM-2_CPU_6420_@_2.13GHz-with-gentoo-2.2 Timestamp of tree: Sat, 20 Oct 2012 06:45:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] ccache version 3.1.8 [enabled] app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/ccache: 3.1.8 dev-util/cmake: 2.8.9-r1 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.1 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.4 sys-devel/binutils: 2.22.90 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo mv sabayon dev-zero local_portage ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -mmmx -msse -msse2 -msse3 -mssse3 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -mmmx -msse -msse2 -msse3 -mssse3 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs" DISTDIR="/home/ftp/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y --keep-going" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersandbox" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_US es es_LA es_MX ja ko zh_CN zh_TW zh" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/mv /var/lib/layman/sabayon /var/lib/layman/dev-zero /usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X aac acl acpi alsa bash-completion berkdb bluray bzip2 cairo cdda cddb cdr cjk cli clutter consolekit corefonts cracklib crypt css cups cxx dbus dri dvd dvdread eds ffmpeg flac fontconfig fortran gdbm gif gmp gnome gnome-keyring gpm gstreamer gtk iconv icu ipv6 jpeg jpeg2k lcms libnotify lm_sensors lzma mmx modules mp3 msn mudflap nautilus ncurses nls nptl nsplugin ogg opengl openmp pam pcre png policykit pppd pulseaudio qemu-ifup qt3support readline session sse sse2 sse3 ssl ssse3 svg tcpd theora threads tiff truetype udev unicode vaapi vdpau vorbis win32codecs x264 x86 xml xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer nlpsolver pdfimport" LINGUAS="en en_US es es_LA es_MX ja ko zh_CN zh_TW zh" NETBEANS_MODULES="apisupport cnd dlight enterprise ergonomics groovy java javacard javafx mobility php profiler websvccommon" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nouveau nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Upgrading to 0.11.1 and 17-r1 and adding udev-mount to sysinit worked for me too. @Chris Slycord: Did you "rc-update add udev-mount sysinit" as noted in commect 24? You did not mention that point in your comment... @Mikael Grahn: I think that was an intentional change, because "nfs-utils knows better" how to start all the needed daemons for nfs. But it might have been better to add a "need nfsmount" if nfs/nfs4 mountpoints where found, instead of changing the behavior of netmount to completely ignore such filesystems. Thanks for the fast fix.
Upgrading to openrc-0.11.1, udev-init-scripts-17-r1, and adding udev-mount to the sysinit runlevel has fixed the problem on my ~x86 box.
I'm using stable udev. udev-171-r8 + openrc-0.11.1 do not fix the problem for me. This fix worked yesterday: /e/i.d/devfs with need dev-mount and /e/i.d/udev-mount with provide dev-mount Why was /e/i.d/devfs changed back to 'use dev-mount' instead of 'need dev-mount'?
(In reply to comment #17) > openrc-0.11 breaks vservers too: cgroups get mounted even if > rc_controller_cgroups="NO" in /etc/rc.conf and no services requiring net are > able to start in any vserver. > Should keep much more attention in releasing init system updates... If rc_controller_cgroups="NO", the /sys/fs/cgroup/openrc group will still be created. This switch only controlls whether the other groups are created. There is a quick hack that will take care of the services that need net not starting. You should add the following to /etc/conf.d/net. rc_lo_provide="net" You should also file a bug against each service that has "need net" in its dependencies and ask for this to be dropped. These bugs should block bug #439092. I will add a warning about this to the ebuild. (In reply to comment #28) > I also had thos problem and it's fixed now, but as someone else stated there > is also a problem with NFS filesystems not being mounted. This problem > persists even after these changes. (In reply to comment #30) > @Mikael Grahn: I think that was an intentional change, because "nfs-utils > knows better" how to start all the needed daemons for nfs. > But it might have been better to add a "need nfsmount" if nfs/nfs4 > mountpoints where found, instead of changing the behavior of netmount to > completely ignore such filesystems. You are correct, this was an intentional change, see bug #427996. The issue with putting a need dependency here like you suggest would be that netmount would then fail if nfs failed even if other types of network file systems could be mounted, and it would be stop if nfs was stopped. I think this probably is not what you want. If you want nfs, you need to add the appropriate services to your runlevel.
Solved on my side with the latest version and the rc-update add udev-mount sysinit command. Thanks :P
(In reply to comment #33) > (In reply to comment #17) > > openrc-0.11 breaks vservers too: cgroups get mounted even if > > rc_controller_cgroups="NO" in /etc/rc.conf and no services requiring net are > > able to start in any vserver. > > Should keep much more attention in releasing init system updates... > > If rc_controller_cgroups="NO", the /sys/fs/cgroup/openrc group will still be > created. This switch only controlls whether the other groups are created. I can confirm ALL the groups are created even if rc_controller_cgroups="NO". > There is a quick hack that will take care of the services that need net not > starting. You should add the following to /etc/conf.d/net. > > rc_lo_provide="net" > > You should also file a bug against each service that has "need net" in its > dependencies and ask for this to be dropped. These bugs should block bug > #439092. > > I will add a warning about this to the ebuild. Don't all these things have to be done before releasing an update to openrc that will make a system unusable? Just to name a few, ssh and nginx have 'need net'. I think
Sorry, for the uncomplete comment. I was going to write: "I think sshd is almost everywhere, so I don't understand why this bug didn't get noticed before."
I am closing this, because, it has been verified multiple times that the specific issue brought up by the original reporter is fixed in openrc-0.11.1. OpenRC-0.11.2 will be released soon to fix the other unbootable issue for people with systemd installed.
This bug is resolved as fixed but I still gget the same issue with 0.11.2 as another user above.
(In reply to comment #38) > This bug is resolved as fixed but I still gget the same issue with 0.11.2 as > another user above. Please see comment 24, if that doesn't fix it then you have a different bug and should open a new bug.