Bug 1310737 - SLOF cannot boot without a console
SLOF cannot boot without a console
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: SLOF (Show other bugs)
7.2
ppc64le Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Thomas Huth
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-22 10:11 EST by Laurent Vivier
Modified: 2016-11-04 00:33 EDT (History)
8 users (show)

See Also:
Fixed In Version: SLOF-20160223-2.gitdbbfda4.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-04 00:33:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laurent Vivier 2016-02-22 10:11:24 EST
Description of problem:

Trying to boot QEMU with virtconsole doesn't work if we remove the spapr-vty and the VGA display. In fact, SLOF cannot be booted without a (known) console.

Version-Release number of selected component (if applicable):

SLOF-20150313-5.gitc89b0df.el7.noarch
qemu-kvm-rhev-2.3.0-31.el7_2.7.ppc64le

How reproducible:

100%

Steps to Reproduce:
1. start qemu-kvm without console: -nodefaults -nographic and without "-device spapr-vty" and without "-device VGA"

Actual results:

Guest hangs and the kernel is not started.

Expected results:

After boot, we should be able to login in the guest using network or virtconsole.

Additional info:

my test command line:

$QEMU -name test-console \
        -machine pseries,accel=kvm,usb=off -m 32768 -realtime mlock=off \
        -smp 4 \
        -chardev stdio,id=conmon,mux=on,signal=off \
        -mon conmon \
        -nodefaults \
        -rtc base=localtime,clock=host \
        -boot strict=on \
        -device spapr-vscsi,id=scsi0,reg=0x2000 \
        -drive file=$IMAGE,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none \
        -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
        -msg timestamp=on \
        -device spapr-vlan,netdev=hostnet0,id=net0,mac=52:54:00:22:ab:39,reg=0x1000 \
        -netdev bridge,id=hostnet0,br=virbr0 \
        -device virtio-serial \
        -device virtconsole,chardev=vty \
        -chardev pty,id=vty \
        -nographic

I use vanilla kernel with virtio-serial and virtconsole modules and getty configured to start on the virtconsole, so I'm able to see if the guest has started or not. I did several tests before, using virtconsole and spapr-vty or VGA console. If we have at least a spapr-vty SLOF starts and boot the kernel and then we are able to login using either the spapr-vty console or the virtconsole console.

In the case of dual console (spapr + virtio), I use systemctl to start/enable getty on the second console (virtio):
systemctl start getty@hvc1.service
systemctl enable getty@hvc1.service

SLOF should be able to manage "no-console":

board-qemu/slof/OF.fs:

: set-default-console
    s" linux,stdout-path" get-chosen IF
        decode-string
        ." Using default console: " 2dup type cr
        io
        2drop
    ELSE
        ." No console specified "
        " screen" find-alias dup IF nip THEN
        " keyboard" find-alias dup IF nip THEN
        AND IF
          ." using screen & keyboard" cr
          " screen" output
          " keyboard" input
        ELSE
          " hvterm" find-alias IF
            drop
            ." using hvterm" cr
            " hvterm" io
          ELSE
            " /openprom" find-node ?dup IF
                set-node
                ." and no default found, creating dev-null" cr
                " dev-null.fs" included
                " devnull-console" io
                0 set-node
            THEN
          THEN
        THEN
    THEN
;
Comment 2 Thomas Huth 2016-02-23 04:18:28 EST
The problem is likely the "read" function in dev-null.fs: It tells the client that input characters are constantly available. This causes grub to hang forever at the kernel selection prompt.

I can fix this issue with the following patch:

diff --git a/board-qemu/slof/dev-null.fs b/board-qemu/slof/dev-null.fs
--- a/board-qemu/slof/dev-null.fs
+++ b/board-qemu/slof/dev-null.fs
@@ -12,7 +12,7 @@ new-device
 ;
 
 : read  ( adr len -- actual )
-  nip
+    2drop 0
 ;
 
 : setup-alias

However, I do not have a proper Linux setup for virtio-console yet.
Laurent, could you please try whether you can successfully boot your guest when the above fix has been applied?
Comment 3 Laurent Vivier 2016-02-23 08:29:38 EST
(In reply to Thomas Huth from comment #2)
> The problem is likely the "read" function in dev-null.fs: It tells the
> client that input characters are constantly available. This causes grub to
> hang forever at the kernel selection prompt.
> 
> I can fix this issue with the following patch:
> 
> diff --git a/board-qemu/slof/dev-null.fs b/board-qemu/slof/dev-null.fs
> --- a/board-qemu/slof/dev-null.fs
> +++ b/board-qemu/slof/dev-null.fs
> @@ -12,7 +12,7 @@ new-device
>  ;
>  
>  : read  ( adr len -- actual )
> -  nip
> +    2drop 0
>  ;
>  
>  : setup-alias
> 
> However, I do not have a proper Linux setup for virtio-console yet.
> Laurent, could you please try whether you can successfully boot your guest
> when the above fix has been applied?

It works fine. Thanks, Thomas!
Comment 4 Thomas Huth 2016-03-21 05:04:35 EDT
Patch has been accepted upstream:
http://git.qemu.org/?p=SLOF.git;a=commitdiff;h=e56149ca790859e0
Comment 5 Miroslav Rezanina 2016-05-06 08:47:50 EDT
Fix included in SLOF-20160223-2.gitdbbfda4.el7
Comment 7 Qunfang Zhang 2016-06-07 23:29:23 EDT
Reproduced this bug with SLOF-20160223-1.gitdbbfda4.el7.noarch.

CLI:

#  /usr/libexec/qemu-kvm -name test-console         -machine pseries,accel=kvm -m 4G -realtime mlock=off         -smp 4         -chardev stdio,id=conmon,mux=on,signal=off         -mon conmon         -nodefaults         -rtc base=localtime,clock=host         -boot strict=on         -device spapr-vscsi,id=scsi0,reg=0x2000         -drive file=rhel72-ppc64le-virtio.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none         -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1         -msg timestamp=on         -device spapr-vlan,netdev=hostnet0,id=net0,mac=52:54:00:22:ab:39,reg=0x1000         -netdev tap,id=hostnet0         -device virtio-serial         -device virtconsole,chardev=vty         -chardev pty,id=vty -nographic

Guest can not boot up and qemu-kvm consumes 100% cpu, ping guest,failed:

 17841 root      20   0 4394816  87616  20928 S 100.3  0.3   0:50.79 qemu-kvm                                                                         
 17908 root      20   0  117568   8512   3904 R   1.3  0.0   0:00.33 top   


Verified pass on SLOF-20160223-4.gitdbbfda4.el7.noarch.rpm with same command line.
Guest could boot up successfully and can login with network.

So this bug is fixed.
Comment 9 errata-xmlrpc 2016-11-04 00:33:44 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2355.html

Note You need to log in before you can comment on or make changes to this bug.