Booting custom LFS directly from CDROM. Iso9660 useless as root file system?
So I've made a custom LFS system and from it I can build a bootable iso image with GRUB 2. The idea is to start linux, enter X, and immediately start a specific program. Basically, I want to use it as a booter disk, as was the case in the (HD-less) Commodore Amiga for many apps. This system needs to boot fast, as it would be on a CD-ROM or USB, so it has NO MODULES WHATSOEVER. Everything is built into the kernel. This makes the system boot into a GUI in at the very least 5 seconds under Virtual box B-) Having the system built, the next stage is building a bootable CD. After that, build a CD that boots straight into a desired program. I'm currently stuck in the second stage (building a bootable CD). That is, I can create it, but it fails when I try to boot it.
When I boot up the kernel loads up fine and sees the root system as iso9660, as it should. And that's as far as I get. It seems incapable of loading and running ANY process from the disk, much less init. The init I'm using is the arachsys init located in /etc/init. I've tried booting with no 'init=...' parameter, with 'init=/etc/init', 'init=/bin/sh', and 'init=/bin/bash'. They all fail. Booting with no 'init=...' parameter yields the message Code:
Kernel panic - not syncing: no working init found. Try passing init= option to kernel. See Linux Documentation/init-guide/init.rst for guidance. Code:
Kernel panic - not syncing: Requested init /etc/init failed (error=-2). |
What strikes me is that for /etc/init or anywhere to be your root drive, it has to be mounted as /, and that is probably where your problem lies. When the kernel boots, part of that process should be to mount the / drive ro as in a typical bootup line
Code:
kernel=<some_kernel> root=/dev/sdaX My advice is to look at a known working live dvd, and see how they do it. Then copy that. They have it worked out. EDIT: I would also search the LFS Hints for ideas. I bet someone has done it and written it up. |
Quote:
The thing about most distros is that they use initrd, so they don't set the root file system. That's because they put everything plus the kitchen sink into separate modules, so they do all the probing there, THEN load the root file system and call the real init. I thought about using initrd as the actual root but In not so sure. I'm looking into squashfs, I believe this can get (decompressed and) loaded into a loopback device upon startup. This has the drawback of some overhead due to the decompression, but I'd have to test it to be sure. It should be fast considering it supports gzip and xz algorithms. I noticed that GRUB2 supports mounting images as loopback file systems. However, the kernel can't pick these up, at least not in any way I've tried so far. This would be ideal as there's no overhead but I haven't worked out how to do it. Even better would be to just be able to use the CD's native file system (the ISo image where GRUB and the /boot directory lies) to be the root file system. This doesn't even need to load the loopback image so it's faster still! Yet I can't find anything conclusive about using the ISO9660 file system as the root of s UNIX file system hierarchy. It CAN hold permissions and file type information with the appropriate extensions, so why can't executable binaries be loaded from it by the kernel at boot up? Do I need to pass special flags to xorrisso/grub-mkrescue for this? |
What you have clearly isn't working.
The initrd & squashfs all sound very familiar, and they work. Even tomsrtbt, the floppy distro (20 years out of date but still up there) uses squashfs. I wouldn't worry about only the first cdrom picking it up. That's what you set up - root=/dev/sr0. It's a rare machine indeed that has 2 dvd drives. You can only pick one. If you're seriously going to do this, the way to go is with uclibc (if LFS still support this), make allmodconfig on the kernel (then sanitize it), and perhaps older versions of stuff with the odd patch applied if you need to save space, or ram. There's also tmpfs which is used these days. You could break modern ground using that. The key point for uclibc is: you may have the ram, but everyone doesn't. As a pet hate, I would try to work on the fact that the dvd drives tend to load one sector from track 0-10, then one from track 5,000 -->, one from track 0-10, etc. and it spends more time seeking than reading. If you don't believe me, try a fedora live dvd. |
You would have way more luck building LFS then copying it over to usb and make that bootable. Cd-dvdrom is old tech but ya the distro's still provide them for use on older hware. Just my 2 cents.
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Looking back at post #1, you're falling down at mounting the iso9660 on /. Does it have a believable file hierarchy (/bin, /boot, /lib, etc.) or some other setup? Surely you want to mount your squashfs?
I did a quick search 'grub mounting squashfs ro' and the results were different depending on the tools you're using but interesting. |
Quote:
NOTE: The problem isn't mounting the file system. That part goes fine. The problem is running the init binary. I think I'll scrap the squashfs idea, at least for now. I'm trying to use a cpio initrd. Still no success. |
Reinventing the wheel is painful, especially given the metamorphoses that the pc has gone through. This leaves inane hardware eccentricities. Everyone with a working system has a drive image mounted on /. That, and your errors, tell you something. Is /dev/sr0 executable? AFAIK, it's read only.
|
(Partial) success!!
Quote:
LFS now puts all libs in /lib, instead of having /lib AND /lib64 in modern systems (why GLibC does this upon configuring I'm not entirely clear), but the dynamic linker--which is part of GLibC, not binutils--is partly placed in /lib64. By partly I mean 2 symlinks are placed there even though the binary is in /lib. So I copied this folder into the template directory (the directory holding the future root directory for a disk or initrd image) and tested this via an initrd image boot. I was finally able to start init and reach a shell command line! I still haven't been able to boot straight from the ISO (i.e. omitting the initrd step), mainly because I 'm in the middle of re-implementing the boot process to boot as before and haven't had the time to get it all done, but the big hurdle has been overcome! |
Code:
Device files are never executable. |
Quote:
Quote:
|
All times are GMT -5. The time now is 09:24 PM. |