https://bugzilla.novell.com/show_bug.cgi?id=450196 https://bugzilla.novell.com/show_bug.cgi?id=450196#c94 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |werner@suse.com --- Comment #94 from Felix Miata 2012-07-04 16:25:30 UTC --- (In reply to comment #93)

I you really depend on localtime in CMOS you have to run the latest mkinitrd *after* updating aaa_base, hwclock, and mkinitrd for 12.2.

Already you've confused me. Are you saying I need to run mkinitrd twice each time a new one is indicated by a new kernel or something it's supposed to contain? I noticed long ago that when doing zypper dup on Factory after not having done it for more than a week or three that mkinitrd tends to get run multiple times. This (and other quirks) caused me quite some time ago to not just do zypper dup, but to make multiple steps out of it: 1-zypper al kernel-desktop 2-zypper ref 3-zypper in zypper libzypp rpm udev glibc mkinitrd libsolv-tools perl-Bootloader yast2-bootloader perl 4-zypper dup 5-reboot 6-zypper rl kernel-desktop 7-[zypper in kernel-desktop,zypper dup] About as often as not I skip step 4, as I've not been able to determine whether it makes a difference. The point is though that mkinitrd is normally that last component of zypper dup when I do it here, in order to ensure that all the latest bits are in the newest initrd. Out of habit, I do it this way even with release versions, not just with Factory.

Then make sure that the file /etc/adjtime exists with exactly three lines and the last line showing `LOCAL'. If the file does not exists the create one

echo "0.0 0 0.0" > /etc/adjtime echo "0" >> /etc/adjtime echo "LOCAL" >> /etc/adjtime

and check with

cat /etc/adjtime

Above matches the current content on host gx62b I booted to respond to comment 93.

if all three lines exists. Now make sure that /etc/localtime as well as /usr/share/zoneinfo/UTC exsists. Then run

mkinitrd

Every time I do updates that result in any new initrd, I save it with a # appended. On gx62b there are currently 2 for the previous kernel and 2 for the current kernel....

and check with

lsinitrd /boot/initrd | grep -E 'clock|time|UTC'

...and all 4 begin with usr/share/zoneinfo/UTC. I just ran mkinitrd, which generated two more and both begin with usr/share/zoneinfo/UTC.

if initrd is correct. There should be /etc/localtime, /etc/adjtime, /usr/share/zoneinfo/UTC, /bin/warpclock, and /boot/0<X>-clock.sh with X maybe equal 5 or so.

The complete content of each: usr/share/zoneinfo/UTC. etc/adjtime etc/localtime etc/sysconfig/clock bin/warpclock boot/05-clock.sh All 13 or 14 of my Factory installs were last updated on or after 28 June and have 3.4.2 kernels, but now zypper se -s tells me there is a 3.4.4 kernel available, so now on gx62b: (on tty3) 1-zypper al kernel-desktop 2-Reboot # (alias Reboot='cd; umount -a; shutdown -r now') 3-mountsrv # (mounts 4 noauto fstab NFS entries) 4-zypper ref 5-zypper in zypper libzypp rpm udev glibc mkinitrd libsolv-tools perl-Bootloader yast2-bootloader perl # none new 6-zypper dup # no new aaa_base, hwclock or mkinitrd; systemd & systemd-sysvinit to be "downgraded" from home:/sbrabec to openSUSE; abort 7-zypper al systemd systemd-sysvinit 8-zypper dup # 20 (mostly kde*3*) to upgrade, 1 to change vendor; warning: %post(kdebase3-SuSE...) scriptlet failed, exit status 1; no new initrds 9-Reboot # no /var/log/boot.msg/omsg to check for this bug, as I was distracted to not look real time 10-zypper rl kernel-desktop 11-zypper dup # (3.4.4-2.4.1.i686) 12-cd /boot; mv vmlinuz vmlinuz-curr; cp vmlinuz-curr vmlinuz (via mc on tty2) 13-mv initrd initrd-curr; cp initrd-curr initrd (via mc) 14-cp -a initrd-3.4.4-2.4-desktop i0nitrd-3.4.4-2.4-desktop1 (via mc) 15-backup & fixup /boot/grub/menu.lst (via mc) 16-rm /boot/do_purge_kernels (via mc) 17-lsinitrd /boot/initrd | grep -E 'clock|time|UTC' usr/share/zoneinfo/UTC. etc/adjtime etc/localtime etc/sysconfig/clock bin/warpclock boot/05-clock.sh 18-Reboot I could see no evidence on tty1 or /var/log/messages that this bug appeared this update round, so I'll have to try on others in separate comment(s) when it does appear again. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.