Hi, firstly I have openrc-0.4.1 and baselayout-2.0 installed. When rebootting, shutting down or running init 1 I receive the following message which repeats continuously. In all but the init 1 case, I must then manually reset my computer. hwclock: waiting for localmount. I initially had hwclock within my default runlevel but removing hwclock from all runlevels (boot in my case) has not solved this issue. I have turned rc logging on and will attach the rc.log file. The file demonstrates me booting my computer, running init 1 and waiting for the hwclock message to display, at which point I am presented with a console after Ctrl-c'ing, and I run killall hwclock (note hwclock messages are still being displayed to console at this point and my root fs is still mounted rw.). I then ran init 3 to bring my system back up. Im unsure as to what info to provide. Your requests are my commands, just lets not start asking for rm -Rf / paludis --info paludis 0.32.4 Paludis build information: Compiler: CXX: x86_64-pc-linux-gnu-g++ 4.3.2 CXXFLAGS: -march=k8 -O2 -pipe LDFLAGS: DATE: 2008-12-24T17:12:15+1300 Libraries: C++ Library: GNU libstdc++ 20080827 Reduced Privs: reduced_uid: 1000 reduced_uid->name: alistair reduced_uid->dir: /home/alistair reduced_gid: 1000 reduced_gid->name: alistair Paths: DATADIR: /usr/share LIBDIR: /usr/lib64 LIBEXECDIR: /usr/libexec SYSCONFDIR: /etc PYTHONINSTALLDIR: RUBYINSTALLDIR: /usr/lib64/ruby/site_ruby/1.8/x86_64-linux Environment: Format: paludis Config dir: /etc/paludis World file: /var/db/pkg/world Repository installed-virtuals: format: installed_virtuals root: / Repository virtuals: format: virtuals Repository gentoo: format: ebuild location: /usr/portage append_repository_name_to_write_cache: true binary_destination: false binary_keywords: binary_uri_prefix: builddir: /var/tmp/paludis cache: /usr/portage/metadata/cache distdir: /usr/portage/distfiles eapi_when_unknown: 0 eapi_when_unspecified: 0 eclassdirs: /usr/portage/eclass ignore_deprecated_profiles: false layout: traditional names_cache: /var/cache/paludis/names newsdir: /usr/portage/metadata/news profile_eapi_when_unspecified: 0 profiles: /usr/portage/profiles/default/linux/amd64/2008.0 securitydir: /usr/portage/metadata/glsa setsdir: /usr/portage/sets sync: rsync://rsync.au.gentoo.org/gentoo-portage sync_options: use_manifest: use write_cache: /var/cache/paludis/metadata Package information: app-admin/eselect-compiler: (none) app-shells/bash: 3.2_p48 dev-java/java-config: 1.3.7-r1 2.1.9999 dev-lang/python: 2.5.2-r8 2.6.1 dev-python/pycrypto: (none) dev-util/ccache: (none) dev-util/cmake: 2.6.2 dev-util/confcache: (none) sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.1 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13 2.63 sys-devel/automake: 1.10.2 1.4_p6 1.5 1.7.9-r1 1.8.5-r3 1.9.6-r2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 (for sys-kernel/linux-headers::installed)
Created attachment 176293 [details] rc.log demonstrating error message
*** This bug has been marked as a duplicate of bug 252534 ***
reverse duplicate
*** Bug 252534 has been marked as a duplicate of this bug. ***
Has anyone tried with 0.4.0?
(In reply to comment #5) > Has anyone tried with 0.4.0? > I downgraded to =sys-apps/openrc-0.4.0 ran etc-update but did not apply any updates (all /etc/conf.d and /etc/rc.conf updates) and retested. Issue still remains. Now I know nothing about openrc or init.d in general but could this be the problem on my system, from the depend() function within /etc/init.d/* localmount ( need fsck ) -> fsck ( use clock ) -> clock ( need localmount ) If I read that correctly (which I probably haven't), neither clock or localmount would be able to stop as they are required by the other.
I think it is using the old /etc/init.d/clock file instead of the new /etc/init.d/hwclock file, what provides clock. I just deleted the old one ( rm /etc/init.d/clock) and rebuilded the deptree with /lib/rc/bin/rc-depend -u ,seems to be fixed that way.
(In reply to comment #7) > I think it is using the old /etc/init.d/clock file instead of the new > /etc/init.d/hwclock file, what provides clock. I just deleted the old one ( rm > /etc/init.d/clock) and rebuilded the deptree with /lib/rc/bin/rc-depend -u > ,seems to be fixed that way. > Also able to fix it by doing this. Was there some documentation that I missed? the baselayout and openrc migration guide mentions clock stuff, but doesn't explicitly mention to delete /etc/init.d/clock. Should it?
Instructions in #7 fixed the problem for me as well
I think it is redundant, because hwclock should be/is used. The migration guide say clock is renamed to hwclock, so for me the old clock file should be erased and it should be added to the doc.
Did you guys come straight from baselayout-1 to the openrc-0.4.x series or were you on a previous openrc version?
(In reply to comment #11) > Did you guys come straight from baselayout-1 to the openrc-0.4.x series or were > you on a previous openrc version? From a previous version.
I too upgraded from version 0.3.0
This is my installation history for openrc: Tue Apr 15 06:53:36 2008 >>> sys-apps/openrc-0.2.1-r2:0 Wed Apr 16 08:23:57 2008 >>> sys-apps/openrc-0.2.2:0 Tue Apr 29 22:39:41 2008 >>> sys-apps/openrc-0.2.3:0 Sun May 11 22:36:20 2008 >>> sys-apps/openrc-0.2.4:0 Wed May 14 18:15:02 2008 >>> sys-apps/openrc-0.2.4-r1:0 Thu May 29 22:47:48 2008 >>> sys-apps/openrc-0.2.5:0 Mon Jun 9 18:13:15 2008 >>> sys-apps/openrc-0.2.5:0 Tue Jun 10 00:44:38 2008 >>> sys-apps/openrc-0.2.5:0 Mon Oct 6 18:41:02 2008 >>> sys-apps/openrc-0.3.0:0 Wed Oct 8 18:18:25 2008 >>> sys-apps/openrc-0.3.0-r1:0 Sat Dec 20 09:52:52 2008 >>> sys-apps/openrc-0.4.0:0 Wed Dec 24 10:19:54 2008 >>> sys-apps/openrc-0.4.1:0
Straight from baselayout-1 here, but the same error.
I've committed what I hope is the fix for this issue. It should forcibly remove the old clock init script now when you emerge openrc. Let me know if this doesn't do the trick.
It didn't work for me with openrc-0.4.1-r1.I had to remove the clock script manually following the instructions in 7. It is possible that I was using an ebuild that wasn't fixed when I did the upgrade though.
I get the same with net.eth0 :( But with openrc-0.4.3-r3.
Seems to be fine now, with >= 0.5.x.
