Control: reopen -1
Control: reassign -1 src:linux,rootskel
Control: severity -1 serious

(Don't know if this is a blocker for the release, but it should at
least be reviewed before we release IMO, hence the severity)

On Sun, Apr 07, 2019 at 12:53:35AM +0100, Ben Hutchings wrote:
> On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> > On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > > My suspicion is that the support multiple consoles in parallel [2] 
> > > introduced
> > > this particular regression. I haven't done any debugging yet though as I'm
> > > not sure where to start, I haven't touched the rootskel package before and
> > > therefore would be interested in any pointers how to debug this.
> >
> > The problem seems to be the fact that the sparc64 kernel uses different 
> > names
> > for /proc/console and the actual console name:
> >
> > root@landau:~# cat /proc/consoles
> > ttyHV0               -W- (EC p  )    4:64
> > tty0                 -WU (E     )    4:1
> > root@landau:~# readlink /sys/dev/char/4:64
> > ../../devices/root/f0299a70/f029b788/tty/ttyS0
>
> The inconsistent name seems like a kernel bug...
>
> > root@landau:~#
> >
> > And this is what used to make it work [1]:
> >
> >         *) # >= 2.6.38
> >             console_major_minor="$(get-real-console-linux)"
> >             console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
> >             console="${console_raw##*/}"
> >             ;;
>
> So maybe rootskel should use that again, but applied to each console's
> char device number.
>
> (Though directly using the symlinks under /dev/char seems cleaner than
> poking in sysfs.)

Just got a report in #debian-cd of a user running into this issue on
s390x with Hercules; a subset of the messages sent in conversation are
below:

[20:12:18]  <gruetzkopf>        steal-ctty: No such file or directory
[20:12:29]  <gruetzkopf>        will go hunt this down once i find time
[20:12:52]  <gruetzkopf>        (DI buster RC2 / s390x)
[21:52:40]  <jrtc27>    gruetzkopf: cat /proc/consoles ?
[21:54:00]  <jrtc27>    should give something like:
[21:54:00]  <jrtc27>    ttyS0                -W- (EC p  )    4:64
[21:54:22]  <jrtc27>    rootskel will prefer a console which has the C flag
[21:55:17]  <gruetzkopf>        now let's see how to get there
[21:55:57]  <gruetzkopf>        (note: running in hercules, not real hw or qemu 
where i'd have virtio console)
[22:01:39]  <gruetzkopf>        cat /proc/consoles
[22:01:40]  <gruetzkopf>        ttyS0                -W- (EC p  )    4:64
[22:02:05]  <jrtc27>    and ls -l /dev/ttyS0?
[22:03:06]  <gruetzkopf>        ls: /dev/ttyS0: No such file or directory
[22:03:06]  <gruetzkopf>        oh, fun!
[22:04:36]  <jrtc27>    and ls -l /sys/dev/char/4:64 ?
[22:06:06]  <gruetzkopf>        ls -l /sys/dev/char/4:64
[22:06:06]  <gruetzkopf>        lrwxrwxrwx    1 root     root             0 Jun 
26 21:05 /sys/dev/char/4:64 -> .
[22:06:06]  <gruetzkopf>        ./../devices/virtual/tty/sclp_line0
[22:06:28]  <jrtc27>    ok, so, it's not /dev/ttyS0, it's /dev/sclp_line0?
[22:06:32]  <jrtc27>    (does that exist?)
[22:06:48]  <jrtc27>    we had an issue like this on sparc64 (#926539)
[22:07:38]  <gruetzkopf>        i just found that
[22:07:53]  <jrtc27>    does that device node exist for you?
[22:08:13]  <gruetzkopf>        crw--w----    1 root     root        4,  64 Jun 
26 20:58 /dev/sclp_line0
[22:08:43]  <gruetzkopf>        (and so does /dev/ttysclp0)

This is the "fault" of drivers/s390/char/sclp_tty.c. I don't know what
the best fix is; we could also patch the kernel to ensure this shows up
as /dev/sclp_line0 in /proc/consoles like sparc64 now does for sunhv,
but I worry now that this might be a game of whack-a-mole and there are
other character device drivers out there that also suffer from this.
Perhaps therefore we need to go back to looking up the device name from
the device number as has been suggested already...

James

Reply via email to