Kernel Panic: Unknown block device

[prologic]

Any ideas?

[ivandavidov]

It would have been better if you shared the command you used to start QEMU. At first glance - have you tried increasing the RAM? Also, ensure that you use the latest available stable QEMU version.

[prologic]

Ahh sorry (it's late)

$ qemu-system-x86_64 -boot d -cdrom minimal_linux_live.iso

I'll try increasing the RAM. Normally this error is indicative of missing kernel modules. But we're booting an ISO?

[prologic]

Increasing memory to 1GB didn't help:

$ qemu-system-x86_64 -m 1G -boot d -cdrom minimal_linux_live.iso

[ivandavidov]

Well, 90% of the time increasing the RAM helps. But I also found out that QEMU doesn't always boot my custom generated ISO images correctly. I also found out that it's very important to keep QEMU up to date. Sometimes even the most recent QEMU version doesn't boot MLS with the most recent Linux kernel.

That's why over the past year I've been using VMware Workstation Player as my main VM to verify that the ISO images boot fine. I suggest you try either VirtualBox or VMware Worrkstation Player. So far I had no troubles at all with VMware's product.

My best guess is that this is a local issue related to your QEMU version.

P.S. Absolutely no troubles at all with the sample scripts on new local machine with git clone of the project and all prerequisites installed.

./clean.sh
./minimal.sh
./qemu.sh

[prologic]

Thanks for verifying! Good to know. I went ahead and built the minimal source as well and that panics too; but funnily enough not the prebuilt ISO they also build :) -- I'll rule a few things out...

[prologic]

So it panics in Virtualbox too. The only thing I'm doing slightly differently is building in a container environment using Docker. See my fork

[ivandavidov]

I had exactly the same issue with Travis CI recently. Everything with the build process seemed to be fine but running MLL in QEMU always failed in the Docker environment. The reason I went for Docker build was because Travis CI supports very old Ubuntu version and I wanted to build MLL by using the latest available Ubuntu version, just as in your use case. After that I found out that QEMU always fails, both in the Docker environment (Ubuntu 18.04) and outside of the Docker environment (Ubuntu 14.04) in Travis CI.

I know this doesn't help much. I'm just sharing my recent experience. :)

Last thing you could check - use VMware Workstation Player to install fully blown Ubuntu 18.04 minimal environment. After that build MLL/MLS inside this environment. It should work fine.

[prologic]

Man :O This is crazy I'm literally just re-tracing your steps :) -- That being said "all things equal" -- A container should be nearly identical to e real host with the same rootfs :) sigh

[prologic]

I'm also re-building with an Ubuntu:14.04 (trusty) env :) But sadly I only just read your comment now so it's probably a waste of time :/ I'll have to spin up a real VM and pick a Linux host to build from.

[prologic]

Mounting the ISO reveals:

$ ls minimal
boot.cat  isolinux.bin  isolinux.cfg  kernel.gz  ldlinux.c32  rootfs.gz

Nothing too interesting so far...

[prologic]

Interestingly booting the kernel and rootfs directly panics the same way hmmm

I extracted the kernel and rootfs from the iso and ran:

$ qemu-system-x86_64 -m 256M -kernel minimal/kernel.gz -initrd minimal/rootfs.gz -append "console=ttyS0 console=tty0"

[prologic]

So if I run this with the same kernel but another rootfs it works. So something about the way the rootfs is being created seems broken somehow.

[prologic]

I got it to build and boot successfully! (but not the resulting ISO)

For some reason the ISO generation is doing something funky with the ramdisk

[ivandavidov]

Just for reference, here is the QEMU version that I used in my tests.

$ qemu-system-x86_64 --version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.30), Copyright (c) 2003-2008 Fabrice Bellard

Another option which I haven't tried is to download & build QEMU locally and don't rely on the pre-built QEMU version that comes with the OS. This may or may not solve the Travic CI issue that I mentioned about earlier, but it's worth to try it.

https://www.qemu.org/download/#source

[prologic]

So my latest commits all work now. I can't explain this. The only things I did was:

• Downgrade the build env to ubuntu 14.04
• Make /build not a docker volume.

[prologic]

And mine:

$ qemu-system-x86_64 -version
QEMU emulator version 2.12.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

$ docker-machine --version
docker-machine version 0.15.0, build b48dc28

$ docker version
Client:
 Version:      18.05.0-ce
 API version:  1.30 (downgraded from 1.37)
 Go version:   go1.10.2
 Git commit:   f150324
 Built:        unknown-buildtime
 OS/Arch:      darwin/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      17.06.0-ce
  API version:  1.30 (minimum version 1.12)
  Go version:   go1.8.3
  Git commit:   02c1d87
  Built:        Fri Jun 23 21:51:55 2017
  OS/Arch:      linux/amd64
  Experimental: false

[ivandavidov]

Congratulations! Even though people consider me very smart when it comes to Linux issues, I have no explanation as well. :)

I can also confirm that MLS can be built on Ubuntu 14.04 (that's what the Travis CI test does) but MLL will fail because the supported build toolchain in Ubuntu 14.04 is quite old and GNU C Library will refuse to comply due to the outdated software. That's the primary reason why I tried to use Docker with Ubuntu 18.04 and in the end I hit the same QMU issue that you also hit.

The only good news here (old news but good news) is the fact that in fully blown Ubuntu 18.04 there are no build issues and both MLS and MLL run perfectly fine with QEMU and other VM software.

[prologic]

Going to try and get to the bottom of this 😀

On Thu, Jun 28, 2018 at 10:30 Ivan Davidov notifications@github.com wrote:

Congratulations! Even though people consider me very smart when it comes to Linux issues, I have no explanation as well. :)

I can also confirm that MLS can be built on Ubuntu 14.04 (that's what the Travis CI test does) but MLL will fail because the supported build toolchain in Ubuntu 14.04 is quite old and GNU C Library will refuse to comply due to the outdated software. That's the primary reason why I tried to use Docker with Ubuntu 18.04 and in the end I hit the same QMU issue that you also hit.

The only good news here (old news but good news) is the fact that in fully blown Ubuntu 18.04 there are no build issues and both MLS and MLL run perfectly fine with QEMU and other VM software.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ivandavidov/minimal-linux-script/issues/10#issuecomment-401113313, or mute the thread https://github.com/notifications/unsubscribe-auth/ABOv-lkk6kwxlFtb92FBD4IVTxcrghpyks5uBRLRgaJpZM4U6wwq .

--

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

[prologic]

So circling back to this issue... (sorry for the delay!). I was never actually able to reproduce this again :/ -- I suspect bad//broken build cache(s) but honestly I don't know :(

In other good news I have what I set out to build based on your script. A fully working OS with:

• Docker build environment -- CI friendly. Takes ~26m to fully build on my underpowered Macbook.
• Busybox userland
• Dropbear SSHD
• Docker CE
• Full Networking support (Static + DHCP)
• Boots in ~3s
• Comes in at about ~25MB ISO

Thank you for your initial work on minimal-linux-script and your help FWIW :)

Now I have to:

• Do more testing
• Polish things up a bit
• Rename the project (no ideas here yet)
• Publish regular ISO(s) and Cloud images
• Add cloud-init support

[ivandavidov]

Good work, James! Impressive!