Tiny Core Linux
Tiny Core Base => Corepure64 => Topic started by: FlyingDutchman on March 13, 2022, 07:21:03 AM
-
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.
-
Have you checked the md5sum for corepure64.gz and vmlinuz64?
Edit: from a successful boot: $ dmesg | grep -i initrd
Freeing initrd memory: 12492K
-
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?
-
google suggests:
The solution is to add "udevchilds=64 udevtimeout=600" kernel boot codes
-
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.
-
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?
-
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
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Hi Juanito
The dependency file for gdb has been updated for TC13 x86_64. TC12 contains the same files so I updated it too.
-
Try to get a core dump, which you can then view on TC12. I think you do it by setting the core limit to unlimited with "ulimit".
-
The dependency file for gdb has been updated for TC13 x86_64. TC12 contains the same files so I updated it too.
gdb updated in the 13.x x86_64 repo
-
I am late to this part, but I have been playing on a HP t520 thin client with no issues.
My install process was to download the latest CorePure64-13.1.iso and render that to a USB stick with rufus-3.18. The thin client came right up off the USB stick and I had to tce-ab to grab the tc-install and put it on the ssd in the t520. I had to manually add the realtek drivers for the nic but that was the only major speed bump so far. Fingers crossed. Did you run the diags on the thinterm to make sure the hardware is all happy?
-
Yours is an AMD processor, so it's not related to the Via issue here.
-
for the curious amongst us:
https://www.bhphotovideo.com/c/product/1331258-REG/hp_g9f02at_aba_tiny_client_t520_gx_212_jc_4gb_8gf_smart_zero32.html
just grabbed a decent random webpage regarding the HP T520
sharing is caring