Bug 1172703

We're going to need a little more information to be helpful here.
Is libvirt used? You say the grub2 menu works, but can't be controlled by console. Please explain a bit more what you mean here.
Since you distinguish seabios as a failing use case, does that imply that using uefi/ovmf does work? Indeed, if you can provide the commandline used, or the libvirt guest xml file that would be helpful.

Do other recent Tumbleweed snapshots install and boot ok for you?

These are the types of additional information needed for us to be helpful in identifying what is going on.

For the record I did install this snapshot of Tumbleweed with simple defaults (virtio block storage, IDE CDROM, default networking and machine type), 2048 MB RAM, on a SLE12-SP5 host, so v3.1.1.1 qemu and it booted up fine.

(In reply to Bruce Rogers from comment #1)
> We're going to need a little more information to be helpful here.
> Is libvirt used? You say the grub2 menu works, but can't be controlled by
> console. Please explain a bit more what you mean here.
> Since you distinguish seabios as a failing use case, does that imply that
> using uefi/ovmf does work? Indeed, if you can provide the commandline used,
> or the libvirt guest xml file that would be helpful.
> 
> Do other recent Tumbleweed snapshots install and boot ok for you?
> 
> These are the types of additional information needed for us to be helpful in
> identifying what is going on.

Thanks for Bruce's' reponse.

Here is my libvirt command for installation:

virt-install --location /home/joeyli/iso/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20200604-Media.iso -r 2048 --accelerate -n opensuseTW-legacy -f /home/joeyli/qemu-vm/opensuseTW-legacy.qcow2 --network bridge=br0 --vcpus 2 --graphics none --extra-args="console=ttyS0,115200"

The installation works well, but system can not boot after reboot.

Created attachment 838654 [details]
opensuseTW-legacy.xml

The libvirt xml file.

I've spent a little time investigating the bounds of this failure, and am somewhat surprised that a "serial only" interface for x86_64 openSUSE and SLE guests isn't working right with QEMU/KVM virtualization, and apparently hasn't been for quite some time.

From what I see, the grub2 config file terminal parameters that gets used by the Tumbleweed guest as a result of the comment#3 virt-install command-line (exact Tumbleweed version not requires), are these:
terminal_input gfxterm serial
terminal_output gfxterm serial

Note that for this VM, there is no virtualized graphic adapter present for the guest at all. Also note that there is no use of the under-the-covers "VGA to serial" translation which happens via SEABIOS's sercon feature, when QEMU's --nographic is used (see: https://git.seabios.org/cgit/seabios.git/tree/src/sercon.c ) or when the SGABIOS is invoked via QEMU's -device sga option (see: https://github.com/qemu/sgabios/blob/master/design.txt ). Console I/O is serial only, no "tricks" involved.

As added context, it is quite common when setting up a QEMU guest with a serial terminal via QEMU command-line to use the --nographic option, but this isn't actually behaving the same way as a pure serial interface into the guest does, due to the SEABIOS sercon feature mentioned above, which links both VGA BIOS and BIOS Keyboard interfaces to the serial I/O stream. I fear that this usage has perhaps resulted in this bug being present for so long without being noticed and addressed.

In particular, the QEMU command-line set up by libvirt for this guest does not include either --nographic or -device sga.

I note that, eg, installing a Fedora guest using the virt-install command-line shown in comment#3, the terminal_input and terminal_output parameters are "serial console" respectively, and the guest is correctly usable by this pure serial I/O.

If I change the installed /boot/grub2/grub.cfg in the installed Tumbleweed guest to have "serial" instead of "gfxterm serial" as terminal parameters, both grub and the kernel work as expected.

I imagine there are other considerations for why "gfxterm serial" has been used, 
but it isn't correct for the pure serial QEMU guest use case this bug report represents.

Could someone from the yast bootloader team look into this?

I'd be happy to provide any additional QEMU / libvirt / virt-install related details to assist in resolving this bug.

(In reply to Bruce Rogers from comment #5)
[...snip]
> 
> If I change the installed /boot/grub2/grub.cfg in the installed Tumbleweed
> guest to have "serial" instead of "gfxterm serial" as terminal parameters,
> both grub and the kernel work as expected.
> 
> I imagine there are other considerations for why "gfxterm serial" has been
> used, 
> but it isn't correct for the pure serial QEMU guest use case this bug report
> represents.
> 
> Could someone from the yast bootloader team look into this?
> 
> I'd be happy to provide any additional QEMU / libvirt / virt-install related
> details to assist in resolving this bug.

Add Josef Reidinger.

Josef, please, could you have a look? Thanks.

Interesting, we usually propose just one value, but due to some bug for multiple consoles we can do both. Now I need to check what happens in this case. Is possible to get installation logs? Ideally result of save_y2logs called on given disk. This should discover why both are used.

Joey, please attach yast logs.

To collect log files run 'save_y2logs' and attach the log file archive this
command creates (usually named /tmp/y2log-SOMETHING.tar.xz).

If you're unsure what to do, please have a look at

https://en.opensuse.org/openSUSE:Report_a_YaST_bug#logfiles

*** Important ***

When done, please remove the 'needinfo' flag. Otherwise the attachment might
not be noticed.

(In reply to Josef Reidinger from comment #8)
> Interesting, we usually propose just one value, but due to some bug for
> multiple consoles we can do both. Now I need to check what happens in this
> case. Is possible to get installation logs? Ideally result of save_y2logs
> called on given disk. This should discover why both are used.

Sorry for I missed this reqirement. Do you mean that I should run the save_y2logs in guest OS?

(In reply to Joey Lee from comment #10)
> (In reply to Josef Reidinger from comment #8)
> > Interesting, we usually propose just one value, but due to some bug for
> > multiple consoles we can do both. Now I need to check what happens in this
> > case. Is possible to get installation logs? Ideally result of save_y2logs
> > called on given disk. This should discover why both are used.
> 
> Sorry for I missed this reqirement. Do you mean that I should run the
> save_y2logs in guest OS?

yes, please in guess OS after installation or during installation after proposal screen appear.

ping :-)

Hi Joey,

Could you, please, attach the logs when you have time? Thanks!

Feel free to reopen the bug if you can provide requested information.