boot.clock/Set system clock to hardware clock error

Has anyone else had problems with the boot.clock process freezing during boot when it displays “Set system clock to hardware clock”? Only way out for me is to ctrl+c and it will continue loading.

Only other post I could find had someone running mkinitrd as root… did that and still no joy. This and one other issue are keeping me from upgrading. (Other issue is that shutdown does not power down… it finishes and I hear the drives power down but the mainboard stays on.

Thoughts? I would LOVE to use this version but these two issues are very bothersome, especially since everything else seems to be so much better… been stuck on 11.0 due to other issues that now seem resolved with 11.2


The failure to poweroff is a BIOS/kernel ACPI issue.
The hardware clock is likely also to be a related issue.

You might have better luck, loading “optimised defaults” in BIOS setup.

You might find there’s a mobo BIOS update to apply from your manufacturer. In past, I’ve had updates which broke things with older versions, but worked with newer. Making a BIOS update may also be tricky, especially if they assume you have Windows and it going wrong can brick a mobo.

You may need to submit a bug report (I think on kernel).

Sorry to “me too”, but me too…

In fact, after 3 minutes boot.clock appears to give up and the boot process runs on regardless.

I installed with ACPI disabled as I have an old motherboard (MSI K7N2 Delta)

It I recall, the boot clock process tries to connect to a time server. If it can’t connect it may take some time before it gives up. This can happen if the network is not up yet or not connected or if a bad URL for the NTP is bad. Check in Yast-System-Date Time to see if a NTP server has been set.

No, it’s setting the Kernel system clock from Mobo RT clock on boot, and saving back to Mobo on shutdown :

/etc/init.d/boot.clock :


Provides: boot.clock

Required-Start: boot.rootfsck

Required-Stop: boot.rootfsck

Should-Start: $null

Should-Stop: apparmor

X-Start-Before: boot.localfs

X-Stop-After: $null

Default-Start: B S


Description: Read hardware clock and set system clock

Short-Description: Read hardware clock and set system clock


Started very early in boot process after mounting root, but before the local filesystems are mounted. Otherwise, the timestamps on files could be messed up.

Hi, I had the same problem when I first updated to 11.2. I was able to fix that error by switching to the kernel (pae) from the kernel (default).But this didn’t solve all my problems, I still have a hang on shutdown but the boot is ok now. I guess this hardware is too old to run smoothly.(HP Pavilion ze4700 from 2002-2003)
I also had similar problems with 10.3, 11.0,11.1. I’ve been chasing down log errors for the last week.

OK, So I was finally able to play with this… Kitting ctrl+c when the system hangs on the set system clock… will allow the boot process to proceed. ACPI was OFF on the mobo… I can use the system normally but issues with shutdown and boot.clock remain. SO… I have a Tyan S2098 mobo. Just flashed with the latest Bios it has for them… circa 2003… Old I know! only option available though…

So, the results… loading optimized or turning on ACPI in bios will correct the boot.clock issue. New Problem: after trying to log in, the desktop never loads. Only hangs after you pass the login prompt and everything but the wallpaper are removed. So the ACPI issue is a problem either way… I have tried all the boot options listed (pci=noacpi, acpi=oldboot, etc) No joy. All behavior stays the same.

I have not had any real success with openSUSE since 11.0 and even that one was not working where Samba and a generic NAS was concerned. Last fully working version for me on these boards (i have 4 Tyan S2098’s) was 10.3… man I wish this were not the case.

I guess I will have to sell these for next to nothing and get some mini itx boards. I have had little issue with the Intel 945 or the d201gl boards. Just funny how it works in one older version and gets broken, then is back…sort of, and then broken again… Regression testing on the kernel must be pretty shoddy. Sorry if that offends… just my experience for the last 5 years…