Booting UML for the First Time
| Let's boot UML now: host% ./linux Notice two obvious things about the results, shown in Figure 2.2. Figure 2.2. Output from the first boot of UML
It's worth comparing this to the boot output of a Linux system, which is normally available by running dmesg. You'll see a lot of similaritiesmany of the messages, such as the ones from the filesystem and network subsystems, are identical. Much of the rest are totally different, although they should seem similar in purpose. This is largely due to hardware drivers initializing. UML doesn't have the same hardware or drivers as the host, so their bootup messages will be different. If you have access to Linux on several different architectures, such as x86 and x86_64 or ppc, you'll see the same sorts of differences between their boot output. In fact, this is a very apt comparison because UML is a different architecture from the Linux kernel running on the host. Let's look at the output in more detail. Checking for /proc/mm...not found Checking for the skas3 patch in the host...not found Checking PROT_EXEC mmap in /tmp...OK These are checking the environment on the host to see if it can run at all (the executable /tmp check) and whether the host kernel has capabilities that allow UML to run more efficiently. You'll see more of this below, but these particular checks need to be done very early. Checking for host processor cmov support...Yes Checking for host processor xmm support...No Checking that ptrace can change system call numbers...OK These are checking some more capabilities of the host. The first two are checking processor capabilities, and the last is checking whether the host has a feature that's absolutely needed for UML to run (which all modern hosts do). mconsole (version 2) initialized on /home/jdike/.uml/3m3vDd/mconsole ... Initialized stdio console driver ... Initializing software serial port version 1 Here, UML is initializing its drivers. A UML boot has much less output of this sort compared with a boot of a physical Linux system. This is because UML uses resources on the host to support its virtual hardware, and there are many fewer types of these resources than there are different types of devices on a physical system. For example, every possible sort of block device within UML can be accessed as a host file, so block devices require a single UML driver. In contrast, the host has multitudes of block drivers, for IDE disks, SCSI disks, SATA disks, and so on. Because of the uniform interface provided by the host, UML requires many fewer drivers in order to access these devices and the data on them. The first driver is the mconsole [2]driver, which allows a UML to be controlled and managed from the host. This has no hardware equivalent on most Linux systems. The last two are the console and serial line drivers, which obviously do have hardware equivalents, except that the UML drivers will communicate using virtual devices such as pseudo-terminals rather than physical devices such as a graphics card or serial line.
VFS: Waiting 1sec for root device... VFS: Cannot open root device "98:0" or unknown-block(98,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on \ unknown-block(98,0) Here is the panic that killed off this attempted run of UML. The problem is that we didn't provide UML with a root device, so it couldn't mount its root filesystem. This is fatal and causes the panic and the stack trace. You can make a physical Linux machine do exactly the same thing by putting a bogus root= option on the kernel command line using LILO or GRUB. [3]
Finally, an important point is that we just panicked a UML kernel, and the only result was that we were dropped back to the shell prompt. The host system itself, and everything else on the system, was totally unaffected by the crash. This demonstrates the basis of many of the advantages of UML over a physical systemit can be used in ways that may cause system crashes or other software malfunctions, but the damage is limited to the virtual machine. As we will see later, even this damage can be undone quite easily. That may have been interesting, but not very useful. Now, we will boot UML successfully and see how it looks inside. |
