Bug 927719

dracut had been reverted in openSUSE:Factory in order to get snapshots out.

Since then, dracut has been hanging in a staging area, awaiting a fix.

https://build.opensuse.org/project/staging_projects/openSUSE:Factory/F gives an overview of the current state of things.

Dominique: Thanks for the bug.
It took some time to set up a multipath system, etc to find it.
The culprit is found and it should be easy to fix.
There is another bug which I mark as duplicate to this one.

*** Bug 930019 has been marked as a duplicate of this bug. ***

Created attachment 633614 [details]
90multipath-etc-multipath.conf-is-not-required.patch

90multipath: /etc/multipath.conf is not required.

Fixed with the above patch.
Thomas, can you update the dracut rpm?

Done: https://build.opensuse.org/request/show/305875

Fixed and already in factory.

I disagree to the statement of fixed - dracut has been accepted to overcome other issues, but the multipath issue is not fixed.

See latest test run for example:
https://openqa.opensuse.org/tests/63432

Ok, I re-installed on a virtual machine, similar like the test platform and it works for me with latest factory dist (including dracut version 041):

multipath -l
35001405134ccdf0a dm-0 QEMU,QEMU HARDDISK
size=10G features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 0:0:0:1 sdb 8:16 active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 0:0:0:0 sda 8:0  active undef running

rpm -qi dracut
Name        : dracut
Version     : 041

cat /etc/os-release 
NAME=openSUSE
VERSION="20150519 (Tumbleweed)"
...

rpm -qi multipath-tools
Name        : multipath-tools
Version     : 0.5.0
...

I had a quick look at the video from comment #8.
Unfortunately there are not many logs in there.
Everything looks rather similar than what I did.
Any ideas how to reproduce this or how to gain more logs from the failing system. Dracut should fall back into a rescue shell after some more ten seconds of timeout. Is it posssible to access such virtual system somehow?

(In reply to Thomas Renninger from comment #9)
 
> I had a quick look at the video from comment #8.
> Unfortunately there are not many logs in there.
> Everything looks rather similar than what I did.
> Any ideas how to reproduce this or how to gain more logs from the failing
> system. Dracut should fall back into a rescue shell after some more ten
> seconds of timeout. Is it posssible to access such virtual system somehow?

Should be possible to get you an access to a openqa worker in interactive mode. I Will be back 'on duty' coming Wednesday (May 27) - simply ping me in #opensuse-factory and we'll have that setup in no time.

Ok, I finally could reproduce (I guess/hope that is what happens in openqa):
An internal KVM error happens when the system tries to boot from the multipath setup. All you see in vncviewer is:

Booting from local disk...

and I expect the kernel did not get executed yet, but kvm failed on getting it from the multipath device (console= specified on kernel command line, but nothing is shown in serial console output):

/usr/bin/eatmydata /usr/bin/qemu-kvm -chardev socket,id=serial0,path=console.sock,server,nowait -serial chardev:serial0 -m 1024 -cpu qemu64 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -device virtio-scsi-pci,id=scsi0 -device virtio-scsi-pci,id=scsi1 -drive file=bighd.qcow2,cache=unsafe,if=none,id=hd1a,serial=mpath1 -device scsi-hd,drive=hd1a,bus=scsi1.0 -drive file=bighd.qcow2,cache=unsafe,if=none,id=hd1b,serial=mpath1 -device scsi-hd,drive=hd1b,bus=scsi0.0 -cdrom /var/lib/openqa/share/factory/iso/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150606-Media.iso -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -vnc :98,share=force-shared -qmp unix:qmp_socket,server,nowait -monitor unix:hmp_socket,server,nowait -S -monitor telnet:127.0.0.1:20088,server,nowait
KVM internal error. Suberror: 2
extra data[0]: 80000b0d
extra data[1]: 80000b0e
EAX=00000000 EBX=00009eba ECX=00000000 EDX=00000000
ESI=0000000d EDI=00000000 EBP=00000000 ESP=000bfff4
EIP=0000a877 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0028 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0020 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0028 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0000 00000000 ffffffff 00c00000
FS =0000 00000000 ffffffff 00c00000
GS =0000 00000000 ffffffff 00c00000
LDT=0000 00000000 ffffffff 00c00000
TR =0008 00000580 00000067 00008b00 DPL=0 TSS32-busy
GDT=     0000abb0 0000002f
IDT=     000030b8 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=d8 8e d0 b0 08 0f 00 d8 8b 25 f4 af 00 00 89 e8 ff e3 fa fc <89> 25 f4 af 00 00 ea 85 9e 00 00 10 00 60 0f b6 74 24 20 bb ba 9e 00 00 eb e4 61 83 c4 04

Summary:
- There was a dracut multipath issue that has been fixed
- There is a qemu issue, probably with multipath only which seem to not always
  be triggered (always via openqa setup? No idea, I only could run into it once
  out of maybe 5 kvm multipath installations and when I run into it the system
  was set up by Max Lin in the "openqa" way.

I close this bug and will reopen anotherone and assign it to virtualization/qemu/kvm maintainers. And before I have a quick chat with Alex Graf.., maybe he already has an idea...

Thanks a lot Dominique and Max! You helped me a lot getting a bit used to the openqa stuff which I like to know a bit better. This is a cool tool..