Bug 1351968 - The /proc/consoles does not list the cmdline console
Summary: The /proc/consoles does not list the cmdline console
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2016-07-01 09:28 UTC by Lukas Doktor
Modified: 2020-05-20 09:29 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-03 16:26:46 UTC
Type: Bug


Attachments (Terms of Use)

Description Lukas Doktor 2016-07-01 09:28:17 UTC
Description of problem:
When installing s390x guest using kickstart I use a little script to write to the current console:

function ECHO { for TTY in `cat /proc/consoles | cut -f1 -d' '`; do echo "$*" > /dev/$TTY; done }

This works fine for x86_64, ppc64 and aarch64, each using different console, but it does not work on s390, because the /proc/consoles does not list the console specified on kernel cmdline.

Version-Release number of selected component (if applicable):
Fedora-Server-DVD-s390x-23.iso 

How reproducible:
Always

Steps to Reproduce:
1. Run installation, I'm using `avocaod-vt`, the qemu command is:
    MALLOC_PERTURB_=1  /usr/local/bin/qemu-system-s390x \
    -S  \
    -name 'avocado-vt-vm1' \
    -machine s390-ccw-virtio  \
    -nodefaults  \
    -vga none  \
    -chardev socket,id=hmp_id_hmp1,path=/var/tmp/avocado_P5KN9W/monitor-hmp1-20160701-052711-ZWrvMKs7,server,nowait \
    -mon chardev=hmp_id_hmp1,mode=readline  \
    -chardev socket,id=hmp_id_catch_monitor,path=/var/tmp/avocado_P5KN9W/monitor-catch_monitor-20160701-052711-ZWrvMKs7,server,nowait \
    -mon chardev=hmp_id_catch_monitor,mode=readline  \
    -chardev socket,id=serial_id_serial0,path=/var/tmp/avocado_P5KN9W/serial-serial0-20160701-052711-ZWrvMKs7,server,nowait \
    -device sclpconsole,chardev=serial_id_serial0 \
    -drive id=drive_image1,if=none,aio=threads,format=qcow2,file=/usr/share/avocado/data/avocado-vt/images/f23-s390x.qcow2 \
    -device virtio-blk-ccw,id=image1,drive=drive_image1,bootindex=1 \
    -device virtio-net-ccw,mac=9a:6f:70:71:72:73,id=iditdkcd,netdev=idDxpjtr  \
    -netdev user,id=idDxpjtr,hostfwd=tcp::5000-:22,hostfwd=tcp::5001-:12323 \
    -m 1024  \
    -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
    -cpu 'host' \
    -device virtio-scsi-ccw,id=virtio_scsi_ccw0 \
    -drive id=drive_cd1,if=none,aio=threads,media=cdrom,file=/usr/share/avocado/data/avocado-vt/isos/linux/Fedora-Server-DVD-s390x-23.iso \
    -device scsi-cd,id=cd1,drive=drive_cd1,bootindex=2 \
    -drive id=drive_unattended,if=none,aio=threads,media=cdrom,file=/usr/share/avocado/data/avocado-vt/images/f23-ppc64le/ks.iso \
    -device scsi-cd,id=unattended,drive=drive_unattended,bootindex=3  \
    -kernel '/usr/share/avocado/data/avocado-vt/images/f23-s390x/kernel.img'  \
    -append 'ks=cdrom nicdelay=60 console=ttysclp0'  \
    -initrd '/usr/share/avocado/data/avocado-vt/images/f23-s390x/initrd.img'  \
    -vnc :0  \
    -rtc base=utc,clock=host \
    -boot strict=on \
    -enable-kvm
2. Switch to console using alt+tab
3. cat /proc/consoles

Actual results:
ttyS1                -W- (E  p  )    4:65

Expected results:
ttysclp0 ...

Additional info:
[anaconda root@localhost ~]# cat /proc/consoles
ttyS1                -W- (E  p  )    4:65

[anaconda root@localhost ~]# cat /proc/cmdline
ks=cdrom nicdelay=60 console=ttysclp0

[anaconda root@localhost ~]# echo "foo" > /dev/ttyS1
[anaconda root@localhost ~]# echo "bar" > /dev/ttysclp0
bar                          echo "bar" > /dev/ttysclp0

[anaconda root@localhost ~]# ls /dev/tty*
/dev/tty  /dev/tty4  /dev/ttyS1  /dev/ttysclp0

Comment 1 Laura Abbott 2016-09-23 19:39:24 UTC
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

Comment 2 Lukas Doktor 2016-10-04 11:35:15 UTC
I don't have the time and system to retest this, but I believe it's still valid.

Comment 3 Fedora End Of Life 2016-11-25 09:22:52 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Fedora End Of Life 2016-12-20 21:06:59 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 5 Richard W.M. Jones 2017-05-17 09:41:10 UTC
This is still wrong in Rawhide:

$ virt-rescue --scratch

The virt-rescue escape key is ‘^]’.  Type ‘^] h’ for help.

------------------------------------------------------------

Welcome to virt-rescue, the libguestfs rescue shell.

Note: The contents of / (root) are the rescue appliance.
You have to mount the guest’s partitions under /sysroot
before you can examine them.

><rescue> cat /proc/consoles 
ttyS1                -W- (E  p  )    4:65


I am using kernel-4.10.0-1.fc26.s390x.

Comment 6 Lukas Doktor 2017-10-23 10:50:08 UTC
As well as the latest RHEL.7.

Comment 7 Christian Borntraeger 2017-12-06 14:32:08 UTC
It is not a bug as far as I can tell. 
The _tty_ is named ttysclp0, but the console driver is named ttyS1 (for historical reasons)

so on the command line doing "console=ttysclp0" should not change anything because this is not a valid console name. "console=ttyS1" (ascii console) or "console=ttyS0" (line mode console) should work. This would then also match /proc/consoles

Comment 8 Christian Borntraeger 2017-12-06 14:33:12 UTC
See drivers/s390/char/sclp_vt220.c


#define SCLP_VT220_DEVICE_NAME          "ttysclp"
#define SCLP_VT220_CONSOLE_NAME         "ttyS"
#define SCLP_VT220_CONSOLE_INDEX        1       /* console=ttyS1 */

[...]
static struct console sclp_vt220_console =
{
        .name = SCLP_VT220_CONSOLE_NAME,
[...]
        .index = SCLP_VT220_CONSOLE_INDEX
};

static int __init
sclp_vt220_con_init(void)
{
[...]
        register_console(&sclp_vt220_console);
        return 0;
}

Comment 9 Thomas Huth 2018-07-11 15:46:30 UTC
I think using the major:minor number from /proc/consoles should do the job here. 4:65 is the major:minor of /dev/ttysclp0 as far as I can see.

Comment 10 Thomas Huth 2020-02-01 19:23:30 UTC
Is the major:minor number working well enough so that we could close this bug nowadays?

Comment 11 Lukas Doktor 2020-02-03 16:18:56 UTC
Major:minor works well, it is safe to close this bug, but it is a bit confusing.

Comment 12 John Paul Adrian Glaubitz 2020-05-20 09:29:48 UTC
The same bug breaks debian-installer as well [1,2] and also previously affected sparc64 where my patch to fix the naming inconsistency was accepted [3].

Not sure why this shouldn't be fixed for s390x as well. The worst regression that happens that admins will have to update their scripts to use the
proper serial console, i.e. stop using work-arounds and rely on /proc/consoles as it should be.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961056
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git/commit/?id=07a6d63eb1b54b5fb38092780fe618dfe1d96e23


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