Images do not work

glushkov

Hi,

Following the example from this video [1], i had tried to create three VMs:

• Ubuntu 18.04

• CentOS8 Stream

• OpenSuse 15.3

I have downloaded the tar.zx archives from here [2]. I have created the VMs following these [3] instructions in a VirtualBox 6.1.26_Ubuntu r145957 on Ubuntu 20.04.3 LTS. The latter two do not work.

CentOS Stream:

• After selecting in the bootloader "CentOS Stream (5.15.0) 8", or "/boot/4.18.0-348.e18.x86_64" I get this [4] and eventually - this [4a]

OpenSuse:

• After selecting in the bootloader "openSUSE Leap 15.3" I get simply black screen [5]

• Going for "Advanced options for openSUSE Leap 15.3" > "openSUSE Leap 15.3 with Linux 5.12.0 9recovery mode)" gives me this [6]

• Going for "Advanced options for openSUSE Leap 15.3" > "openSUSE Leap 15.3 with Linux 5.3.18-59.27-default gives me this [7].

I do have a working Ubuntu, so it is not urgent, but I would really prefer to have all VMs so I can compare between different distributions..

Btw, it would be nice to remove the reference to "training@linuxfoundation.org" in [3] since this is just automatic reply which is pointing to an even more useless JIRA tracker (where I cannot attach any screenshots). Which brings me to my next question:

What is the official support channel for the VM images which you are providing?

Cheers,

Ivan

[1] https://trainingportal.linuxfoundation.org/learn/course/essentials-of-linux-system-administration-lfs201/course-introduction/course-information?page=11

[2] https://training.linuxfoundation.org/cm/VIRTUAL_MACHINE_IMAGES/

[3] https://training.linuxfoundation.org/cm/VIRTUAL_MACHINE_IMAGES/000README.txt

[4]

[4a]

[5]

[6]

[7]

coop

Great. Keep in mind CentOS-9 came out just a few days ago and while it is branched off of Fedora 34, it is incomplete as there is no EPEL repo for 9 and other such matters. ANd I had some trouble configuring selinux to run on custom kernels, but it is running on the stock kernel. Enjoy

coop

All three of these VMS have worked successfully on both vmware and virtualbox although I confess they are better tested on vmware as that is where they are produced. (This is the right forum to ask about the images as I am the one that creates and maintains them)

If you successfully get into a grub menu and then the system starts to boot and fails, the most likely instance is always a mismatch between the hard disk driver in the initramfs, and the driver the hypervisor wants to use. All of these images use SCSI as the disk type (I just checked). I have seen Virtual Box sometimes mysteriously choose SATA by default. And some very recent images (like FC-35) actually use nvme. Usually the rescue images can handle both as they are pre-canned (not built at time of installation or kernel compile and install) like the other ones). If you have access to the actuall initramfs file you can use the "lsinitrd" program to list the contents.

If the emergency boot choice works, that is a good clue. You can change the machine settings in the hypervisor or reinstall the kernel while running the emergency boot option.

By the way, I assume you have OpenSUSE 15.3 not 25.3 unless you are far in the future The output you post from OpenSUSE is almost definitely a hard disk dirver mismatch. Same is true for CentOS

we can change the link in the readme file. However, let me note that if you are in the class, that is not the best way to ask about this, it is to ask in the forum as you are doing. The training JIRA link will take a more circuitous route to get answer

I expect both of these would work fine with vmware without a problem. I won't get into vmware <-> virtual box holy wars but they are more often used in vmware so bug reports come in more often and get dealt with, but they are rare. It is almost always the disk driver.

If all else fails it takes about 1/2 hour to:

build a new VM from scratch by downloading the install isos and using them
then run ready-for.sh --install LFS201 (you may have to install curl first depending on distribution)

Then you will have the pride of doing it yourself. And it may take less time than debugging what went wrong if it is not the hard disk driver problem, which is a couple of mouse clicks to fix.

glushkov

Thanks for the pointers coop,

• I have no doubt that all images are being tested but that does not really help me, right? Anyway..
• VirtualBox is always using by default SATA (no idea why). And it actually miraculously works in some cases (CentOS8 for example).
• The VirtualBox vs. VMWare - I also don't care. It's simply that I cannot install VMWare on OSX (I am working on the courses on two different machines depending on my physical location - an Ubuntu 20.04 and an OSX). So, at least for the OSX case - I am stuck with VirtualBox
• openSUSE worked (btw, CentOS 9 Stream needed that too) after I have removed the SATA controller and attached the disk to the default SCSI controller (LsiLogic). I need to do zypper clean --all in order to update the VM, but otherwise it worked like a charm, thanks.
• On top of the above, Fedora is starting in rescue mode and give it 4 GB RAM to get it going. Once updated and booting with kernel 5.15.6-200.fc35.x86_64 works perfect.

• The VMs which do not work for me also after trying all SCSI drivers are

  • CentOS8 Stream (stuck in dracut, and in rescue mode - with dracut: FATAL: iscsiroot requested but kernel/initrd does not support iscsi)
  • Gentoo (stuck to a "terminal" i.e. blinking cursor where I cannot input anything or no obvious error in rescue mode)

• My point [4] from the previous post i.e:

drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message

This message btw seems to be harmless since it exist for example in CentOS8 image in dmesg, but the VM boots fine. Anyway, the solution is to change in VrtualBox the graphics controller (Settings > Display > Graphics Controller) from the standard "VMSVGA" to "VBoxVGA" (from [01])

• Ubuntu 20.04, Fedora 35 and openSUSE 15.3 image - Flickering of the screen. Solved by enabling 3D Acceleration (Settings > Display > Acceleration: Enable 3D Acceleration)
• Ubuntu 21.10 (I know it is not supported, I include it for completeness) - the pointer does not work with the default settings. Changing Pointing Device (Settings > System > Pointing Device) to "PS/2 Mouse" did the trick. It is still with different speed than the host OS, but hey, better than nothing.
• For the link in the readme file - I think you should remove it. Or at least mention that the right way to report errors is here - it is not clear from the documentation.
• Installing from .iso - I know that is an option. I wanted to have your VM, because I presume there will be baked in some goodies in them at some point

Anyway, for me, the story is over - I have at least one working VM from each distro family. The key one was openSUSE - while you have several VMs from RedHat and Debian clones, there was only one for SUSE and it was not working - now it does, thanks.

Cheers...

[01] https://unix.stackexchange.com/questions/502540/why-does-drmvmw-host-log-vmwgfx-error-failed-to-send-host-log-message-sh

coop

BTW, you can use vmware on the mac if you use VMware Fusion, which is not free but low cost and works well. For the life of me I don't know why they charge for the Mac Version and not the PC version.

When you install on vmware you get to pick all the hardware under Machine Settings before the install starts. On VirtualBox it picks these things for you once you point to only the .vmdk file (there is nothing like the .vmx file vmware uses which has these settings.) I cannot predict exactly what a given choice of hardware and software and VirtualBox on the host will decide to pick and dumb things happen.

You should also never try booting into the custom kernel (5.15.0 probably) before making sure you can get into the distribution supplied kernel. The custom kernel is only for use in kernel development courses and the other should be the default. It deliberately does not contain every possible driver and option as it gets rebuilt multiple times in other courses.

I don't own a Mac and do not test on the Mac. Things are different. For example, hardware video acceleration does not work on PCs in any scenario I personally have seen. Mouse drivers and integration is a typical bug that comes up that is hard to predict and solve for both hypervisors and usually involves installing addition software from the upstream provider (additions etc.)

There is a limit to how much hypervisor setup debugging we do and there is a conscious reason for that. This is not a course on hypervisors. We don't have the expertise or bandwidth.

If you want the best experience and you have a linux host running, use kvm, it works the best.

Let me note that if you install from the distro CD/DVD, run dnf or apt to update and run ./ready-for.sh you are duplicating exactly how these vm's were built, the only difference being we run ./ready-for.sh for a number of courses and so it installs more software and takes longer (the complete list is LFS300 LFS301 LFS416 LFS416 and a bunch of LFD courses -- LFS301 is the same as LFS201 -- but never takes more than 1/2 hour of which 25 minutes you don't need to be there. All this debugging may be educational but does not produce a better VM. For an experienced person like yourself this should not be a big challenge.

As far as GENTOO goes it is completely unsupported and is there for fun. As you can see it is hell to keep working and up to date. I have found that if I don't update at least once a week it breaks beyond repair and it is very sensitive to the drivers on the host. ArchLinux works better but is also unsupported.

the only VMS we encourage are CentOS-8-Stream and Ubuntu-20-04. The rest are there for fun or for a couple of legacy courses (I'd like to dump Ubuntu 18-04 at the end of the year and CentOS-8 is reaching EOL. ) Please note almost no one downloads and uses OpenSUSE any more so that is also there for fun. All exams use either Ubuntu or CentOS. Debian is almost always ok because it is close to Ubuntu and is very well done to begin with.

Thanks for all the diligence, it keeps us on our toes, but as I said I would never try to do full hypervisor support. the providers are crappy with Linux support even though Oracle has its own distribution. For example, when 5.16 comes out it is unlikely it will work as a Linux host on one or both distributions and I will have to figure out or find someone who has figured out how to patch the vmware source so it works with 5.16 as I work only on linux hosts.

The readme file and all VMS will be updated about the end of the year when 5.16 comes out. We do it as an atomic operation.

For fun you could try CentOS-9-Stream. I uploaded it a few days ago, no promises or support

Merci

glushkov

Thanks for everything coop,

I have my setup (Ubuntu 20.04, CentOS9 Stream and openSUSE 15.3) working and I am not planning to play around with the rest. I think it would be useful/timesaving for the users to somehow note which images are considered "current" and which are "for playing"..
Anyway, feel free to make / label this thread as solved.

Cheers..