Nothing happens after freeing kernel memory

Hello,

I am trying to set up an X-Terminal, but I cannot get my initrd to boot. As filesystem I use cramfs. The tools used are linux-2.4.34.1 and busybox

1.5.0. The same image as an ext2 image produces the same error (who knows where to get an mkfs.minix for Fedora Core 6 ?)

Busybox's init is configured to read an /etc/inittab and the initrd's /dev/ is populated with console, tty*, hda*, hdb*, null, kmem, mem, zero, ram* and more. But even if I specify init=/bin/sh, nothing gets run; not even if I compile a Busybox with only ash and want to run it. Busybox runs happily on the host system (Athlon 1700+, Fedora Core 6).

"uname -a" on the host prints out "i386", so I compiled BusyBox on the host system against the host libraries and copied these from /lib/ into the image. But I think nothing is run at all.

The kernel is booted via LOADLIN using the following line:

loadlin bzImage initrd=rootfs root=/dev/ram ro [init=/bin/sh]

The complete bootlog can be seen at:

formatting link
(100 KB)

Do you know why the system doesn't do anything after mounting root?

Regards, Sebastian

Reply to
Sebastian
Loading thread data ...

Try compiling a statically linked bash for i386, copy it into the ramdisk image and try running that with init= ?

Confirm the result is what you expect using the 'file' utility.

For bash 3.2 .....

#./configure --enable-static-link --build=i386

# file bash bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux

2.2.5, statically linked, not stripped #
Reply to
Unknown

That works, strange.

The same. But when I try to run Busybox, the system just hangs. Do you think the libraries are compiled for i686 and don't run on that processor? BusyBox can't be built statically against glibc.

Do you know about some howto about creating an "embedded" distribution (I need Busybox, XF86_S3, Kernel and maybe more) ? Best would be to have it built against some smaller library than glibc.

Regards, Sebastian

Reply to
Sebastian

Sebastian,

the reason Mr. Unknown has asked you to statically link bash is because the resulting binary is independent of the rest of your embedded file system. It bypasses any library problem you may have.

In a nutshell, the C library (glibc, uclibc) must match the one used by the compiler. What you have probably done is compiled busybox against your host's C library which is different from the one on your embedded filesystem.

I would recommend you look at Buildroot. It's a build system which first produces a cross-toolchain, by default based around uclibc. It then uses this toolchain to build Busybox and whatever other programs you select and packages them into a consistent embedded file system.

Kind regards,

Iwo

Reply to
Iwo Mergler

Is it ? Compiling a set of libs with busybox and creating a ramdisk image that works is IMHO non trivial. If in doubt remove dependency, kernel + static bash is a good starting point to test things, its difficult to debug if it just locks up !

Find out with the 'file' command - Doh ! See previous posting, try it - its worth its weight in gold......

BusyBox

Have you run ldconfig on the libs in the correct way to make a happy set of libs ?

I doubt its a size problem, its probably not a valid set of libs for the arch.

Consider building an NFSroot kernel image and using the target itself to build the final linux image (if it has enough RAM). When your finished you can squash it back down and create a stand alone image from it.

I don't know of any howto, i've just had to blindly feel my way through it, I still would not consider myself an expert......

Cheers, Jon

Reply to
Unknown

Hello,

ramdisk

Yes, that's right. What Iwo Mergler wrote is also very helpful to me. I did create some initrd's before, and they worked. But then I used Debian Woody's host libraries. I don't have the knowledge to do a "clean" job about it. But why doesn't it even give out some kind of message why it failed? Can't the kernel cry out if it can't run init?

think

I will do it, but can't right now.

Umm, no. But all needed libraries are found in /lib; this worked for me always. I don't know if other pathes are searched (apart from /lib and /usr/lib). Busybox complains if I try to build it static. ldd gave me a list of libraries and I copied them to /lib. Can libraries depend on each other (even if the binary doesn't need both) ?

(I

The architecture is kind of i486. But my guess is, that if I compile the target's tools using uClibc or something like that, these binaries can't run on my host system. That would force me to divide strongly between host and target binaries.

I could use chroot and have it easier. NFS root doesn't work for me, because most of the time development is inside a virtual machine. It can connect to the internet, but not the other way round.

Same as I did. But there are many questions...

Regards, Sebastian

Reply to
Sebastian

(I

Yes, that's possibly why it works then. But Busybox complains if I try to compile it against glibc (which the host system uses).

You are right there, too. But I copied the host libraries to the target, as I did before. Although, as I've written to Mr. Unknown, I used different host libraries (Debian Woody instead of Fedora Core).

I tried it, but sometimes it won't compile through and leave me with some cryptic error message. Another problem for me is the fact that it takes ages to compile it through... lastly, I have no idea how to build XFree86 3.3.6 with my new toolchain (apart from linking my -gcc to gcc and have it as first item in $(path) ). I can't use any newer version of X, because the graphics chipsets are not supported anymore (wd90c24-compatible; S3 Aurora64 with 2D-acceleration).

But I need different programs than these supplied with Busybox; how can I compile them? I don't see really through the library system (yet), although I learn more and more every time I fail of whatever reason.

But thank you for your answer and kind regards,

Sebastian

Reply to
Sebastian

The kernels I use do ! You get an "init not found" kernel panic, if thats not the case then init has probably started (or at least loaded and crashed!) but is not able to do useful work - missing or malformed /etc/inittab maybe ?

If your trying to build an Xterm from this then why bother with busybox and small clibs at all ? The jpeg you provided shows 64MB of RAM, thats plenty to waste 5MB on a ramdisk image, another 5 MB on libs still have enough RAM for an X-term.

If you start the kernel with Framebuffer support enabled and a vga= argument then you can use a framebuffer device for X, with a statically linked X you would not need much more than ifconfig, route, bash, X and some scripts to make a functional X-term.

What are you trying to build ?

Reply to
Unknown

Hello,

The inittab exists, but Busybox doesn't need it (although it reads it if it exists).

Yes, that's running, too. The system then had only 16 MB and I wanted to eliminate the Ramdisk. Right now I have a 5,6 Mb image containing loadkeys, init and XF86_S3 which works (although without many fonts; I couldn't afford the memory then). DHCP Autoconfiguration is done by the kernel, which, unfortunately, can't do this with PCMCIA nics - I wanted to make two more X-Terminals out of old 486-based notebooks.

My problem is only, that this X-Terminal doesn't work as expected (it's getting a bit off-topic now). It "hangs", but later continues to work. I don't know why, but I think it has to do with the amount of data that has to be sent across the network. It's the same, regardless of what system I connect to (I tried Fedora Core 6 natively, Debian Woody in coLinux as well as Qemu, and RedHat 6.2 in Qemu). When using KDE, every action (context menu or suchalike) makes the terminal "freeze" for a minute (mouse curser moves, but no other reactions at all), Icewm and Xterm can be used well. If I start dillo, it hangs sometimes while redrawing the screen (when a page has loaded) - Firefox hangs almost all the time. I already asked the question in de.comp.os.unix.x11, but noone could me help there (apart from asking over what kind of network I was trying - it's a 10 MBit LAN, crossover cable).

I can't use the Framebuffer at all (apart from vga16), because the graphics chip (S3 Aurora64V+) is not VESA 2.0 compliant (only VESA 1.2), but XF86_S3 (3.3.6) can be used to get accelerated 2D support.

I thought about a working system, but Windows (both 95 and 98) randomly crash / freeze. NT4 worked fine, but the memory was too small then. Without floppy or cd-rom support it is quite a challenge to install anything. Yesterday I changed the 64 Mb CF disk onto a 40 GB hard disk (clipped to 32 GB), but I think I'll get back to using it as a terminal. Do you know of a linux rescue system that can be booted over PXE ?

Regards, Sebastian

Reply to
Sebastian

Personally I think rolling init into busybox is poor idea, a statically linked init with busybox utils and shared libs is a compromise on space, but a better way to get a system running.

dhclient instead?

Yep. A 10MB lan will crawl running an X-terminal, especially with any application that uses large amounts of image data as backgrounds (called background pixmaps in X-speak). The problem is when an expose and redraw event occurs the entire window contents for the top window (visible window) and any secondary windows (more than are visible for a web browser) are copied over the lan as raw bitmap data.

So a 600x900 window with 24bit graphics would send (600x900x3)/1024 =

1.58MByte of data, but if its using stacked windows or backgrounds it may send it several times.

In the real world the throughput of PCMCIA ethernet adapter is only about

3/4 the speed of an ISA one - and the ISA one already sucked....

You could try enabling the X backing store, but a lot of code will ignore it (see +bs option on some X servers)

Nope !

The best PXE boot stuff i've found is "pxes", but its gone a bit to commercial for my personal taste.

formatting link

Maybe a Debian boot or an LTSP client image.

formatting link

Consider putting some of the older kit in the skip, trying to run an X-term on 64MB of RAM and a fast LAN is possible, but slow LAN or less RAM will not be viable as a general desktop.

I use a Sparc SLC with 16MB of RAM, but all it displays a single xterm window running multitail to displays logs from a server, I would not consider it for desktop use.

formatting link
(Left most machine here)

formatting link
Multitail - a great tool for log watching.

Reply to
Unknown

Hello,

I thought using BusyBox for everything possible makes it easiest for me to create that image... of course, I can use SysVInit, but I don't need any runlevels or suchalikes.

loadkeys,

afford

more

That again needs work I have not done before; and it would need more configuration. But I saw yesterday that BusyBox provides a dhcp client. The biggest problem (and the problem that made everything useless) is the lack of any storage inside one laptop. I'd need two floppies (kernel and root-fs) at least, but couldn't fit the root-fs into one floppy containing pcmcia-tools, dhcp client and X-server. A ramdisk is out of question, as 4 Mb of memory are simply not enough. This system works as a VNC client using MS-DOS. I can even afford a two Mb ramdisk containing DOSVNC, SSHDOS and SSH2DOS... thus far I never came with Linux, unfortunately.

[X hanging]

I thought that X-Terminal were used commonly on some universities over 10 MBit network connections, but I never heard that the speed was unbearable. At home it is... do you think NX is a way to go? I like the idea of XDMCP (connect to any server available), as this is not possible with VNC or RDP.

I only need 16 bit color depth, on the notebooks it's only 640x480x8 at most.

Yes. The Terminal I was talking about had at least a PCI-onboard one, able to take 100 MBit/s. But my network infrastructure here isn't able to take it (10base2 coax cables lie in the wall and there's no way to replace them). Of course, I could try to switch NICs and have that crossover-cable using my RTL8139.

I'll do later.

Understandable. Furthermore, the download is about 70 Mb and that won't fit onto my CF card. I think that it should be possible to create an image of about ... 20-30 Mb to get at least X and VNC client support. That'd be enough if I change to Xvnc (as I've done it because of the notebooks).

That would need server-side configuration and limit the possibility to take the thin client somewhere, hook in into the net and use it. That's why I like XDMCP - configure xdm and boot the terminal. But if 10 MBit/s is not enough...

You should know that I don't have a server here. I'm just experimenting with my main computer and my Etherminal; nothing serious (yet).

I thought I could get the main memory down at 16 Mb again. These are the only 32 Mb EDO modules I have (and they are not even mine), but I have about

10 unused modules of 8 Mb each.

Nice to know that I'm not the only person using many computers at the same time. My father would kill me if I had a working space like that. ;-)

Regards, Sebastian

Reply to
Sebastian

It should work, but I don't know these distributions. Maybe they are compiled for post-486 processors?

Building all that stuff by hand would take much longer. :^) It builds binutils and a 'naked' gcc to start with. It then uses that gcc to build uClibC. It then builds gcc again, this time with c-library support. After that, it starts building applications, one of which is Busybox. There are many others to chose from. You can add more applications if you want.

It depends on the build system. Quite often, you can do it with environmental variables like

# CC=-gcc LD=> It then uses this toolchain to build Busybox

Buildroot has an option to select where to install the cross toolchain. Make sure you set that to something sensible. I like /opt/cross/i486-pc-none

With most versions of GCC, the toolchain should not be moved away from the directory it was build for.

Now, in order to cross-compile any application, you do

# export PATH=$PATH:/opt/cross/i486-pc-none/bin

and tell the buildsystem to use that compiler.

Kind regards,

Iwo

Reply to
Iwo Mergler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.