I compiled a new kernel and modules in DSL (3.2), however, during testing with qemu (replaced files from dsl-embedded.zip) it would not go anywhere after booting the kernel (would stop in command shell).

At first, I though this was a problem with my compilation steps/environment, but experienced the same results again. Installing a grub+hdd+frugal showed that they worked, and the same with isolinux+cd - the only problem seemed to be with qemu.

Looking at the error messages, it seems the system in qemu tries to execute the first parameter in -append, which happens to be qemu - but since that file doesn't exist in the miniroot, it fails and drops to the shell.

It would appear that the init scripts are just not being started at all. I could pass init=/etc/init ... (though it couldn't find the knoppix image next - may be a result of this problem) but I would like to know if there is something extra (or maybe something left out) that needs to be done to make the kernel "qemu-friendly".

Heh, I hadn't used a full hd-install lately because now most of my machines have at least 32mb.But, I remembered that on full hd-installs, apt is the system to use, so I decided to try it again (using a full hd-install anyways).

Did some tinkering on the packages (since not everything will install right off), and loaded mydsl > gnu-utils.Built kernel, and loaded it into dsl-embedded's qemu scripts, and init successfully executed automatically. (Still had the knoppix image not found, but now I remember dsl-embedded's minirt is slightly different, and mine was based off the cd .iso's)

Using a full hd-install or frugal should not matter in this case IMO.I think the packages that I used on the frugal probably had some conflicted somewhere.If there is some sort of reason why using a full hd-install for kernel compilation is required, I'd be really interested to know.

Additional note: following juanito's guide also resulted in the same problem

Compiling off the ramdisk also makes sure of the proper permissions, etc. because it is always ext2, though it limits those with lower resources/settings and they would have to use a large swap/pagefile.

I suppose it's preference whether you'd prefer to test by rebooting or using a VM first.

And here's some more info:

It appears that, depending on how you are running your current (root) system, the kernel compilation tries to adapt to it.For frugals it appears on the ramdisk, on full hd-installs it appears on the hard drive's partition.By editing the kernel image's 'header' you can achieve the same result as if it was built on the full hd-install by use of rdev.

Code Sample

rdev -R bzImage

The rootflags should show that this is 0, or else you will recieve read-only errors upon boot. If it is not, you can use

Code Sample

rdev -R bzImage 0

Note that you could also always just run this command anyways instead. (My latest compilation under dsl+frugal was correctly set already...)

Checking dsl-embedded scripts, it is using the KNOPPIX cloop image as hda, which is probably one of the main reasons why I encountered this thread's problem. (note that qemu explicitly requires -hda to be used when a linux kernel is used on the qemu argument list)

Code Sample

rdev bzImage

The root_device will show you which is the device will be "/" (root). Using a frugal compilation will show this to be "/dev/ram0" while a full hd-install will show "/dev/hda1".

Code Sample

rdev bzImage /dev/hda1

can change it if it is /dev/ram0. Note that you could also always just run this instead, regardless.

Booting it under qemu should now work.

I suppose the regular bootloaders might change the image header on-the-fly during boot so that's why it did not affect those setups.