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

The suggested file did not help. When I try 'init=/etc/' I get

I get this same message for all other attempts, including /bin/sh and/bin/bash. Oddly enough, /etc/init IS in fact one of the paths that the linux kernel probes when booting up, so with no 'init=...' I should see the same message as for explicitly stating /etc/init as the init process to use. In any case I can't boot from the iso image. Is the ISO 9660 useless as a UNIX file system, or at least as one to boot into? If so, how can I boot a usable system from the iso image?

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 Now you will probably have to make heavy use of tmpfs to get going, as certain things like /proc, /sys, /var all need access during the normal startup.

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.

I did set the root file system: root=/dev/sr0 (the CD-ROM drive). If I hadn't I would've gotten the kernel panic stating that the root file system couldn't be mounted. I got that before 'till I realized how to set the root file system device to the CD-ROM drive. This still needs fixing as it's inflexible: it'll only boot from the FIRST CD-ROM drive.

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.

No shit! Maybe I should go on one of these fancy, newfangled "forums" I've heard so much about ;-)

Well of course they work, they're supported by the kernel, and just about all distros use them.

I would. Though rare, I'd prefer to have that base covered.

Why? I don't care about RAM usage, plus the root file system I've built is ~108 MB so... Also, I'm building everything into the kernel, allmodconfig is out of the question.

Not really. I considered that before, but since I can't boot directly from the CD-ROM I have to use a loopback file (squashfs formatted initrd) which make the manual tmpfs mount point creation pointless.

I'm only targeting systems with enough RAM. And since there's no 64-bit system with less than 1 GB I don't care about uLibc. And as I pointed out before, the entire root file system is ~108 MB. I'd have plenty of extra RAM, as well as space in the distribution medium.

This is now a moot point as I'm going to (have to) go with initrd.

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.

Yep, all the expected directories there. ISO built with Joliet and RockRidge extensions, UNIX permissions and symlinks supported. Everything's fine but init seems to be impossible to run during boot.

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.

Device files are never executable. And what does that have to do with anything? The ability to run executable binaries, as well as other attributes necessary of the root file system, are set up by the kernel at boot time. Anyway, I found out why all executables seemed to be failing. After googling a bit more I found someone was getting the same error and the answer marked solution noted that the error (-2) meant one of the resources of the binary, i.e. one of the libs and/or auxiliary binaries, was missing. It also said that you could use the ldd binary to list these resources. I tried that and the result was clear: I was missing a directory, /lib64!

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!

Correct, but the software to handle it IS read only. So how can you populate /dev, /proc, /var & /sys? /sbin/init is PID 1. Where's that going to be written? You're going to need all of those, and you only have a read only device so far when init is started. I explained myself poorly.

Huh?! None of that made any sense. What does files being executable or not have anything to do with it being read only vs read-write? And what does the file system being read only have anything to do with mounting anything under it. Yes, init is the second process created by the system, so logically it's PID is 1. What about that? Where's WHAT going to be written? Need all of what?!

No argument there!