OK. Steve stayed up very late last night checking that this worked OK
on x86 and adding some useful logging (allowing for the fact that it
needs to work before syslog is actually started).
We've checked some more stuff today, including testing the matching
finish-install functionality on full inst
On 2019-02-21 00:55 +, Steve McIntyre wrote:
> Hey Wookey,
>
> Reviewing the code from your patches in sequence, I think the approach
> looks good *except* I think you've missed a patch or a commit or
> something.
>
> Trying to apply debian-installer-multiple-consoles.patch and
> rootskel-mul
On 2019-02-21 00:55 +, Steve McIntyre wrote:
> Hey Wookey,
>
> Reviewing the code from your patches in sequence, I think the approach
> looks good *except* I think you've missed a patch or a commit or
> something.
>
> Trying to apply debian-installer-multiple-consoles.patch and
> rootskel-mul
Hey Wookey,
Reviewing the code from your patches in sequence, I think the approach
looks good *except* I think you've missed a patch or a commit or
something.
Trying to apply debian-installer-multiple-consoles.patch and
rootskel-multiple-consoles-inittab.patch in sequence, there are patch
failure
On Sat, 2019-02-16 at 02:19 +, Wookey wrote:
[...]
> Issues:
> The framebuffer console came up with some UTF-8 chars as blocks (ones
> not in 8859-1?). I've seen this before once with the old code then it
> went away again, so I'm not sure it's anything to do with these
> changes but it might
On 2019-02-09 04:11 +, Wookey wrote:
> Future work:
>
> All this faffage has made me realise that a better approach to all
> this would probably be to get rid of all this 'steal-ctty' bodgery,
> and use init to do it's job: it's designed to run multiple things on
> multiple consoles, and deal
On 2019-01-19 11:08 +, Steve McIntyre wrote:
> On Sat, Jan 19, 2019 at 04:27:05AM +, Wookey wrote:
[Re: adding multiple console support to D-I, including changing
/var/run/console-device with one device line to be
/var/run/console-devices with 1 or more lines]
> >The only other place this
On 2019-02-09 04:11 +, Wookey wrote:
> On 2019-01-25 03:45 +, Wookey wrote:
>
> Attached is a patch which provides working multiconsole support for
> linux (not hurd or bsd, sorry).
>
> One bug I just noticed in the bit we did today is that the 'default'
> preferred console (for when one
On 2019-01-25 03:45 +, Wookey wrote:
> So, unless anyone can see a problem with this approach, I'll finish
> this off. Trying to do it with separate /var/run/consoles and
> /var/run/extra-consoles files was getting very messy.
OK. This took way longer than I hoped as it was not entirely trivi
On 2019-01-23 08:35 +, Ian Campbell wrote:
> On Wed, 2019-01-23 at 03:41 +, Wookey wrote:
> > Any idea how we should choose a D-I primary console when none of them
> > is marked 'preferred'? Or should D-i do away with the concept and try
> > to treat them all equally (which is a slightly m
On Wed, 2019-01-23 at 03:41 +, Wookey wrote:
> You are right. I wasn't taking note of those:
>
> E=enabled
> C=preferred console
> p=used for printk buffer
> a=safe to use when CPU is offline
>
> console=tty0
> tty0 -WU (EC p )4:7
> ttyAMA0 -W- (E p a) 204:
On 2019-01-22 08:23 +, Ian Campbell wrote:
> On Tue, 2019-01-22 at 04:31 +, Wookey wrote:
> > On 2019-01-20 03:02 +, Ben Hutchings wrote:
> > > Reading /proc/consoles is exactly what you should do.
> >
> > Checking this on a booted thunderx machine (with no explicit kernel cmdline
> >
On Tue, 2019-01-22 at 04:31 +, Wookey wrote:
> On 2019-01-20 03:02 +, Ben Hutchings wrote:
> > Reading /proc/consoles is exactly what you should do.
>
> Checking this on a booted thunderx machine (with no explicit kernel cmdline
> options) it lists
> ttyAMA0
>
> If I boot with explicit
On 2019-01-20 03:02 +, Ben Hutchings wrote:
> /proc/consoles shows everything on the global console_drivers list.
> Every time a console is added to the list the kernel logs a message
> with the format "%sconsole [%s%d] enabled\n". So these should match,
> except that (1) it is also possible
On Sat, Jan 19, 2019 at 01:16:43PM +, Ian Campbell wrote:
>On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
>> >So far I have done a proof-of-concept hack and demonstrated that
>> >running two instances does in fact work nicely without anything
>> >obvious breaking. The console selectio
On Sun, Jan 20, 2019 at 03:02:33AM +, Ben Hutchings wrote:
>On Sun, 2019-01-20 at 01:21 +, Wookey wrote:
...
>> My current code leaves all this alone and just records/uses all
>> enabled consoles on the command line, not just the last one, but
>> ideally we'd autodetect and/or hardcode al
On Sun, 2019-01-20 at 01:21 +, Wookey wrote:
> On 2019-01-19 20:11 +, Ben Hutchings wrote:
> > On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
> > [...]
> > > * add lots more console= options to the grub.cfg for arm64 (to cover
> > >all the possibilities), then let d-i startup
On 2019-01-19 20:11 +, Ben Hutchings wrote:
> On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
> [...]
> > * add lots more console= options to the grub.cfg for arm64 (to cover
> >all the possibilities), then let d-i startup work out which devices
> >exist from /proc/cmdlinge an
On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
[...]
> * add lots more console= options to the grub.cfg for arm64 (to cover
>all the possibilities), then let d-i startup work out which devices
>exist from /proc/cmdlinge and spawn d-i on each.
[...]
I think you should look in /pr
On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
> >So far I have done a proof-of-concept hack and demonstrated that
> >running two instances does in fact work nicely without anything
> >obvious breaking. The console selection still needs some work/checking
> >(I've run out of time for that
20 matches
Mail list logo
