Bug 1523083
Summary: | [s390x] Qemu process terminated while booting with additional module enabled by mkinitrd | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Zhengtong <zhengtli> |
Component: | qemu-kvm-ma | Assignee: | Cornelia Huck <cohuck> |
Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 7.5-Alt | CC: | cohuck, david, dhildenb, knoel, michen, qzhang, thuth, zhengtli |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | s390x | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-12-08 08:34:02 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Zhengtong
2017-12-07 08:14:39 UTC
The issue happened on s390x platform with kernel:4.14.0-15.el7a.s390x 4.14.0-15.el7a.s390x broken 4.14.0-14.el7a.s390x good 4.14.0-12.el7a.s390x good 4.14.0-8.el7a.s390x good So this bug is a regression. (In reply to Zhengtong from comment #2) > The issue happened on s390x platform with kernel:4.14.0-15.el7a.s390x > > > 4.14.0-15.el7a.s390x broken > 4.14.0-14.el7a.s390x good > 4.14.0-12.el7a.s390x good > 4.14.0-8.el7a.s390x good > > So this bug is a regression. I assume this refers to the guest kernel? (In reply to Cornelia Huck from comment #4) > I assume this refers to the guest kernel? yes, It is. and the host kernel is always: 4.14.0-15.el7a.s390x oh...wait. I think I can still hit this issue on -14 and -13 now. I will do more test on the different versions. update them later. Just looked at your boot messages again. It seems you boot from a virtio-scsi disk, but add virtio-blk to your initrd. Does this reproduce if you add virtio-scsi as well? (In reply to Cornelia Huck from comment #7) > Just looked at your boot messages again. It seems you boot from a > virtio-scsi disk, but add virtio-blk to your initrd. Does this reproduce if > you add virtio-scsi as well? I tried with "virtio_net" and "virtio_scsi" module, Both hit this issue, two. In my latest test result. This issue happened on 4.14.0-9.el7a.s390x, but not on 4.14.0-8.el7a.s390x. Could you please provide the full console output of mkinitrd for the case where it is failing? Just to make sure: a) you're booting into kernel < 4.14.0-15.el7a.s390x b) you update the kernel to 4.14.0-15.el7a.s390x via rpm/yum c) you generate an initrd manually d) you reboot Can you answer: 1. you need to generate the initrd manually shouldn't there get one generated automatically? Why is that necessary? 2. do you run "zipl" _after_ you generated the initrd? Otherwise this might be the problem. Can you also provide your QEMU command line? (or libvirt xml) Thanks! (In reply to Thomas Huth from comment #9) > Could you please provide the full console output of mkinitrd for the case > where it is failing? mkinitrd application has no any std output while running . And the console output of guest after ejecting "reboot" is in comment #0 (In reply to David Hildenbrand from comment #10) > Just to make sure: > > a) you're booting into kernel < 4.14.0-15.el7a.s390x > b) you update the kernel to 4.14.0-15.el7a.s390x via rpm/yum > c) you generate an initrd manually > d) you reboot > > Can you answer: > > 1. you need to generate the initrd manually shouldn't there get one > generated automatically? Why is that necessary? Actually, this test scenario comes from a autotest code. The new initrd should install all the virtio drivers, and prepare a easy ENV to do test. Yes , there is already a initrd in directory "/boot/" before I making one. > > 2. do you run "zipl" _after_ you generated the initrd? Otherwise this might > be the problem. Oh..no. I tried with "zipl" after re-making inird just now. the issue disappeared.. Thanks very much. > > Can you also provide your QEMU command line? (or libvirt xml) /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -machine s390-ccw-virtio \ -nodefaults \ -vga none \ -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/avocado_ut7GP4/monitor-qmpmonitor1-20171115-020901-7Fni7fsG,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/avocado_ut7GP4/monitor-catch_monitor-20171115-020901-7Fni7fsG,server,nowait \ -mon chardev=qmp_id_catch_monitor,mode=control \ -chardev socket,id=serial_id_serial0,path=/var/tmp/avocado_ut7GP4/serial-serial0-20171115-020901-7Fni7fsG,server,nowait \ -device sclpconsole,chardev=serial_id_serial0 \ -device virtio-scsi-ccw,id=virtio_scsi_ccw0 \ -drive file=/home/zhengtli/root_dir/ALT-Server-7.4-s390x-virtio-scsi.qcow2,id=drive0,if=none,format=qcow2,snapshot=on \ -device scsi-hd,bus=virtio_scsi_ccw0.0,drive=drive0,id=hd1 \ -netdev tap,id=hostnet0 \ -device virtio-net-ccw,netdev=hostnet0,id=net0 \ -device diag288,id=wdt0 \ -m 1024 \ -smp 1,maxcpus=1,cores=1,threads=1,sockets=1 \ -cpu 'host' \ -vnc :1 \ -rtc base=utc,clock=host,driftfix=slew \ -boot strict=on \ -monitor stdio \ > > Thanks! Based on comment #12. We need to to "zipl" to update the boot behaviors after re-making initrd. Maybe we can close this bug now. But I have a little doubt that why no need to do this(zipl) for kernels whose version is lower than 4.14.0-8.el7a.s390x (In reply to Zhengtong from comment #13) > Based on comment #12. > > We need to to "zipl" to update the boot behaviors after re-making initrd. > Maybe we can close this bug now. Likely yes. > But I have a little doubt that why no need to do this(zipl) for kernels > whose version is lower than 4.14.0-8.el7a.s390x I think that was just by accident. If there was already a ramdisk before making a new one with mkinitrd, the new might overwrite the old one on the disk at the very same location (i.e. the very same sectors on the disk). So the zipl boot code then could load the new ramdisk from the old location. But as soon as one sector location changes, the ramdisk will be loaded corrupted when you did not run "zipl" before the reboot again. (In reply to Thomas Huth from comment #14) > > > But I have a little doubt that why no need to do this(zipl) for kernels > > whose version is lower than 4.14.0-8.el7a.s390x > > I think that was just by accident. If there was already a ramdisk before > making a new one with mkinitrd, the new might overwrite the old one on the > disk at the very same location (i.e. the very same sectors on the disk). So > the zipl boot code then could load the new ramdisk from the old location. > But as soon as one sector location changes, the ramdisk will be loaded > corrupted when you did not run "zipl" before the reboot again. sounds reasonable, thanks OK, from the comments above, this is a test case bug (needs to include an invocation of zipl)? If you agree, I'll close this. (In reply to Cornelia Huck from comment #16) > OK, from the comments above, this is a test case bug (needs to include an > invocation of zipl)? > > If you agree, I'll close this. Go ahead |