Hi, I have posted here about a problem I have been having with building a zImage for a 2.0.40 kernel.

I create a zImage then I copy that zImage to a floppy. When I boot from a floppy with that image I successfully get "Loading...................." but before the "Uncompressing Linux" message is displayed the machine reboots!

I wondered if any experienced forum members can remmeber possible reasons why the machine does the reboot before the Uncompressing.

I am currently using a bootable floppy disk which I successfully built a 2.0.40 bootable kernel in 2015 on that same machine, so something must be different now.

The bootable disks that I create, I have tried on a different machine and they behave the same way: The working disk works and goes through the bootup process and the fresh build attempts do the Loading..... but not the Uncompressing.

Thanking you in advance for giving this some thought.

Wow. 2.0 kernels is really bringing suffering on yourself. Have you seen this?
http://www.toms.net/rb

Tomsrtbt is a floppy based linux system. It formats a 1722k floppy ( or something like that) on a 1.44MB disk, and puts kernel, busybox, & all on there as a rescue disk. It saved my a** more often than I care to remember. Amazingly, it's still there, although floppy disks are not fitted these days.

Are you in a museum?

EDIT: The kernel may be 2.2x but you might find an old version on the site. I'm sure 2.2 will work for you anyway.

Are you using an initrd created for that kernel, (might be the way).

Hi thanks, will have a look over the weekend.

Hi, I had a look at some of those things to help.... I got hold of a Ubuntu Trusty and was looking into that.

.....with regards to my zImage...... I put a HLT instruction in the file bootsect.S where it has the jump to SETUPSEG. So I have confirmed it gets as far as that without anything going wrong.

I need to look into what SETUPSEG gets up to..... (i.e. what the file setup.S does)

Wonder if running tests on virtual machine or maybe better still qemu would speed up tests? Since you say it did work on that exact system we have to mostly assume that the floppy is bad.

Did you spend the 5 minutes making a tomsrtbt floppy? Does it boot on that?

This quite old kernel.

You may compile a kernel yourself relatively easily. Such old kernel, I am not so sure if it is stable.
The oldest one I compiled was the 2.4.x a bit like the DSL damn small linux.

In principle, it ought to work though.

In principle, yes; In practise, he'll be lucky. SOME of the issues I can see are
1. Module-init-tools (modprobe, insmod, rmmod, depmod) have changed teetotally
2. /etc/modprobe.conf is now /etc/modprobe.d
3. Glibc has changed drastically since then. Glibc is an essential part of the compiling toolchain.
4. The linux headers have shifted around, directories have been renamed, and contents are different.
5. Gcc has gone from gcc-2.x to gcc-5.x. For a long time, kernels were to be compiled with gcc-2.7.x (2.7.2 I think. This was a
l o n g time ago)
6. The isa bus has been obsoleted and I imagine neither libs nor includes on modern versions support it. He will probably need isa bus support.

This link ftp://ftp.heanet.ie/mirrors/slackwar...slackware-3.5/

is a link to Slackware-3.5, which has kernel 2.0.34. In those days the even numbers (2.0.x, 2.2.x, 2.4.x etc) were stable and the uneven ones (2.1.x, 2.3.x etc) were unstable or testing versions. If you install that to a spare partition, usb, or dvd, then you might have the equipment to make up your kernel. The KERNEL that's there might even serve your needs. The tgz packages are tar.gz. You can unzip and untar in your new root directory. Much better to use package tools. But the a1/aaa_base.tgz has all the / directories, so you can install that wherever it can be read. I don't think a /boot directory was common back then. Put the kernel in /.

Whether you can boot slackware-3.5 on a modern pc is another question. SATA was unheard of.

1 members found this post helpful.

Yes tomsrtbt will be helpful in an emergency.....I still have one working boot disk so am ok for the while. I have had a go at debugging the booting of the 2.0.40 kernel and I found the error happens upon reaching the following line in linux/arch/i386/boot/compressed/head.S (attached):

lss SYMBOL_NAME(stack_start),%esp

When execution gets here the system reboots.

Attached Files

headS.txt (3.2 KB, 10 views)

That's Assembler code. It would have to be assembled (i.e. turned into machine code). I've programmed in assembler but not on x86 & I'm not familiar with the lss instruction. The instruction is all variables which are included from (/usr/include)/linux/linkage.h, and/or (/usr/include)/asm/segment.h. I gave you a link for slackware-3.5. How did you get on with that?

I am just finding a machine to try the slackware 3.5 on. Unfortuantly I threw away my spare Pc a year or so ago. I have been looking at getting a spare partition on my current PC (the one with the SATA) or I was looking to get a 486 or base Pentium to try on.

[interesting!] fyi/fwiw idea: have a look at discussion of head.S lss here, p23-24

1 members found this post helpful.

Sorry - posted to wrong thread.

1 members found this post helpful.

Hi Business Kid.... I made some progress....I have obtained a COMPAQ 586 (with PCI and ISA slots!)
I used that Slackware 3.5 link you posted.....I installed Linux (although I got a large number of messages during setup about something not being in the index files and the setup not promising install will work) However install appeared to work...

I have compiled a working 2.0.34 kernel.... I just need to test it on my 486 now.


(For the install I made the bare.i and color.gz. I then copied Slackware 3.5 to a CD-ROm, ran setup form the bare.i/color.gz startup and pointed the SOURCE at the CD-Rom)