Gentoo Archives: gentoo-user

From: Hilco Wijbenga <hilco.wijbenga@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] ERROR: cannot start hwclock as fsck would not start
Date: Tue, 05 Aug 2008 07:30:03
Message-Id: e95b15950808050030y21031cccr76754ed76c683c78@mail.gmail.com
In Reply to: Re: [gentoo-user] ERROR: cannot start hwclock as fsck would not start by ionut cucu
1 On Mon, Aug 4, 2008 at 11:29 PM, ionut cucu <cuciferus@×××××.com> wrote:
2 > On Thu, 31 Jul 2008 22:32:31 -0700
3 > "Hilco Wijbenga" <hilco.wijbenga@×××××.com> wrote:
4 >
5 >> Hi all,
6 >>
7 >> I've had the above error during boot for quite some time now so
8 >> clearly it doesn't have too major consequences. :-) I would, however,
9 >> like to understand what's going on and then, if possible, fix it.
10 >>
11 >> The first thing I tried was to grep for (parts of) this error in the
12 >> /etc/init.d scripts but that yielded nothing. Using extra ewarns in
13 >> /etc/init.d/hwclock and /etc/init.d/fsck I discovered that both
14 >> hwclock and fsck *do* indeed run (but after the error is displayed).
15 >> Looking in other places (/usr/lib/portage, /usr/portage, /etc) didn't
16 >> yield anything useful either.
17 >>
18 >> lion ~ # rc-update show
19 >> gpm | default
20 >> ntp-client | default
21 >> fsck | boot
22 >> hald | default
23 >> mtab | boot
24 >> ntpd | default
25 >> root | boot
26 >> swap | boot
27 >> keymaps | boot
28 >> local | default nonetwork
29 >> vixie-cron | default
30 >> syslog-ng | default
31 >> maradns | default
32 >> localmount | boot
33 >> consolefont | boot
34 >> modules | boot
35 >> hostname | boot
36 >> net.lo | boot
37 >> net.eth0 | default
38 >> procfs | boot
39 >> netmount | default
40 >> sysctl | boot
41 >> urandom | boot
42 >> termencoding | boot
43 >> hwclock | boot
44 >> bootmisc | boot
45 >> device-mapper | boot
46 >> alsasound | boot
47 >>
48 >> Any ideas?
49 >>
50 >> Cheers,
51 >> Hilco
52 >>
53 > Same here with that error, didn't even noticed it till now. Maybe we
54 > should open a bug report
55
56 I removed hwclock (rc-update del hwclock) and that seems to have
57 "fixed" it. I'm still not sure on why this happened though.