Bug#926539: rootskel: steal-ctty no longer works on s390x

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#926539: rootskel: steal-ctty no longer works on s390x

John Paul Adrian Glaubitz
Hi!

On 5/20/20 11:00 AM, Valentin Vidić wrote:
> Similar change for console name on s390x was not accepted:
>
>   https://lkml.org/lkml/2020/5/19/854
>
> so please fix in rootskel.

I don't see any discussion in this thread. I would like to know the reasoning
why kernel upstream thinks that this naming inconsistency is correct. It
makes no sense, in my opinion and it can potentially trigger more problems.

Also, this bug report should be merged with the other one that I referenced
yesterday.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Bug#926539: rootskel: steal-ctty no longer works on s390x

John Paul Adrian Glaubitz
On 5/20/20 12:42 PM, Valentin Vidić wrote:
> It is hard to tell, but it seems the current state is hardcoded
> in different places:
>
> https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html

This wouldn't cause breakage as with your change, the console name
would actually be ttysclp0.

> https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html

Well, IBM could just update their documentation.

> I think it would be better to make debian-installer smarter about
> this since we will probably run into the same problem again with
> a different architecture/driver.

It was only SPARC which had this issue as well and where it was fixed. For
all the other architectures, the console and driver names already match.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Bug#926539: rootskel: steal-ctty no longer works on s390x

Philipp Kern-6
In reply to this post by John Paul Adrian Glaubitz
On 20.05.20 12:42, Valentin Vidić wrote:

> On Wed, May 20, 2020 at 11:19:53AM +0200, John Paul Adrian Glaubitz wrote:
>> Ah, sorry. I was seeing the cached version of the thread, refreshing helped.
>>
>> In any case, the SPARC kernel maintainer (Dave Miller) had the same argument
>> that it would potentially break existing setups but eventually I could
>> convince him that the change was right.
>>
>> Not sure which distributions he has in mind.
>
> It is hard to tell, but it seems the current state is hardcoded
> in different places:
>
> https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html
> https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html
>
> I think it would be better to make debian-installer smarter about
> this since we will probably run into the same problem again with
> a different architecture/driver.

qemu-system-s390x is probably the least representative here. I recall
that the consoles for z/VM and LPAR were actually different. As alluded
to by the thread LPAR uses SCLP while you get 3215 on z/VM.

I'm all for making d-i smarter. But I think we should start by trying to
back merge all the improvements Canonical made on Ubuntu instead of
Debian as part of their s390x contract. Maybe trying ubuntu-installer
and seeing if that works correctly would be a good start.

But then I keep wondering how representative qemu is. Is VT220 SCLP even
something you get on a real z machine? Not that we shouldn't fix qemu,
of course. But Hercules might be closer to the real thing in this regard.

Kind regards
Philipp Kern