Exercise 2.1: Can't get provided CentOS 7 image to boot?

neiljsmith

Hi all,

I'm wondering if any kind soul can help me.

I'm falling at the first hurdle of LFS216 here - I can't get the provided VM to boot.

I've downloaded https://training.linuxfoundation.org/cm/VIRTUAL_MACHINE_IMAGES/CentOS7.tar.xz, and have set up a new machine in VirtualBox on my Mac, and am using this as a disk image.

(I believe using my Mac as the host should be fine? https://training.linuxfoundation.org/cm/VIRTUAL_MACHINE_IMAGES/000README.txt states that "The VM's have been confirmed to work on Linux, Windows and MacOS host machines.")

The machine initially starts to boot fine (on /boot/3.10.0), and I see the CentOS Linux 7 progress bar, but then this error is produced:

The /boot/5.1.0 option produces the same error - but the (0-rescue) option works, and gives me a login window. I assume this may not be ideal for the rest of the course, however.

I've done a lot of Googling, and trying various fixes for dracut related issues (I'm guessing the disk uuids don't match somewhere?), but to no avail.

Can anyone please help? I obviously can't get further on the course whilst falling at this first hurdle.

Many thanks,
Neil.

coop

I am travelling and cannot check until some time tomorrow, but if some other kind soul can check the vbox case, please do so. They did work on vbox as recently as last week but the VM is new. I don't think the Mac might matter but it might.

If the other posted VM's work ok, the problem can be in the specification of the root device; if in grub you change it to
root=/dev/sda1 instead of root=UUID=... there is a chance that could work, but I don' t really know.. I can test on Tuesday

neiljsmith

coop, thanks for your response!

Hmm, I just tried that, but it yields me a "Warning: /dev/sda1 does not exist" message instead and the same Dracut Emergency Shell.

I note, in case it helps, that a couple of other lines in that grub config mention a specific UUID id - two lines starting "search --no-floppy --fs-uuid --set=root [various options] [some UUID]"

neiljsmith

Sorry, forgot to say - the Ubuntu 19 VM from the same directory (https://training.linuxfoundation.org/cm/VIRTUAL_MACHINE_IMAGES/Ubuntu-19-04.tar.xz) boots fine for me.

coop

make sure you have right scsi driver. not sata. vbox screws up some times

neiljsmith

Bingo!

Thanks so much, coop.

I swapped from attaching a SATA controller to SCSI, and it now boots first time!

coop

great! With vmware, you attach to the .vmx file which specifies things like the disk controller, default RAM, number of CPUs etc (which you can always change). with vbox, you get only the disk image and the other parameters are set by virtual box (and can be changed) so we cannot really protect against taking wrong disk controller. VBOX has its own ideas and for some reason it takes a different one with centos than every other distribution for some bizarre reason (sometimes!)

llewell

I'm getting the same thing with libvirt/kvm on Ubuntu 18.04. I've converted the image to qcow2 twice and now I'm trying to boot the vmdk directly. I changed the disk interface from virtio to scsi but both the 3.10 and 5.2 boot items end up in the dracut shell. The 5.2 boot item starts out with a message that says autofs4 fails to load, then both of them end up in a display just like Neil posted above. The rescue boot item doesn't load at all. Changing the disk to IDE doesn't load at all.
I have the Ubuntu16 image, my own Debian image, an F5 image, and a vyos image all working, and GNS3 running with QEMU support on this machine, so it's hard to see how the system is the problem. Anyone else doing this on libvirt/kvm?

coop

I haven't personally tried to convert these images to KVM format (qcow2) and run with libvirt etc. (recently) although I have in the past with success. And I don't have time to check right now. But I think you will find it takes a lot less time to try and use our VM (if you are having nightmares) than doing the following:

Do a simple install from the ubuntu 18.04 install image directly in KVM. This should be about a 10-15 minute job at worst. Ubuntu gives you almost no choices during install except for name, password and time zone

You can use student as the username if you find that it matches the course better, but you don't have to.

18.04 is old now, so as soon as it reboots do an update as in

sudo apt update && sudo apt-dist-upgrade

Then download the ready-for.sh script from http://training.linuxfoundation.org/cm/prep
Then run it (as a normal user) as in

./ready-for.sh --install LFS216

This is mostly just install all new packages command. and runs as quickly as your network will allow (on some distributions you might have to do something first like sudo apt install wget as wget is not always in the default package list due to distro dumbness.

llewell

So it boots with "sudo qemu-system-x86_64 -m 4G -accel kvm -k en-us -hda /var/lib/libvirt/images/CentOS7.qcow2" Not sure why it needs the language specified. I couldn't log in and when I tried to get in as root it came out "vzzn".
It's not exactly zippy. Now that I know that works I can look for options that may speed it up. And move it out of the libvirt/images directory where only root can run it.
Whatever was done to build the CentOS image it doesn't seem to like libvirt's kvm-spice emulator. Like I said, the Ubuntu16 vm boots up fine.

llewell

Didn't see your reply, coop, before I added my own above. I was under the impression that we were supposed to use the CentOS image for reasons I assumed would become clear.
Anyway, can't get it to boot in virt-manager or virsh. I can get it to boot from a qemu command line, and boy have I enjoyed the trip thru qemu command-line hell figuring out how to get the networking going the way the instructions specified. I have two of them and they can ping each other on both the NAT and the isolated networks, and can get to the Internet.
I have converted several VMWare images over the years to work in KVM and I have never seen one fail this way. That UUID message is really puzzling since the one printed out in the dracut error on KVM is the one that boots fine in QEMU.

coop

I'll get to looking or asking for help figuring out

llewell

It seems like it's just not finding the disk,right? When I did this in virt-manager setting the disk to IDE didn't work. But I just dropped it into GNS3 and after trying SCSI and Virtio, I tried IDE and it booted. Not sure if it matters, but GNS3 is using qemu-system-x86_64 instead of kvm-spice. Hope that helps.

lee42x

Hi, maybe I can help. I have most of the vm's running happily under KVM. Being lazy, I used virt-manager to create the machines and hook up the disk, other than memory and CPU I left the defaults. I did convert the images to qcow2, I find the qcow2 images a little quicker than the vmdk's. I launch the VM's out of virt-manager. Currently I'm running Centos7,Ubunti18.04/19.04 and Opensuse15-1 all started the same way.

Now if your crashing on dracut with the standard image but can get the rescue image to boot, do a reinstall (or update) on the kernel and it will rebuild the initial ram disk and thing should be much better.

Lee

llewell

Yeah, not sure why I had a problem getting it to boot in virt-manager with an IDE bus, since it seems to be working now. I may try to rebuild the 5.2 kernel since that one still won't boot.

lee42x

The kernels with the very short names, 5.2.0, 5.3.0 etc... are created for the Development classes not the Administration classes. The reason they are different is the Developer classes do not need as much "stuff" so they compile a rather bare bones kernel for their environment. Having removed may options, the Administration classes do not work so well on the Developer kernels. We recommend the distribution kernels (long names and versions) for the Administration classes.