Re: Multiple console support in d-i
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 work out which devices > > >exist from /proc/cmdlinge and spawn d-i on each. > > [...] > > > > I think you should look in /proc/consoles, not /proc/cmdline. The > > format is documented in > > https://www.kernel.org/doc/Documentation/filesystems/proc.txt > > Interesting. > > Currently reopen-consoles does: > if d-i console not already recorded > set console using kernel 'handover' message (in dmesg) if running pre 2.6.38 > kernel > unless it's set to serial on a non-serial tty, in which case unset it > make list of 'enabled consoles' from 1st 260k of dmesg > if one matching device, then set as console > if still not found (only) one, set to last one in kernel command line args > if still not found one, default to /dev/console > record chosen console > fi > start d-i on recorded console. > > I'm not entirely convinced that all this logic is actually needed/optimum, > but I don't know the history of it. You can certainly remove anything that relates to old kernel versions. > How exactly does /proc/consoles fit into that? The docs say it is > "registered system consoles". Does that correspond to the same list of > 'enabled consoles' the above is currently fishing out of dmesg? /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 to unregister consoles, and reopen- consoles doesn't account for that (2) the kernel log might have rolled over so that reopen-console-linux doesn't see the messages. > Does it include any/all listed explicitly on the kernel command line? It's a bit more complicated than that. The kernel has a table of up to 8 "preferred" console devices, which can be specified on the kernel command, or through Device Tree or platform code, or by a hypervisor. The device specified last (which usually means the last console= argument on the command line) is the most preferred. If some preferred devices are specified, then console_drivers will include all the console devices that are preferred *and* have been found to exist, and the most preferred (if it exists) will be first. Otherwise, the kernel seems to enable the first console device found to exist. > 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 all the sensible available > consoles and run on them. > > If 'read /proc/consoles (and check the devices exist)' does this, then > that sounds very sensible. Reading /proc/consoles is exactly what you should do. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Re: Multiple console support in d-i
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 and spawn d-i on each. > [...] > > I think you should look in /proc/consoles, not /proc/cmdline. The > format is documented in > https://www.kernel.org/doc/Documentation/filesystems/proc.txt Interesting. Currently reopen-consoles does: if d-i console not already recorded set console using kernel 'handover' message (in dmesg) if running pre 2.6.38 kernel unless it's set to serial on a non-serial tty, in which case unset it make list of 'enabled consoles' from 1st 260k of dmesg if one matching device, then set as console if still not found (only) one, set to last one in kernel command line args if still not found one, default to /dev/console record chosen console fi start d-i on recorded console. I'm not entirely convinced that all this logic is actually needed/optimum, but I don't know the history of it. How exactly does /proc/consoles fit into that? The docs say it is "registered system consoles". Does that correspond to the same list of 'enabled consoles' the above is currently fishing out of dmesg? Does it include any/all listed explicitly on the kernel command line? 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 all the sensible available consoles and run on them. If 'read /proc/consoles (and check the devices exist)' does this, then that sounds very sensible. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multiple console support in d-i
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 /proc/consoles, not /proc/cmdline. The format is documented in https://www.kernel.org/doc/Documentation/filesystems/proc.txt Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part
Re: Multiple console support in d-i
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 tonight, but it can easily be fished
> >out of the kernel command line args. (or we could get fancier).
>
> Nod. Potentially we might end up of running on multiple
> consoles.
IIRC (and it hasn't changed in the years since I knew this stuff) we
already have this on some of the netconsole install images for
arm{el,hf}, you end up with an installer on serial and one on the ssh
connection. Not an identical situation since I think the second one is
only spawned when you login via ssh, but some sort of precedence I
guess!
Ian.
Re: arm64 graphical installer
[ Adding CC to debian-arm for interest ]
On Sat, Jan 19, 2019 at 03:39:44AM +, Wookey wrote:
>I've done some work on getting the graphical installer going on arm64.
\o/
>It's not quite finished, but Steve suggested I publish where I'm at so
>I can get some help with the right set of module packages, and we can
>start fixing up missing bits.
>
>The first patch (enable-arm64-netboot-gtk.patch) enables the
>support. This allows X to start on the display (if the correct console
>is found/specified - see next mail). This looks lovely, but there is
>no input working, because there are no no x input drivers installed,
>nor modules for USB devices (keyboard and mouse are USB).
>
>The second patch (add-missing-arm64-netboot-modules.patch) endeavours
>to fix that, by putting arm64 on the same basis as amd64 in terms of
>modules loaded. However not all module packages are built for arm64
>so I had to remove some to get a working build.
>
>Missing modules (not built on arm64) are:
>mouse-modules
>speakup-modules
>acpi-modules
>sound-modules
>
>we should fix that too.
>
>I was not able to demonstrate that the resulting build works fully,
>because when it tries to boot the kernel I get "Error: Invalid Magic
>number..., you need to load the kernel first". No idea why that's
>changed due to adding more module packages? Clues welcome.
>
>This all sounds more broken than it is: the difficult bit of the
>graphics works fine, we just need to make sure the right modules for X
>input are available too.
Nod. I'm thinking that arm64 is likely to look very similar to amd64
in terms of the desired module sets, module obviously-missing things
like pcmcia. :-)
Also: you've added these to a netboot gtk image. We'll want to add the
equivalent graphically-minded changes for the cdrom target too so we
can make working physical media.
>From b8d5ea7d37670c6c5f9cc251e1cfc5f007388eb6 Mon Sep 17 00:00:00 2001
>From: Wookey
>Date: Tue, 8 Jan 2019 18:14:22 +
>Subject: Add support for graphical installer to arm64
>
>
>diff --git a/build/config/arm64.cfg b/build/config/arm64.cfg
>index d9e782d..f320324 100644
>--- a/build/config/arm64.cfg
>+++ b/build/config/arm64.cfg
>@@ -1,4 +1,4 @@
>-MEDIUM_SUPPORTED = cdrom netboot device-tree u-boot
>+MEDIUM_SUPPORTED = cdrom netboot netboot-gtk device-tree u-boot
>
> KERNELMAJOR = 2.6
> # The version of the kernel to use.
>diff --git a/build/config/arm64/netboot-gtk.cfg
>b/build/config/arm64/netboot-gtk.cfg
>new file mode 100644
>index 000..0f1d246
>--- /dev/null
>+++ b/build/config/arm64/netboot-gtk.cfg
>@@ -0,0 +1,24 @@
>+MEDIA_TYPE = netboot image
>+
>+NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
>+
>+TYPE = netboot/gtk
>+
>+TARGET = $(NETBOOT_DIR) $(NETBOOT_TAR) $(MINIISO)
>+EXTRANAME = netboot/gtk/
>+
>+BOOT_SCREEN_DIR = $(NETBOOT_PATH)/boot-screens/
>+
>+MANIFEST-NETBOOT_DIR = "PXE boot directory for tftp server (graphical
>installer)"
>+MANIFEST-NETBOOT_TAR = "tarball of PXE boot directory (graphical installer)"
>+MANIFEST-MINIISO = "not so tiny CD image that boots the graphical netboot
>installer"
>+
>+IS_PURE_GTK = 1
>+
>+KEEP_GI_LANGS = 1
>+
>+VIDEO_MODE=$(VIDEO_MODE_GTK)
>+
>+# All images that include cdebconf should include symbols needed by these
>+# plugins.
>+EXTRAUDEBS += cdebconf-gtk-entropy
>From b0bc63a3baeb1e46c469d75ff7d68929be267949 Mon Sep 17 00:00:00 2001
>From: Wookey
>Date: Sat, 19 Jan 2019 03:13:40 +
>Subject: Add missing modules (usb, fat, virtio) to arm64 netboot build and
> xorg modules to netbook-gtk
>
>
>diff --git a/build/pkg-lists/netboot/arm64.cfg
>b/build/pkg-lists/netboot/arm64.cfg
>index e07dff0..18ca630 100644
>--- a/build/pkg-lists/netboot/arm64.cfg
>+++ b/build/pkg-lists/netboot/arm64.cfg
>@@ -11,9 +11,22 @@ nic-modules-${kernel:Version}
> nic-usb-modules-${kernel:Version}
> nic-wireless-modules-${kernel:Version}
> virtio-modules-${kernel:Version}
>+usb-modules-${kernel:Version}
>
> fb-modules-${kernel:Version} ?
> input-modules-${kernel:Version} ?
>
>-#for all targets
>+# In case they need to load a driver image.
>+mountmedia
>+media-retriever
>+fat-modules-${kernel:Version}
>+usb-storage-modules-${kernel:Version}
>+mmc-modules-${kernel:Version} ?
>+
>+# brltty
>+brltty-udeb
>+serial-modules-${kernel:Version} ?
>+usb-serial-modules-${kernel:Version} ?
>+uinput-modules-${kernel:Version} ?
>
>+#for all targets
>diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg
>b/build/pkg-lists/netboot/gtk/arm64.cfg
>new file mode 100644
>index 000..2d8530a
>--- /dev/null
>+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
>@@ -0,0 +1,10 @@
>+#include "gtk-linux"
>+
>+#mouse-modules-${kernel:Version}
>+xserver-xorg-input-evdev-udeb
>+xserver-xorg-video-fbdev-udeb
>+
>+#speakup-modules-${kernel:Version}
>+#sound-modules-${kernel:Version}
>+#console-setup-linux-fonts-udeb
>+#espeakup-udeb
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
