Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: lkraemer on May 26, 2009, 01:31:36 PM
-
Roberts,
I have been using Tinycore 1.42 on my older Compaq Presario 1672 K6-2 350 MHZ 192 Meg RAM with
a 80 Gig IDE Drive, and it boots and runs correctly.
I do get the following message when booting, but it continues to work.
ACPI Unable to load System Description Tables
IDE Generic IO Resource 0x1F0-0x1F7 not free
IDE Generic IO Resource 0x170-0x177 not free
But now with Tinycore 2.0 rc2.1, I get the following ERROR and system lockup.
IO APIC Resources cound not be allocated
Kernel Panic - Not Syncing: Attempted to kill init!
I don't understand the message, and would like to know if I will be able to continue
to use Tinycore on my OLD Compaq? Is this due to my older BIOS, or something
that can be fixed or bypassed?
Are there any Cheatcodes that would help me be able to continue to use later versions
of Tinycore?
Thanks.
lkraemer
-
Older computers used APM new ones use ACPI.
Try all the kernel commands to not use ACPI, e.g., noacpi acpi=off
You may want to consult the kernel boot options complete guide
http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/ch09.pdf
-
Also using the "debug" code will show all messages, might give more clue to why it happens
-
The DEBUG code didn't provide any other clue as far as I could detect.
APIC Resources not allocated, then the Kerenel Panic - Not Syncing! messgae.
And it locked up so I can't do a thing, except take a picture of the last screen.
I have also tried all the ACPI commands referenced in Chap 9. No Luck!
I tried the latest version 2.0rc3 and have the same problem. But version 1.43 seems to work fine.
I wish Version 2 worked the same as Version 1.43.
I've tried DSL, Puppy, TinyME Acorn, and really want to keep/follow Tinycore as it develops, if I can.
So far, it has worked fine until the Kernel Panic error on version 2.xx
Suggestions?
Thanks.
lkraemer
-
I have had the very same experience with my....very...old thinkpad 760 laptop (no cdrom) .
I can boot tc 1.4 (using linld from dos) ...but can not get tc 2.0 to boot...
kernel panic about half way thru....It fails right before is normally says...booting tinycore... I also tried lots of boot codes...no luck
I tried mix and match version 1.4 and 2.0 tinycore.gz and bzImage...will boot
(with errors) using bzImage 2.0 and tinycore.gz 1.4...but panic using bzImage1.4 and tinycore.gz 2.0.
My tc 2.0 download is good I think, because I can use the cd I burned it on to boot ...another desktop computer.
Would be interested in trying any suggestions....I really like version 2 on my desktop computer.
Note...when booting laptop with 1.4...my pcmcia cards are not automatically found during boot process...I have to modprobe i82365....to get pcmcia to work...don't know if that is relevant or not
G
-
APIC Resources not allocated, then the Kerenel Panic - Not Syncing! messgae.
And it locked up so I can't do a thing, except take a picture of the last screen.
I have also tried all the ACPI commands referenced in Chap 9. No Luck!
Maybe you're mixing APIC with ACPI, which are not the same thing? There are various boot codes for both APIC and ACPI...
-
OK, on Version 1.43 I see the following messages:
ACPI Unable to load System Description Tables
IDE Generic IO Resource 0x1F0-0x1F7 not free
IDE Generic IO Resource 0x170-0x177 not free
If I use the cheatcode acpi=off, I only get these two error messages, but Tinycore
continues to run perfectly, just as it does without any cheatcode.
IDE Generic IO Resource 0x1F0-0x1F7 not free
IDE Generic IO Resource 0x170-0x177 not free
But, on version 2.xx I try the following cheat codes, I see no differences in the booting,
and it still locks up at the Kernel Panic message.
apic=debug
apic=verbose
noapic
nolapic
noapic nolapic
acpi=off noapic nolapic
One interesting thing is that the latest version of Puppy boots fine, but I don't like it, and
don't want to use it. Same goes for TinyME Acorn, and DSL!
I'm posting this from Tinycore 1.43 on my OLD Compaq 1672.....NICE!
lkraemer
-
I didn't see this boot option in your list, does pci=noacpi help?
-
I am following this thread quite closely as I have the very same problem...same messages....same panic.....with my old laptop. (version 1.4 works)
I tried all the codes including pci=noacpi...
also tried rootdelay=3 (in case my old hdd was slow), nomce nousb noexec
and noirqbalance and finally irqfixup.
It looks like it panics just when it should launch tinycore
-
Just to be doubly sure - in the upgrade from tc_1.x to tc_2.x were both bzImage and tinycore.gz replaced?
-
I am not the originator of this thread...so hope I am not confusing the issue
but I have the identical problem...as i noted above
when I boot with version 2 bzImage and version 2 tinycore I get same panic and last
message as originator got
if i boot with version 2.0 bzImage...and version 1.4 tinycore.gz...it does not crash
... it gives the same "IO APIC Resources could not be allocated" message...but
it goes past that and thru "Booting tincycore" to desktop (there are some other messages
but it does not crash).
I don't think APIC...... is the problem
the unsuccessful boot with version 2 bzimage and version 2 tinycore does not get to the green line
that says "Booting tinycore"
-
@gwalther, I suggest you also use the "debug" code and see if there's anything relevant
-
Using "debug" boot code... trying to boot version 2
this is the last the last several messages
RPC: Registered udp transport module
RPC: Registered tcp transport module
IO APIC resources could not be allocated
Using IPI No-Shortcut mode
Freeing unused kernel memory: 344 freed
Kernel panic - not syncing: Attempted to kill init!
some time later get this message
Clocksource tsc unstable (delta = 70011540 ns)
did not notice anything else of note during boot sequence
-
gwalther, now I'm following along.......Glad to have the extra set of eyes, and the help.
I searched today and found crunchbang that was supposed to work on older machines.
I burned the ISO and it boots fine and runs. I get a message about ACPI and BIOS age being
1999 older than >2000, and it uses the ACPI=force and then boots fine. I didn't make a
note of the Kernel Version.
I tried ACPI=force with Tinycore 2.xx and it did not help.
lkraemer
-
@ Ikraemer
try boot codes.......debug initcall_debug
I get the following messages just before the panic
async_waiting @1
async _continuing @ 1 after 11 usec
what do you get?
trying to figure out what this means
g
-
followup to previous post using ..boot code...initcall_debug
i used this boot code and version 1.4..... to compare to what i get with version 2
all the same messages as near as i can tell until the point at which it panics in version 2.0
version 1.4 follows with green message..."booting tinycore
so ...looks like something bad is happening at loading or start of tinycore
-
gwalter, I get the exact same messages you're getting.
Photo #1 is with debug only.
Photo #2 is with debug initcall_debug
I did download Slitaz 2.0 and it boots and runs fine......and if I understand correctly
the origin of Tinycore is from Slitaz. INTERESTING!
lkraemer
-
Here is photo #2.
lkraemer
-
looks the same......maybe .....new and future versions are never going to play well with our old pre 2000 girls (ie. laptops) regadless of what we do....my laptop is older and slower then your s ( P120...64mb...no cdrom...no usb....720mb hdd)... don't think it is lack of memory ...... that's the problem....since you have much more......something at the start of tinycore.gz!!!!!...maybe it can't find image....no when I use version 2.0 bizImage it will find version 1.4 tincycore...got to be at the start of version 2 tinycore before it puts out message..."booting tinycore"
my old girl does boot and run ok with "damn small linux"...actually with frugal install and opera.uci it is an ok lite web browser...which was goal in trying small distros...I .just like tinycore size and idea more (I run tinycore version 2 on a old desktop and am really starting to like it more and more ...in fact using it for this reply...I even got wireless and Xorg finally working...after quite a long learning curve)
don't want to give up....but
G
-
The major change in v2 is the upgrade in kernel.
It is really not too interesting to compare with other distros even ones that boot in similiar fashion, unless we are talking about the same kernel version.
Googling "2.6.29 kernel panic acpi" appears to further suggest the kernel version.
-
Are you able to compile the kernel? It would be worth a try to check if the latest 2.6.29 boots properly.
-
curaga,
While I don't know the capabilities of gwalther, I have never compiled a kernel........but, saying
that, if I were to have good instructions, and be led by someone who has done it before, I am
willing to try. I have several questions that need to be answered before I start:
1. What software needs to be installed for the Kernel compile? All my Linux systems are 32 bit.
2. Can I compile the kernel on my Ubuntu 8.04 LTS Desktop for Tinycore? Or do I have to
use the old Compaq 1672 for that?
3. If and when I get the kernel compiled, what are the next steps, for installing/testing with
my Tinycore LiveCD?
It seems to me that a Tinycore Developer would compile the latest test kernel, and upload it where
gwalther and I could download it and follow a testing procedure to do some beta testing on our older
systems. That makes much more sense to me, and it frees you up from having to answer stupid questions.
lkraemer
-
Yes, I thought that would be likely, but it never hurts to ask ;)
http://www.ziddu.com/download/4947749/bzImage-2.6.29.4-tc-test.gz.html
This is the latest stable kernel, compiled with TC config but removed a lot of things (module, networking support among other things :P) to make a fast build. It's only to test whether you can boot TC with it, and is likely to not be usable if it boots.
How to test - download, gunzip, and replace the bzImage of TC with this. Do take a backup of the old bzImage before this. Boot.
If you need to burn a CD, see the wiki on remastering for the mkisofs command.
-
I tried the test bzImage from the quoted site;
(note I boot from dos using linld097)
heres what happened:
Test bzImage and version 2 tinycore.gz
kernel panic at almost same spot as previously seen...I did get this one additional message:
Input: AT Translated Set 2 Keyboard as /devices/platform/i8042/serio)/input/input0
Test bzImage and version 1.4 tinycore.gz
booted all the way thru with some additional messages about missing 6.29 libraries
I saw the message I noted above in the panic boot .... Input: AT.etc......just before the green line saying "Booting tinycore" on this successful boot
I used boot code .........initcall_debug......so got lots of messages
-
Okay, so the kernel bug is still there for you gwalther. There's nothing we can do about it, I can only point to the kernel documentation (kernel-parameters.txt) and hope there's some option that can make the .29 kernel work with your hardware.
-
Thanks for all the suggestions!
At some point I guess you have to admit your gear is just too old and move on.
G
-
These things happen every once in a while, for example 2.6.21 would just not boot on one of my laptops. Since debugging the regression was (and still would be) out of my skillset, I waited some kernel versions and things started working again. When the next kernel update happens for TC, that would be a good time to retry on your hardware :)
-
I've run into exactly the same problem like gwalther ... but having fallen in love with TinyCore ;-) i just don't want to give up before having understood what is _rearly_ happening here.
So I would deeply appreciate if you like to answer my questions:
1) Why is the 2.6.29.x kernel _itself_ supposed to be the cause of the panic though it is able to boot with the 1.4.3 version of the tinycore-initramfs ?
Afaik the kernel _modules_ contained in this initramfs are associated with the older 2.6.26.x kernel so that they can NOT be employed by the newer .29.
This also implies that the newer .29 is able to boot "out of itself" only supported by some of its own _built-in_ modules ... what indeed works with my fairly ancient notebook.
2) Why are you not concerned about the 2.x version of the tinycore-initramfs ?
Because only when this newer initramfs is used the panic occurs ...
3) Could you perhaps give me some hints if at all and then what i might try to change in the (already extracted) initramfs to cope with the panic ?
I already took a somewhat deeper look into tc-config of TC 2.x as the initial starting routine ... but up to now i could not dig out a difference compared to this routine of TC 1.4.3 which seems big enough to cause the panic ...
-
Hardware details?
1) We have now three reports in this thread with the same symptom, but they might all be different causes. Only one confirmed that the older initramfs boots. This could be hardware failure, kernel bug, gcc bug. Run memtest86+ just in case?
2) The K6-2 is a very... delicate processor. It's supposed to be a full 686, yet 686 code sometimes doesn't run on it. I've seen it myself, as well as a Via C3 not running 486 code despite being a 586.
About the Pentium laptop, it could be bad ram or something else.
3) Please post more info; your hardware, anything interesting in debug/initcall_debug messages?
-
Ooops, of course I should have detailed my hardware, i.e. what I mean by "fairly ancient notebook" :
Toshiba Satellite Pro 410CDT dated from 1996 =:o)
Pentium 90 MHz
40 MB RAM (max. equipped ;-)
60 GB E-IDE HD (70x the capacity compared to the beginning)
no CD-ROM ... but fortunately a 16-bit PCMCIA Fast-EtherNet-Card
BIOS: PnP 1.0a, NOT supporting Int 13h Extensions (LBA)
(... which means that the BIOS (and "legacy" GRUB) is only happy if the
HD has a /dev/hda1 of only 16MB inhabiting the /boot partition
... once having booted Linux and Win98 feel fine with additional /root and /home partitions
... but that's another quite lengthy story ...)
The minimum memory required during boot had risen from 32MB with TCL2.0 to 48MB with TCL2.1, which breaks my above mentioned RAM limit :-(( .
So I concentrate on TCL2.0 at first ... being aware that for all following TCL releases I would anyway have to fix the initramfs tinycore.gz .
Meanwhile I've tried to dig even deeper :
To get a thorough _comparison_ between
TCL2.0 booting badly to a kernel panic
and
bzImage-2.0 + tinycore-1.4.3.gz booting nicely in this combination
I implemented a _serial_ terminal connection between the "culprit" and my Ubuntu desktop pc
(1) connecting a Null-Modem-Cable between both serial ports
(btw. 3-wired was sufficient compared to lots of oversized proposed Null-Modem-Cables www...)
and
(2) setting up an appropriate GRUB's menu.lst on the "culprit" and employing minicom on Ubuntu desktop pc
(It just took a couple of hours till working smoothly ... incl. restoring my old soldering iron to life again ... ;-)
The entries in my grub's menu.lst give rise to the highest possible level of debugging :
title TinyCore bzImage-2.0 + tinycore-2.0.gz + debugging to SERIAL CONSOLE
kernel (hd0,0)/boot/bzImage-2.0 noscsi nousb noagp nofirewire acpi=off pci=off S debug loglevel=7 initcall_debug console=tty0 console=ttyS0
initrd (hd0,0)/boot/tinycore-2.0.gz
title TinyCore bzImage-2.0 + tinycore-1.4.3.gz + debugging to SERIAL CONSOLE
kernel (hd0,0)/boot/bzImage-2.0 noscsi nousb noagp nofirewire acpi=off pci=off S debug loglevel=7 initcall_debug console=tty0 console=ttyS0
initrd (hd0,0)/boot/tinycore-1.4.3.gz
Note: I just renamed the kernel and initramfs files with version suffixes to keep track of all the combinations I already tested ...
Attached is the comparison generated by
diff -yW 200 minicom-output-file-of-bzImage-2.0+tinycore-1.4.3.gz-booting minicom-output-file-of-TCL2.0-booting
Result :
Aside their different execution times all the initcalls are identical - even if their return code is _NOT_ 0 !
The combination of bzImage-2.0+tinycore-1.4.3.gz is even successful despite of FATAL errors due to missing an appropriate modules.dep file !
Immediately after the line "Freeing unused kernel memory: 344k freed" BusyBox' init process starts on the "exotic" combination side while a Kernel panic occurs on "standard" TCL2.0 side :-((
calling 0xc0499c01 @ 1 calling 0xc0499c01 @ 1
initcall 0xc0499c01 returned 0 after 22 usecs initcall 0xc0499c01 returned 0 after 22 usecs
async_waiting @ 1 async_waiting @ 1
async_continuing @ 1 after 17 usec async_continuing @ 1 after 17 usec
Freeing unused kernel memory: 344k freed Freeing unused kernel memory: 344k freed
init started: BusyBox v1.13.3 (2009-03-18 12:08:31 PDT) | Kernel panic - not syncing: Attempted to kill init!
starting pid 40, tty '': '/etc/init.d/rcS' <
Booting tinycore_1.4.3 <
Running Linux Kernel 2.6.29.1-tinycore. <
Starting udev daemon for hotplug support...input: PS/2 Generic Mouse <
Done. <
Boot options checked. <
As you may imagine I'm somewhat helpless now ... =o-/
Any comments, hints, advice are welcome !
[attachment deleted by admin]
-
fellow, that was an amazing story to read. I completely agree with your analysis: the source of the problem is not the 2.6.29 kernel by itself, but "something" in the initramfs ( = tinycore.gz).
Here is my take. Everyone reports the same error message: "Attempted to kill init!" That looks very familiar. I get that message when I play with custom initramfs files and introduce a typo or "thinko" whereby the kernel cannot pass control to the init process after it (the kernel) is done with its own stuff.
That makes me think that the "init" program in TinyCore 2.0 is (somehow) the culprit. "init" in TinyCore 2.0 is provided by Busybox 1.13.3; TinyCore 2.1 upgraded to Busybox 1.13.4. Looking at the Busybox website, major bugfixes have been applied between 1.13.3 and 1.13.4, including this one: "init: major improvement in documentation and signal handling. Lots of nasty, but hard to trip, races are fixed."
I therefore suggest that you stop concentrating on TCL2.0, and try a more recent version instead. I know, the Wiki says that 48 MB RAM are required for TinyCore, and your machine has only 40 MB. It's worth a try nevertheless: first, using the "embed" boot code, I can boot even TinyCore 2.7 in a virtual machine (QEMU) with 40 MB; second, you could use MicroCore instead of TinyCore, simply to see whether the Busybox version is a factor or not.
-
I have an eBox 2300 with the SiS processor that has the same problem. Here is what Itried.
Boot 2.8rc2 - Error
Boot 2.8 with 1.4 initrd - boots
Boot 2.8 with 1.4 initrd with 2.8 modules added - boots
Boot 2.8 with 1.4 initrd with 2.8 modules and 2.8 busybox - boots.
So it apparently is not the 2.8 kernel, the 2.8 modules, or the 2.8 busybox.
-------------------------------
After further investigation I found the problem to be with libc.so and ld-linux.so.
Copying those 2 libraries ( and symlinks ) from V 1.4 to V 2.8 allows V2.8 to finish loading.
Copying libresolv.so allows nfs to mount, and all my extensions to load.
There are still GLIBC errors reported, but that is expected.
The problem appears to be some change in libc and/or ld, or in the way they were compiled.
-
Using the bootcodes "base norestore embed nofstab noswap" you can really drop the minimum memory requirement, at the expense of functionality.
Hmm, thanks for the info gerald_clark. Let's see what Juanito says.
-
I compiled libc in tc-1.x in pretty much the same way as in tc-2.x - the version of libc and gcc is different in both cases, so it's kind of hard to know what exactly the problem is.
I know in other threads some users have found errors in exception handling with apps compiled with the tc-2.x version of gcc, but this seems to be quite rare. The are no doubt some bugs with the libc version used in tc-2.x, but they don't show up on any hardware I have.
Let me think about this a while.
-
When you mention libc.so, ld-linux.so and libresolv.so, I take it you're speaking of:
/lib/libc.so.6 -> /lib/libc-2.9.so
/lib/ld-linux.so.2 -> /lib/ld-2.9.so
/lib/libresolv.so.2 -> /lib/libresolv-2.9.so
Looking at /usr/lib/libc.so, there is a small difference between the versions: [new]
$ cat /usr/lib/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) )
[old]
$ cat /usr/lib/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
..but this is not in the base, and I can't imagine it would make a difference anyway.
I double-checked my notes and libc was compiled for use on i486 and up.
-
It's possible it's a gcc bug as well, gcc might have let 686 code in.
-
Many thanks for all your precious replies !
Frank and gerald_clark with your input I can now confirm that the panic error does _NOT_ come from the 2.6.29 kernel by itself :
I've customized both initramfs files of MC 2.7 and TC 2.7 by copying libc.so , ld-linux.so and libresolv.so INCLuding the respective symbolic links from TC 1.4.3
(thereby learning from gerald_clark that one must not always create a new symlink but may just COPY over :-)
Then I just remotely edited my notebook's GRUB menu.lst "on the fly" sitting in front of my "serialized/terminalized" Ubuntu desktop (remember my previous post ;-)
( having learned from Frank that the boot option 'embed' had been made available to stay on initramfs,
i.e. to skip the usage of tmpfs in the init script preceding BusyBox' init )
FIRST trial with fixed _M_C 2.7 initramfs
kernel (hd0,0)/boot/bzImage-2.7 embed noscsi nousb noagp nofirewire acpi=off pci=off S debug loglevel=7 initcall_debug console=tty0 console=ttyS0
initrd (hd0,0)/boot/microcore-2.7-with-TC1.4.3-libs.gz
==> BOOOOOOOTed and worked like a charm !!!
SECOND trial with fixed _T_C 2.7 initramfs
kernel (hd0,0)/boot/bzImage-2.7 embed noscsi nousb noagp nofirewire acpi=off pci=off S debug loglevel=7 initcall_debug console=tty0 console=ttyS0
initrd (hd0,0)/boot/tinycore-2.7-with-TC1.4.3-libs.gz
==> Booted "almost" up to the end ... but finally experienced segfault errors
Setting keymap to us Done.
login[1769]: root login on 'tty1'
esetroot[1843]: segfault at 43434704 ip b7fbde5b sp bfdc77f0 error 4 in ld-2.3.6.so[b7fb2000+14000]
flwm_topside[1841]: segfault at 43434704 ip b7f77e5b sp bf87f240 error 4 in ld-2.3.6.so[b7f6c000+14000]
wbar[1846]: segfault at 43434704 ip b7fdbe5b sp bfde29d0 error 4 in ld-2.3.6.so[b7fd0000+14000]
==> with Ctrl-Alt-F1 I can reach the text console and continue "normal" working in the _C_UI
==> so the old loader ld-2.3.6.so stemming from TC 1.4.3 seems not to be in harmony with _G_UI stuff
==> Questions to gerald_clark
(1) Is it this what you meant by "There are still GLIBC errors reported, but that is expected." ?
(2) Could you please give me/us some hints of your systematic approach in finding out what libs the culprits are ?
THIRD trial with fixed _T_C 2.7 initramfs and a CUSTOMIZED and even NEWER kernel 2.6.30.10 from kernel.org + patched with SLICES of the TC-patch
kernel (hd0,0)/boot/bzImage-2.6.30.10-tc-patch-adapted embed noscsi nousb noagp nofirewire acpi=off pci=off S debug loglevel=7 initcall_debug console=tty0 console=ttyS0
initrd (hd0,0)/boot/tinycore-2.7-with-TC1.4.3-libs.gz
==> Booted "almost" up to the end ... SAME result as in SECOND trial (as expected ;-)
It's fantastic to see once again the Core Team members, in this case curaga and Juanito, doing a perfect work, caring that much about the users and being accompanied by such an invalueable community !
It's a real pleasure being with you on board !
-
To find the libraries causing the problem, I ran ldd on busybox ( the suspect program ).
I then replaced the libs in various combinations from 1.4.
The libc and ld-linux were both needed to allow the system to complete booting.
The libresolv was needed to get some of the other utilities not to core dump.
There are still some library incompatibilities that cause some programs to fail, but this
was just an exercise to determine the root cause of the boot failure.
We now know it is not a kernel problem, but a problem in the libraries.
Whether it is a library source or a compiler bug is not yet known.
-
gerald_clark, I just want to say thank you for explaining your evident procedure (finally with wikipedia's help I even remembered the meaning of core dumps :-))
I'm eagerly looking forward to what the investigators will discover ... thanks in advance !
-
Dear members of the TinyCore Team
would you be so kind and give us, i.e. the folks being unfortunately somewhat locked out by this (not kernel but ;-) lib or gcc caused panic, some prospect of what you plan or even are about to do in curing us from this issue ...
I hope that you will take this request not as some kind of demand but as our hope that we too are further-on able to participate and contribute to this unique TC/MC-project and its lovely community.
Is there perhaps any additional information and/or examinations you would need to be delivered by the affected users ... of course just let us know.
To be honest I'd like to append :
Though I've already succeeded a couple of times to build a customized kernel it seems to me being a far more challenging enterprise to cope with the specialties of the various envolved libraries or the last touches of the compiler options (at least I got this impression when looking into a huge book belonging to those topics ;-) ...
Thank you very much in advance for considering this issue !
-
About the best thing I can think of at the moment is to recompile libc and/or gcc when we get to tc-3.
I'm a bit stuck as I do not have an i486 or i586 to test with.
-
Is there perhaps any additional information and/or examinations you would need to be delivered by the affected users ... of course just let us know.
Thanks, but your efforts have already pinpointed where the issue is.
-
Juanito, curaga, thanks for your replies.
Just to assure that I got your points right ( and my learning curve may go ahead ... :-) :
(1) Recompiling the core's libs can not be done under MC/TC itself ( + compiletc.tcz etc. ) but only on your specific IDE which regularly generates MC/TC ?
(2) To find out the correct set of options to be fed into the gcc command line for recompiling the libs may not be sufficient ... ?
(3) ... even the gcc source package _itself_ may have to be recompiled ( again in your IDE ? ) to get rid of possibly sneaked-in i686 code ?
(4) I hope you will indulge me in posing the ( unavoidable ;-) question, if a GROSS prospect could be given of the appearance time of tc-3 ?
-
1 - no, they are done under TC/MC and should be. It's just that you cannot upgrade in place, you have to store them somewhere, upgrade offline, and boot with the upgraded files to test.
2 - sometimes it requires magic incantations and sacrifices
4 - there have been some hints dropped at the fora ;)
-
Okay ... I got that with the base' libs.
Aside the TC Team's professional work there seems to be some need for outside mysterious support :o ... I hope the "sacrifices" will not be that sort of bloody ones ;D ... because we can't afford to lose any of our precious administrators :)
But nevertheless the new word "incantation" will further elaborate my english code.
I'm still somewhat confused concerning gcc's role in this issue :
One needs gcc.tcz, gcc_libs.tczl, and quite a few more tcz to re-build the base libs ... but what if the anomaly originates from gcc(_libs) itself ... ???
Unfortunately up to now I couldn't find any of those revealing "hints dropped" ... you don't accidentally remember a respective link ...
-
In the first half of 2010, would be an accurate estimate :)
-
I'm still somewhat confused concerning gcc's role in this issue :
One needs gcc.tcz, gcc_libs.tczl, and quite a few more tcz to re-build the base libs ... but what if the anomaly originates from gcc(_libs) itself ... ???
The gcc_libs are just the libs created when gcc is complied, but split out from the rest of gcc as several extensions require them and it would be a pity to load all of gcc for just a couple of libs.
I recompiled gcc(-4.2.2) yesterday and will have a look at recompiling libc - this being said, libc and the kernel were originally compiled with tc-1.x, so recompiling libc with tc-2.x might bring other issues.
-
For what it is worth, I rebuilt both glibc-2.9 and built glibc-2.10.1 with the standard gcc-4.2.2 and neither would boot on my amd k6 machine.
-
Glibc-2.9 from Slackware works (boots) beautifully with TC-2.9rc1 on my k6 that will not otherwise boot.
Looks to be an issue with GCC if I was to guess, as "-march=i486 -mtune=i686" is also used to build Slackware's glibc. Slack uses gcc-4.3.3 along with glibc-2.9.
-
Yeah - I'm coming to the conclusion that it's some kind of gcc-4.2.2 bug
-
Good suggestion Jason.
I built a glib2.cpio.gz that contains replacement libraries and ld.so.cache.
I load this as an overlay during boot.
Now my eBox-2300 with the SiS Vortex86 SoC is happily running 2.9rc1
-
very good news; is there a possibility to get the glib2 initramfs? i have two machine which i would like to boot with tc/mc 2.9rc1 but i can't do it because of this issue with gcc
-
It is 4M.
It replaces core libraries, so it doesn't increase the loaded system size much.
I don't know if the Forum moderators would want an attachment of that size here.
-
This issue is being worked on by the team and a fix may be available soon. Let's hold tight for now.
-
Sounds good.
My mistake ... only 1 Meg.
Official fix will be better.
-
great thanks
-
No more kernel panic!!!! ...problem solved for me.
Just tried tinycore 2.9rc4 and it booted. This is the first tinycore 2.x that did not kernel panic on my old laptop......outstanding work tinycore team!
My old,old laptop is a thinkpad 760c...p120..64MB...no USB ports. I do not have a cdrom so I boot out of DOS/WIN98 using linld097.....it's working
-
I almost can't believe it ... finally you brave guys succeeded in spending another linux life to my fairly ancient notebook (http://forum.tinycorelinux.net/index.php?topic=1685.29) :D
Encouraged by gwalther's latest post I also gave TC2.9rc4 a try using embed and xsetup as boot options ...
Both my notebook and TC booted so smoothly as if they had fallen in love with each other ::)
To get access to the online repository by appbrowser I still had to manually fix the pcmcia/ethernet/ip/dhcp stuff by
modprobe i82365
ifconfig eth0 up
udhcpc
Did I get the right clou, i.e. gcc's version 4.2.2 seems to have a bug and you already employed its newer version 4.3.3 since TC2.9rc4 !?
Many many thanks to all of you participants !
-
Did I get the right clou, i.e. gcc's version 4.2.2 seems to have a bug and you already employed its newer version 4.3.3 since TC2.9rc4 !?
The error was caused by the way glibc-2.9 had been built causing it not to boot on (at least some) i486/i586
-
Thanks juanito for analysing and fixing this issue so soon.
Would you mind to reveal more precisely what you mean by "the way" ... was it a certain compiler option/value ... or some pre-processing directive in glibc ... or ...
You know my learning curve is somewhat curious about the details ... and if possibly curaga had to utter his "incantation" at the end ;)
-
Would you mind to reveal more precisely what you mean by "the way" ... was it a certain compiler option/value ... or some pre-processing directive in glibc ... or ...
echo "CFLAGS += -march=i486 -mtune=i686 -pipe" > configparms
../glibc-2.9/configure --prefix=/usr i486-pc-linux-gnu --disable-profile --enable-add-ons --enable-kernel=2.6.16
"i486-pc-linux-gnu" was missed previously
-
I'm attempting to test tinycore on some older machines in a computer lab in a retirement communitywhere I volunteer. I'm running into the kernel panic issue described in this thread. I downloaded the iso I'm using within the last week--it's called tinycore-current.iso. Once I read about this issue in this forum I began looking for the rc 4 release but have so far not managed to find any download so labelled.
So, where can I find 2.9 rc 4? Or for that matter any other release candidate with the kernel panic patch applied? The release candidates directory appears to be empty. Input will be appreciated.
Thanks,
James
-
You need the current release - either microcore-2.9 or tinycore-2.9
-
Thanks for the reply, Juanito. Given what you're saying, then, do I understand correctly that, since I downloaded within the last week the iso labeled tinycore-current.iso (found by following the link labeled "Current Release" from the tincore web site), I already have 2.9 rc 4 or later? That would not be very good news: I'm having the problem discussed in this thread, despite using a supposedly patched version.
If I am using the most current version and still have the kernel panic issue described in this thread, what are my options for testing tinycore on these older machines? Should I try an older release? If so, which?
Also, just out of curiosity: why is the release candidates directory empty?
James
-
2.9 was released the evening of March 2nd.
If you downloaded 'current' before that, you got 2.8.
Download 2.9.
-
Thanks for your input, gerald_clark. Just one point of clarification, though. There are two files in the "Current Release" directory that seem relevant, but I am uncertain which corresponds best to your directive. The two files are labeled tinycore-current.iso and tinycore_2.9.iso. Which of those two should I get? I assume both are 2.9?
James
-
Not wanting towait any longer for an answer I went ahead and downloaded anew tinycore-current.iso and burned that to CD. The old computer booted fine with that one, no kernel panics occurred.
Thanks,
James
-
"tinycore-current.iso" is simply a symlink to the latest release which is now "tinycore_2.9.iso" The symlink would have been updated at the time of the release on the evening of March 2nd.
-
Just to say that I have installed Tc 2.10 on an old Pc (it boots from the hard disk using grub). I get the kernel panic just after the APIC message. However the same Pc boots fine from the Tc 2.10 CD. Puppy and a number of other puppy based cds boot fine from the cd, I haven't tried putting any of them on the hard disk to see if they produce the panic.
-
Hi,
First post here :)
I have some problems with the latest stable TC on an old Compaq Deskpro @ 166MHz / 160Mb RAM, which I'd like to turn into a small print server...
It boots fine from the live CD, but once installed I have the following issues:
with debug=on I can see that there is a problem with the RAMDISK (incomplete write, write error) and kernel panic - not syncing: VFS: unable to mount root fs on unknown block (8,3).
I can go past this error with root=/dev/hda2 but then I have another issue: "unable to open an initial console" kernel panic not syncing: no init found :(
What am I doing wrong ?
Bye and thanks for your help !
Magic Sam
EDIT: I have tried **A LOT** of boot options, to no avail :(
-
What is your exact boot line?
Is that in default mode?
-
Hi tinypoodle :)
Thanks for helping me !
My exact boot line is:
kernel /boot/bzImage quiet
initrd /boot/tinycore.gz
As explained in the installation tutorial :)
Magic Sam
-
Check the md5sum of the initrd, it could have been corrupted (against the one on the cd, and http://ftp.nluug.nl/pub/metalab/distributions/tinycorelinux/3.x/release/distribution_files/tinycore.gz.md5.txt if it's the latest one). Could also be the HD is getting faulty.
-
You could change 'quiet' to 'debug' to try to get more detailed output.
If I understand right, root fs should not be any storage partition, at least not when running TC in default mode.
Edit:
Try adding boot parameters
norestore
base
-
Try adding boot parameters
norestore
base
It didn't change anything :(
EDIT: @ curaga: you were right about md5sum :) The one from the official FTP matches the one on the CD, but the one installed on the hard drive is totally different ! What does it means and how do I solve this ?
Thanks a lot ! Magic Sam
-
If comparing md5sums - as suggested by curaga - of initrd shows that they are identical, then do the same with bzImage
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release/distribution_files/bzImage.md5.txt
-
Could also be the HD is getting faulty.
or similar with RAM?
Edit:
This and preceding post are no longer of direct relevance to specific case after the edit of earlier post of OP.
Leaving them here just for future reference of troubleshooting in general.
-
EDIT: @ curaga: you were right about md5sum :) The one from the official FTP matches the one on the CD, but the one installed on the hard drive is totally different ! What does it means and how do I solve this ?
Thanks a lot ! Magic Sam
It means tinycore.gz on your hard drive is corrupted. Try copying it again from the CD.
You could scan the HD with the manufacturer's app for defects (Hiren's includes many of those), to get an image how bad it is.
-
You could scan the HD with the manufacturer's app for defects (Hiren's includes many of those), to get an image how bad it is.
Also with 'mhdd' - independent of manufacturer - which might be included on Hiren's or otherwise is available as bootable floppy or CD image.
-
IT WORKS !!!
I've copied tinycore again, checked its md5sum and this time it matched !
Now the computer boots and works like a charm !
Thanks a bunch guys for your help, it's very much appreciated :)
I guess I'll need your help again when I will set up the print server: CUPS + Foomatic + GUTENPRINT + PPD files = HELL ON EARTH ;)
Bye and thanks again, Magic Sam