Setting system clock to hardware clock [Local TIme] ...
hanging system on upgrade to 064-r1. no additional info as i have a dead box now.
Steps to Reproduce:
after using the livecd to boot and downgrading to udev-063, my system boots
again. i am masking off >=064 locally. emerge info pasted below/
Portage 188.8.131.52-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130,
glibc-2.3.5-r0, 2.6.12-gentoo-r7 i686)
System uname: 2.6.12-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz
Gentoo Base System version 1.6.13
sys-devel/autoconf: 2.13, 2.59-r6
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
CFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
USE="x86 X alsa avi cdr cups divx4linux dvd dvdr encode fbcon gif gpm gtk gtk2
jpeg mad mikmod mmx mpeg ncurses nls nptl oggvorbis opengl oss perl png python
readline sdl slang spell sse ssl tcpd truetype unicode xml2 xprint xv xvid zlib
userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS
And 064 works?
Sure you merged the new config file properly for 064-r1?
Also, 065 is now out, try that.
Let me know if 065 works.
i never tried 064. as far as the configs are concerned i alway replace the _id
files and the 50-udev.rules with the new ones. i'm hestitant to test this
unless you feel you really found somethuing. booting from a cd and chroot'ing
is a pain.
i just installed 065 and carefully replaced the _id and rule files. My report
is the same. My box inits through the filesystem checks, mounting local file
systems, activation of more swap and then it hangs on:
* Setting system clock to hardware clock [Local Time] ...
I should mention, since I believe that the release note state you are now using
tmpfs, that my /tmp partitiion is a memory (swap) partition. I don't know if
that matters, but I am mentioning it. Is it possible that there are now
implicit restrictions on mounting partitions to swap? Anyway, time to dust off
the LIVECD again and downgrade to udev-063.
specifically these lines in my /etc/fstab may be of interest:
none /dev/shm tmpfs size=32M,nosuid 0 0
none /tmp tmpfs size=256M,nosuid 0 0
I don't see anything odd in the clock setting logic.
I see /dev/tty being opened, and /dev/urandom, and /dev/null.
What is the permissions that are set on /dev/tty?
It should be:
crw-rw-rw- 1 root tty 5, 0 Aug 4 15:39 /dev/tty
And no, the tmpfs stuff should not matter (didn't change anything there anyway.)
crw-rw-rw- 1 root tty 5, 0 Aug 4 15:39 /dev/tty
is indeed what i see here now, but i am back at 063. it tried several tests,
including using kernels 2.6.12-gentoo-r6 and r7 and also not using any local
rules at all. as far as the clock is concerned, i use the real-time clock
driver compiled into the kernel. i alter the rtc settings in my /etc/sysctl.conf
# for mplayer, tvtime. etc.
dev.rtc.max-user-freq = 1024
my /etc/conf.d/clock differs from the defaults only in this line:
Finally I note that "clock" is in the boot run-level.
All of the above is really not unusual I would think.
Can you run strace on the clock startup?
Do as root:
strace -o /tmp/strace.out /etc/init.d/clock/start
and then attach the /tmp/strace.out file to this bug?
Created attachment 65468 [details]
strace.out of clock start
here it is.
In that strace, it does:
read(3, "root=/dev/hda3 hdc=ide-cd hdd=id"..., 128) = 128
read(3, "LE=/dev/vc/1\n", 128) = 13
What file is this that is specifying /dev/vc/1 ? Can you grep around /etc
to find it? That might help in tracking down what is going wrong.
It's my /boot/grub/grub.conf kernel line:
kernel /kernel-2.6.12-gentoo-r7 root=/dev/hda3 hdc=ide-cd hdd=ide-scsi
I used CONSOLE=/dev/vc/1 instead of /dev/tty1 because tty1 is a symlink to vc/1.
or, it's my inittab:
etc # grep vc inittab
c1:12345:respawn:/sbin/agetty 38400 vc/1 linux
c2:12345:respawn:/sbin/agetty 38400 vc/2 linux
c3:12345:respawn:/sbin/agetty 38400 vc/3 linux
c4:12345:respawn:/sbin/agetty 38400 vc/4 linux
c5:12345:respawn:/sbin/agetty 38400 vc/5 linux
c6:12345:respawn:/sbin/agetty 38400 vc/6 linux
I changed the terminals to vc/* so that /var/log/wtmp entries properly report
users on my framebuffer consoles. Otherwise 'w' does not report things correctly.
tty1 is no longer a symlink to vc/1, as that is gone with the 065 release.
So, can you change both of those files to be just tty1?
Are you telling me that in 065 my framebuffer devices will be /dev/ttyX and not
/dev/vc/X? I don't follow the logic of your statement that "tty1 is no longer a
symlink to vc/1," therefore I should change my tty's to ttyX. I want my
getty's to listen on the devices that match the utmp entries. If you are
telling me that my framebuffer devices are going to be /dev/ttyX and logged as
such to utmp, then I understand. Otherwise I am puzzled by your statement as it
has no connection to the information I provided above.
Yes, inittab should look like:
c1:2345:respawn:/sbin/agetty 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux
c3:2345:respawn:/sbin/agetty 38400 tty3 linux
c4:2345:respawn:/sbin/agetty 38400 tty4 linux
c5:2345:respawn:/sbin/agetty 38400 tty5 linux
c6:2345:respawn:/sbin/agetty 38400 tty6 linux
The /dev/vc/ directory is now gone, as that was a devfs name. We have switched
back to LSB names as devfs is now gone from the kernel.
btw it looks like /etc/securetty from sys-apps/shadow is loaded up with vc/X
i skipped ahead to udev-067. boots ok now after changing to CONSOLE=/dev/tty1
on my grub kernel line and changing my /etc/inittab to ttyX entries instead of
vc/X. Using no local rules file, I notice none of the cd/dvd symlinks were
created. Are you aware of this or do you need a new bug report? Close this
one out. It's resolved.
bug #102669 filed regarding no cd/dvd symlinks created at boot
Yeah, it was probably the inittab entries, thanks for testing this.
*** Bug 103762 has been marked as a duplicate of this bug. ***