Arch Linux

golubovsky

Member

Registered: 2007-05-28

Posts: 5

Under KVM, hda when booting from hda, sda when booting from cdrom

Hi,

I'd emphasize at the beginning: this was observed under QEMU/KVM and may not apply to "bare iron".

But it looks interesting. I'm not even sure what would be the right forum for this discussion. Let's start here.

I performed installation of i686 ArchLinux from the LinuxTag 2007 FTP ISO on a virtual machine running under KVM-17 on a x86_64 host (AMD Athlon x2).

Here are the commands I used:

to install:

su -c "qemu-system-x86_64 -net nic -net tap,script=no  -hda disks/vdisk.img -boot d -m 196 -std-vga  -cdrom images/Archlinux-i686-2007.05-Duke-Linuxtag2007.ftp.iso"

to boot from hda:

su -c "qemu-system-x86_64 -net nic -net tap,script=no  -hda disks/vdisk.img -boot c -m 196 -std-vga  -cdrom images/Archlinux-i686-2007.05-Duke-Linuxtag2007.ftp.iso"

so the difference is only in the -boot parameter, the rest of parameters are the same. Bridge and tap0 were configured externally, thus script=no.

When trying to boot from the hda image, I noticed that the kernel cannot mount root filesystem on /dev/sda1 as was instructed by LILO. Replacement of sda with hda in lilo.conf fixed the problem. When I compared the dmesg output with different booting devices, I noticed that the disk device is interpreted as scsi over ata (newer way) when booting from cdrom, and as hda (traditional way) when booting from hda (both virtual of course;)

I have placed both dmesg outputs here (not to make the message to long):

http://www.golubovsky.org/repos/boot_cd.dmesg
http://www.golubovsky.org/repos/boot_hda.dmesg

And here's the most interesting part of their diff:

--- boot_cd.dmesg       Sat Jun 16 08:05:00 2007
+++ boot_hda.dmesg      Sat Jun 16 08:05:00 2007

...

-libata version 2.20 loaded.
-ata_piix 0000:00:01.1: version 2.10ac1
+Clocksource tsc unstable (delta = 910814613 ns)
+Time: pit clocksource has been installed.
+Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
+ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
+PIIX3: IDE controller at PCI slot 0000:00:01.1
+PIIX3: chipset revision 0
+PIIX3: not 100% native mode: will probe irqs later
 PCI: Setting latency timer of device 0000:00:01.1 to 64
-ata1: PATA max MWDMA2 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001c000 irq 14
-ata2: PATA max MWDMA2 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001c008 irq 15
-scsi0 : ata_piix
-ata1.00: ATA-7: QEMU HARDDISK, 0.9.0, max UDMA/100
-ata1.00: 10485760 sectors, multi 16: LBA48 
-ata1.00: configured for MWDMA2
-scsi1 : ata_piix
-ata2.00: ATAPI, max UDMA/100
-ata2.00: configured for MWDMA2
-scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK    0.9. PQ: 0 ANSI: 5
-scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.9. PQ: 0 ANSI: 5

...

+    ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio, hdb:pio
+    ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio
+Probing IDE interface ide0...
+hda: QEMU HARDDISK, ATA DISK drive
+ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
+Probing IDE interface ide1...
+hdc: QEMU CD-ROM, ATAPI CD/DVD-ROM drive
+ide1 at 0x170-0x177,0x376 on irq 15
+libata version 2.20 loaded.
+hda: max request size: 512KiB
+hda: 10485760 sectors (5368 MB) w/256KiB Cache, CHS=10402/255/63, (U)DMA
+hda: cache flushes supported
+ hda: hda1
+hdc: ATAPI 4X CD-ROM drive, 512kB Cache, (U)DMA

So the first difference that can be seen is that libata was not loaded when booting from hda image.

And that's probably the reason. So, if the difference may be either in the initialization scripts used on cdrom's initrd vs. installed initrd, or this may be different configuration of kernels used.

I wouldn't say I'm too much disappointed. This all is very experimental, and I will most likely compile a custom much smaller kernel for a virtual machine anyway. But the issue might also affect some real hardware configurations.

PS The x86_64 installation did not have this issue: disks were seen as sdaX from both CDROM and disk boots.

Thanks.