Package: kvm
Version: 70+dfsg-1 

Hello Debian Maintainers,

In a short break when waiting for some software tests finishing at work, I 
wrote this bug report attached as .txt-file out of my head without having my ws 
at home in front of me. Most information should be correct. Please excuse that 
I did not use your bug report template or tool. I did not have that much time, 
but I think your interested, because I found none of these bugs listed 
somewhere and felled it was my duty to write any kind of report.


Best regards

Holger Fischer
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

Hello dear Debian Maintainers,

in the last 3 weeks I found some bugs.

Here some details to debian and my hardware:

Asus m2a-vm (sb600/amd690g)
Athlon be2350
8g ram ddr800 (4x2g)
internal sata samsung sata 2,5" 160gb connected to sata port 4 of mainboard
sometimes external sata over esata slot bracket samsung 2,5" 250gb connected to 
sata port 1 of mainboard

debian
unstable / sid amd64 branch, daily updated (like today in the morning)
kernel 2.6.25-2 - 2.6.25.5
grub2 (which I have some problems with)
kde4
kvm 70
vde (vdekvm)
bridge-utils
ext3 (mostly with journal=data) as filesystem for all my partitions

1st bug: most serious: device salad when connecting a esata device before boot:

Normally my root device is /dev/sda6. When I connect the ext. sata before next 
boot my root device becomes /dev/sdb6 and the ext. sata is sda. 

But not today:
sda is obvious the external disk and sdb the internal, but mount tells me that 
sda6 is my root device. gparted tells me that there is no sda6, because my 
external disk doesn't contain a 6th partition

blkid tells me that there is a sda6 and a sdb6 with the same uuid (there should 
only be sdb6)

What could it be related to? Where is that salad from?

grub2 (as kernel parameter I give root=UUID=<uuid>)
in my fstab I use UUID=<uuid> for mounting the root partition

I detected this problem today in the morning. I think one of the updates in the 
last 3 weeks or my switch to grub2 is responsible for that.

2nd bug: kvm pxe boot with model=e1000 broken - doesnt recognize DHCP 
information - fine with model=rtl8139

This worked with kvm prior 70, must be broken somewhere in the last 3 weeks
daemon log on dhcp server says dhcpoffer <ip> to mac <mac> (or similar) again 
and again but pxe with e1000 in kvm says .no dhcp information again and again 
when doing the same with model=rtl8139 all is fine, gets dhcp, gets pxe file, 
boots ....
when booting linux (not using -boot n in kvm commandline) linux gets ip address 
as usual with model=e1000
I think problem could be found somewhere in the e1000 boot rom file

3rd bug grub2 does not install in boot block of actual root partition or 
actually mounted partition

In my mbr I installed gag. It boots from my bootable partitions. Therfore I 
install grub in the boot block of a partition I want to boot from, I find this 
more "sorted". This worked fine for years.

I tried it with some prior version of grub2 (I think 1.96-200805xx) on my root 
(like above sda6) as follows:

grub-install /dev/sda6

This does not work. After a lot of tries and some dangerous 
grub-install /dev/sda6
grub-install /dev/sda7
dd if=/dev/sda7 of=/dev/sda6 bs=512 count=1 
actions I got it to work, but this does not always work. I think that work's 
because sda7 is not mounted at this moment. (There's a longer story behind it 
with checking the difference of the first 512 bytes of sda6 and sda7 with 
vbindiff and finding the right jumppoint to core.img...., if you are interested 
let me know)

Now I try it always with sda7 by doing
mkdir /1
mount /dev/sda7 /1
grub-install --root-directory=/1 /dev/sda7
umount /1
rmdir /1

when I then do 
kvm /dev/sda
(I know this is dangerous because sda6 is mounted as root and kvm does not 
check it, but for only trying the bootloader on sda7 I won't destroy anything 
on sda6)
the bootloader works flawless
when I reboot and try this from real hardware grub2 stops somewhere in the 
beginning  with a short message.
When I do kvm /dev/sda after this reboot I get the same message like from real 
hardware. 
My thoughts:
I think the message I get after reboot is the message from my last successfull 
grub2 dd if=.. installation, because the changes that should have been written 
to the 1st 512 bytes of sda7 are not written back by grub-install, they were 
only cached. This only occurs when the boot block I want grub2 boot.img install 
on is actually mounted (I think some tests I did proved this, the boot sector 
of the partition stayed the same after a reboot like before grub-install). 
Maybe this information helps you.

There's another thing related to this:
One advantage of grub1 (or grub-legacy) was that you could install it somewhere 
and then create or change the grub.conf or menu.lst without the need of 
reinstalling grub or a update-grub or grub-setup

With grub2 this does not work. When I change something in the grub.cfg I must 
do a grub-setup or update-grub to "apply" changes. This means, the grub.cfg is 
not really used when booting?  
Did I do something wrong? Will this always be the behaviour of grub2? (If yes, 
then grub2 is a big step back in the evolution of bootloader software, it 
behaves like old lilo did and I don't need full size splash images, I need 
easy-to-maintain software)

Best regards 

Holger Fischer

Don't make Linux too much like Windows, because I don't like Windows but I like 
Linux and other ?NIX

Reply via email to