Corepure64 won't boot on HP thin client

[FlyingDutchman]

Hi,

I'm running tiny core linux, corepure64 for a few years now without issue. I started at release 9 and upgraded through the years to releases 10, 11 and 12. However, release 13 won't boot on my system. I compared the on screen messages during startup and on release 13, halfway during boot I see the message "Freeing initrd memory: 12492K". I don't see that message in release 11 or 12. Then 2 segfaults follow and after that, the whole system freezes and a power cycle is the only option.

I don't think initrd memory is supposed to be freed, but I'm not sure. Any thoughts what is happening here? Or what a trigger might be to free initrd memory?

Sorry I can't include the logs; as the system doesn't boot to a CLI, I can't access them. I do have screenshots of the startup messages attached.

System information:
- HP Thin client t5550 (Via nano u3500 processor, 1 GB memory)
- Grub bootloader
- running Corepure64

Regards.

[Juanito]

Have you checked the md5sum for corepure64.gz and vmlinuz64?

Edit: from a successful boot:

Code: [Select]

$ dmesg | grep -i initrd
Freeing initrd memory: 12492K

[FlyingDutchman]

Hi,

Yes, I checked the md5 sums and these are correct. I also tried using "modules64.gz" and "rootfs64.gz" instead of "corepure64.gz"; same result.

BTW: it seems I'm on the wrong track with the "freeing initrd memory" message. Also in release 11 this message exists, only on a different moment in the startup sequence.

So, I really have no clue why the system won't start. Any thoughts what I can do to debug this?

[Juanito]

google suggests:

The solution is to add "udevchilds=64 udevtimeout=600" kernel boot codes

[curaga]

The segfault says it was in libc.so. So it looks like a bug in libc given udev has not changed, and probably something that only triggers on a Via cpu too.

Tracking down libc bugs on a system that won't finish boot in the first place is going to be difficult. I would approach it by running 12.x, setting up a 13.x chroot, and then trying debug approaches with a debug-built libc.

It may be easier if you try searching the libc bugzilla and see if someone else has already reported it? Though Via users may be a bit rare, so there's a chance you're the first.

[FlyingDutchman]

Short update.

I created a rootfs64 with a modified tc-config script, with lines "udevd --daemon" and "udevadm trigger --action=add" were commented out. This at least allowed the system to start and present a shell. From there I hoped to learn more by starting udevd with the --debug option. But nothing: it only reports a segfault.

I did learn that even the shell sometimes triggers a segfault in libc, so libc definitely seems to be the culprit. I'm not sure how to proceed. Even if I was able to find a cause with a debug libc version (which I doubt), changing or updating libc probably means recompiling lots of binaries that are dependent right? Maybe waiting for 14.0 is my best option?

[Juanito]

I've built a debug version of glibc a couple of times in earlier versions of tinycore - you will probably only need to replace /lib/libc.so.6 in the initrd.

Using the source and patches from here:

http://tinycorelinux.net/13.x/x86_64/release/src/toolchain/

..something like the attached should work

[curaga]

No, nothing dependant needs to be recompiled.

As for waiting for a new version, that will only work if someone else has found and fixed the bug. What if nobody else is using recent glibc on Via cpus?

[Juanito]

There's a debug libc.so.6 here: http://tinycorelinux.net/13.x/x86_64/tcz/src/glibc_debug/

You'll need to replace the existing version in the initrd with this one.

[FlyingDutchman]

That is wonderful service. Thanks. I've included the debug glibc in a rootfs64.gz, but booting that on my Via machine immediately brings me segfaults during init (error 6), leading to a kernel panic. Strange, because on an Intel virtual machine, the same rootfs64.gz works fine.

But booting from the rootfs64.gz I had constructed before and then swapping libc.so.6 for the debug libc.so.6 seems to work. Now some reading up to do on how to use gdb and then I will share some results.

[FlyingDutchman]

So, finally had some time to further investigate this. And again, hit a dead end. I was able to get the system running, with the modified rootfs64.gz (not starting udev). I then installed gdb.tcz and dependent packages and finally swapped libc.so.6 for the debug version. So far so good.

But then: starting gdb itself leads to a segfault. See screenshot.
How to proceed?

btw: there is dependency of gdb.tcz on readline7.tcz that is not listed in the .dep file.

[Rich]

Hi FlyingDutchman

btw: there is dependency of gdb.tcz on readline7.tcz that is not listed in the .dep file.

No, there is not. These extensions do depend on  readline7 :
Forum error, see attachment.

[FlyingDutchman]

Hi Rich,

If I install gdb.tcz and then run it, I get the message:

gdb: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory

A search with tce-ab indicates that libreadline.so.7 is provided by readline7.tcz. If I install readline7.tcz, gdb works. So I think there should be a dependency listed for readline7.tcz in the gdb.tcz.dep file.

[Rich]

Hi FlyingDutchman
I think you are right. gdb was last compiled under TC10 which used version 7 of readline. I will adjust the dependency file.

[Rich]

Hi Juanito
The dependency file for gdb has been updated for TC13 x86_64. TC12 contains the same files so I updated it too.