No CD/DVD boot with new empty system

I had problems in booting new empty systems. KVM instances just did not boot from CD/DVD, only harddisk. The only way to install an OS was to use PXE to boot an iso. Pretty cumbersome, since I do a lot of installations to testdrive software. So I finally decided to get this sorted out and it seems to be a simple thing with an easy solution.

The virtual disk file is not blank! There is random data in there and this seems to confuse the boot process, because the harddisk is not properly detected ("corrupt"). All I had to do was fill the partition table with zero's (which are the first 512 bytes of the harddisk).

Why does Cloudmin not do this when it creates a NEW virtual disk? Easy solution to an annoying problem...

Cloudmin 6.2.kvm

Status: 
Closed (fixed)

Comments

Actually that shouldn't be needed ... cloudmin has a setting to control which device the VM boots from, at System State -> Change Boot Method. For a new empty VM this should be set to cd, but you can change it..

I have set the CD/DVD as the boot device, but it did not work at all. Checked the commandline of KVM and everything seemed OK, but Seaboot just did not boot from CD/DVD. It seemed to "hang" on a "corrupt" harddisk. PXELINUX and gPXE have the same problem.

I found the source of the problem with partition managers. Some (with older age) could not detect the virtual harddisk and then also missed the presence of the virtual CD/DVD.

Had this problem with about 3/4 of new installations. As a workaround I can PXE-boot a small Linux to wipe the disk boot sector, but I think it would be better if Cloudmin did this automatically. Only on newly created disks. Never had this issue before with VMware. I can confirm that they do wipe the boot sector to make sure that a new disk is "blank".

Could you post what appears in the VM console when you try to boot from CD?

I've created numerous empty systems with Cloudmin, but have never run into this issue booting from a CD.

Also, are you running a BIOS on your VMs that is different from the default?

I use defaults for CentOS 6 and installed Cloudmin via the repo and no further tweaking.

Attached are screendumps with the console and the settings of the new VM. The console just hangs at "Booting from Hard Disk...". This can only be resolved with my proposal, as far as I know.

I created a PXE boot menu for PXELINUX with labels for "localboot 0" and "localboot -1", which I access via gPXE on the console (with Ctrl-B). Both boots give me "Booting from Hard Disk... No bootable device.".

If you need more info, let me know.

Can you check in the VM's BIOS if it even sees the virtual CD-ROM drive?

Also, does it help if you shut down the VM, detach the CD image, and then re-attach it as /dev/hdc instead of hdb ?

I changed the CD/DVD image to /dev/hdc. No luck.

Any idea how to get into the VM BIOS? It goes straight to gPXE, in which I find no options to access drives.

Usually you can hit F1 or something during the boot process at the console to access the BIOS menu. But that might be hard when Cloudmin boots the VM..

If you create a VM from one of our provided images and attach an ISO image to it, can you access it as a CD from within the VM?

Tried many keystrokes at boot and F12 seems to do something, but the BIOS goes straight on to gPXE. It all happens too fast, a common problem with booting VM's.

Virtual CD's can be accessed once the harddisk is initialized. Either from the provided images, by using old VMware images, by clearing the boot sector or after installing any OS.

It is really a problem of the BIOS, provided by qemu/kvm. But I almost gave up on Cloudmin because of it. So annoying that basic functions do not work properly.

Weird that nobody else found this before.

I wonder if maybe you are using a different BIOS from other users. Do you have the seabios package installed on your system?

Yes, I have Seabios v0.6.1.2. You can see it on the screendumps. It just came with CentOS 6, I guess...

If you run ps axuwww | grep kvm to find the kvm process for this VM, could you post the full command line to this ticket?

The iso is still on /dev/hdc:

root 24776 84.1 0.2 1031024 18552 ? Sl 10:34 0:25 /usr/libexec/qemu-kvm -name test.fds -m 768 -drive file=/volume/kvm/test.fds.img,media=disk,index=0,if=virtio,boot=on -drive index=2,media=cdrom,file=/volume/shares/archive/software/linux/linuxmint-12-gnome-cd-nocodecs-32bit.iso,if=ide -boot d -net tap,vlan=0,script=/volume/kvm/test.fds-eth0.sh -net nic,vlan=0,macaddr=02:54:00:13:3D:16,model=e1000 -vnc :4,password -usbdevice tablet -monitor tcp:127.0.0.1:40003,server

That looks fine too ..

So I did some testing on Scientific Linux 6, which is basically a clone of CentOS 6 .. and booting from CD worked fine. However, I was using the Ubuntu 12.04 ISO image - what OS are you attempting to boot there?

I have tried to boot CentOS 5.8 and 6.2 (x64), Elastix 2.3 and FreePBX 1.8 (both basically CentOS 5 x86), Lint Mint 12 (32 bit), Windows XP (32 bit), Windows 7 and 2008 R2 (64 bit), Acronis TrueImage 2011, BootItNg/BootItBm. Once booted these OS have the iso-DVD available. But booting from iso mostly fails when a new virtual HD contains random data.

Never tried to boot from a physical DVD drive, because the system doesn't have one. Next week I shall build a new system with physical DVD. Will see how that works.

I do not think that the iso's are the problem, but the BIOS that must boot from it. What BIOS and version is used by the VM on SL6?

Are the first 512 bytes of a new virtual disk zero'd? This can be the case with a brand new drive. My drive is now in use for over a year in a server, so every bit of it is probably written before.

You could test if the drive contents are the cause by shutting down the VM, manually zeroing it, and then starting up the VM again.

To zero the drive, run the command cloudmin list-disks --host yourvm --multiline to see the disk image devices .. the first line should be the device or file for the main drive, like /kvm/yourvm_img or /dev/vg/yourvm_img

Then run the command :

dd if=/dev/zero of=/kvm/yourvm_img bs=512 count=1

I already mentioned in my first post that zeroing the virtual drive is the solution. Since I have to do this with most new installs, I requested that Cloudmin should zero the first 512 bytes of a new virtual drive.

We are back at my first post... Please reread it.

Ok, instead of trying to work out why the BIOS doesn't like this disk, I will change Cloudmin in the next release to simply zero out the first 32k. Based on your tests, that will fix the issue.

Automatically closed -- issue fixed for 2 weeks with no activity.