DSL Embedded :: kernel compilation: qemu problems
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".
Using -cdrom in qemu to boot the .iso image worked.
Any ideas/suggestions?
Compilation steps: used the standard make oldconfig mrproper clean bzImage etc. with dsl/knoppix patches/configs
As a side note: the rdev command executed on the kernel image after compilation seems to be needed for the isolinux setup (and USB - from juanito) but not grub+hdd+frugal.
Not sure what your issue might be.
I can say that when I built DSL v2.x (2.4.31) I did not have any problems with embedded. But then I never had to do a rdev either.
I recently built a new kernel and modules and again experienced none of these issues.
I always build on a full hard drive install of DSL on ext2 partition.
I am aware that Jaunito does not have acess to full hard drive installation and perhaps that is why rdev is needed.
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
As with anything Linux, many ways to do it. No, hard and fast correct answer.
I do full hard drive install for two reasons:
1. I am sure of the filesystem supporting proper permissions
2. Easy to reboot and test new kernel and/or modules without need to copy or remaster
You are correct when working with the qemu embedded to update THAT minirt24.gz.
There are actually several minirt24.gz customized for their particular use.
It is always best to update the one currently used for a particular purpose.
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)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.
Next Page...
original here.