Arch Linux

Maniaxx

Member

Registered: 2018-03-28

Posts: 9

kernel/init bug when BIOS date/time incorrect

Hallo,
i have a HP Compaq nc6120 Laptop (BIOS 07/27/2006). Arch32 runs pretty well.
The built-in BIOS/CMOS battery drains very fast (over and over again) so i do not change it anymore (main battery pack is dead/removed as well). The time will be synchronized by Arch instead. This worked for some years. I'm not sure when it started exactly but nowadays the kernel crashes with the error below (right after GRUB). The BIOS has no option to set the date and time. Even Win7 has problems setting the date. If i attempt to do so there is a 100% cpu spike on the 'system' process and the date won't be set.
Working solutions are setting date by either a live Linux or GRUB2 recovery shell. Once done the device works properly until AC power gets removed.

Any idea what this could be? Arch32 specific (init?) problem? The keyboard doesn't work in the state of the screenshot.

abaumann

Administrator

From: Zurich

Registered: 2019-11-14

Posts: 1,032

Website

Re: kernel/init bug when BIOS date/time incorrect

I can say very little about the clock issue, the early missing keyboard issue is usually a keyboard module missing in mkinitcpio.conf.

Maniaxx

Member

Registered: 2018-03-28

Posts: 9

Re: kernel/init bug when BIOS date/time incorrect

Seems to be a Y2K problem. Setting the date before 2000-01-01 leads to the crash. Maybe someone can confirm that on a 2nd machine? Grub->press 'c'->date 1999-01-01->press 'esc'->boot.

This doesn't happen on upstream Arch. Some people say the mount error ('Value too large for defined data type') is 32bit only that could be solved by compiling with 'large file support' that leads to a chain of new problems though. Not sure if related.

The screenshot shows several (i/o related?) binaries/commands are failing: 'stat' and 'mkdir' are 'busybox'. 'mount' is a regular file. 'ash' seems to work properly.

For reference:
Screenshot transcription:

/init: line 477: mount: Value too large for defined data type
/init: line 478: mount: Value too large for defined data type
/init: line 479: mount: Value too large for defined data type
/init: line 480: mount: Value too large for defined data type
/init: line 481: mkdir: Value too large for defined data type
/init: line 13: can't open /proc/cmdline no such file
/init: line 27: modprobe: Value too large for defined data type
:: mounting '' on real root
/init: line 378: mount: Value too large for defined data type
You are now being dropped into an emergency shell.
/init: line 56: sh: Value too large for defined data type
Trying to continue (this will most likely fail) ...
/init: line 49: stat: Value too large for defined data type
/init: line 49: stat: Value too large for defined data type
ERROR: Failed to mount the real root device.
Bailing out, you are on your own. Good luck.

sh: can't access tty: job control turned off
[rootfs ]# _

./init

#!/usr/bin/ash

udevd_running=0
mount_handler=default_mount_handler
init=/sbin/init
rd_logmask=0

. /init_functions

mount_setup

./init_functions

476: mount_setup() {
477:     mount -t proc proc /proc -o nosuid,noexec,nodev
478:     mount -t sysfs sys /sys -o nosuid,noexec,nodev
479:     mount -t devtmpfs dev /dev -o mode=0755,nosuid
480:     mount -t tmpfs run /run -o nosuid,nodev,mode=0755
481:     mkdir -m755 /run/initramfs

alf9009

Member

Registered: 2020-02-29

Posts: 20

Re: kernel/init bug when BIOS date/time incorrect

I had not the same but a similar problem, cmos battery dead ... resets to year 2060 ... kernel panic ...
You can set the date in grub, see here my post at #9 - maybe this helps you too
https://bbs.archlinux32.org/viewtopic.php?id=3000

Maniaxx

Member

Registered: 2018-03-28

Posts: 9

Re: kernel/init bug when BIOS date/time incorrect

Yes, that's a good idea. I will use that.

Thanks.

Edit:
I've tested 2060 and it throws the same error as above. Looks like i'm bound between 2000-2038 that is kinda weird. Looks like i'm suffering from both epoch types limits.

Alternative proposals have been made (some of which are already in use), such as storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed 64-bit integer
https://en.wikipedia.org/wiki/Year_2038 … #Solutions

Last edited by Maniaxx (2022-07-23 20:44:33)