Re: Debian Installer support for Chromebooks
Hi, On 26/06/2023 20:14, Holger Wansing wrote: > Holger Wansing wrote (Wed, 14 Dec 2022 22:21:42 +0100): >> Am 14. Dezember 2022 16:50:58 MEZ schrieb Alper Nebi Yasak >> : >>> So if I understand it right, things will go mostly in this flow: >>> >>> - depthcharge-tools-installer and partman-cross pass NEW review >>> - Holger uploads version 2 for both, with note for translators (Thanks!) >>> - No translation work is done for the two packages for now >>> - Bookworm releases >>> - The templates' original texts get reviewed for English >>> - The packages are integrated to d-i l10n workflow >>> - Translators start working on the packages for Trixie within d-i >> >> That would be my plan, yes. > > I have now added them to the l10n-machinery. > Translation material should appear for translators then shortly. Thank you. I have already received some translations as bug reports, how should I process them?
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
On 01/06/2023 16:27, Emanuele Rocca wrote: > Hi again, > > On 2023-05-31 05:46, Samuel Thibault wrote: >> The problem is that both are frown-prone. I guess there is a reason why >> on arm the default console is set to the serial port, e.g. for simpler >> debugging or something like that. > > Also worth mentioning: there is no bug on real hardware (eg: RPi 3B+). > > So far I think we've only heard about people getting this issue with > qemu. I've had this problem on my chromebook (rk3399-gru-kevin) since forever. I don't know what's best here, but wanted to provide more context in case it helps. Thank you all for working on it. There's actually two different things that can make Linux set a serial port as the preferred console on arm64 systems: - An SPCR table on devices using ACPI - A /chosen stdout-path property on devices using device-tree I had once tried to change it on the kernel side, going through that email thread [1] might make the how-and-why clearer. (I've silently given up on that series) Furthermore, the same thing happens in the installed system as well, which will ask for your encryption password over a serial console that you have no access to [2] unless you have ended up installing plymouth transitively through a desktop environment. Adding console=tty0 would persist into the installed system and fix that, so I'm used to doing that as a workaround on my own systems. But that disables the serial console on device-tree systems, so doing it by default is a problem for SBCs etc. where people might genuinely be trying to install over serial. (I'd still like it for "Graphical Install" entries [3], but that's orthogonal to this). [1] Prefer working VT console over SPCR and device-tree stdout-path https://lore.kernel.org/lkml/20200513143755.GM17734@linux-b0ei/ [2] initramfs-tools: prefers serial console over framebuffer console https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952452 [3] arm64 graphical installer fixes merge request https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/17
Re: Debian Installer support for Chromebooks
Hi again, On 03/12/2022 23:45, Alper Nebi Yasak wrote: > I've been trying to make Debian easier to install and use on Chromebooks > by adding integration to support their stock firmware/bootloader. > > [...] > > AFAICT the next steps after this are modifying the debian-installer repo > to build custom images bootable this way and > kernel/initramfs/modules-udebs changes for more boards as needed... I have filed a merge request [1] to debian-installer as an initial attempt to provide netboot images for Chromebooks, but it won't work on older chromebooks (like my arm64 one) due to hard-coded size limits. Below the link are some ramblings on how to handle it, comments welcome. [1] Build AMD64/ARM64 netboot images for ChromeOS devices https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/30 The size limit issue is a bit complicated. But in short, the sum of a compressed kernel, initramfs and device-tree files has to fit into 8MiB/16MiB on armhf, ~15MiB on older x86, and 32MiB on older arm64. I can get armhf/arm64 cdrom builds to fit 16MiB/32MiB if I recompress d-i initrd with `xz -9`, but then I guess we would need to generate the final disk images in debian-cd. i386/amd64 builds are too big for that. It might be possible to make these fit by removing unneeded modules, but that's not feasible here because of the way modules are grouped into udebs. My initial plan was to use U-Boot as an intermediate bootloader to overcome the size limit. I have a proof-of-concept working on the one arm64 Chromebook I have, it may work on others depending on upstream support. That result would look something like the concatenable sdcard images. It would need changes to src:u-boot first to enable board builds. Also depthcharge-tools-installer doesn't prepare the installed system like this (yet?), and I don't know how to make this work on x86. Another solution I liked very much is what postmarketOS does. They track essential modules per-board, then build a bare-minimum initramfs which loads the actual initramfs from disk. Very cool, but not really adaptable to Debian at this stage I think. Debian aside, I'm thinking the best way forward is to replace the stock firmware altogether, then just use them as ordinary laptops. Prebuilt TianoCore is available for most x86 ones, and I'll also be trying to do that with U-Boot for arm ones.
Re: Debian Installer support for Chromebooks
On 15/12/2022 00:21, Holger Wansing wrote: > Am 14. Dezember 2022 16:50:58 MEZ schrieb Alper Nebi Yasak > : >> So if I understand it right, things will go mostly in this flow: >> >> - depthcharge-tools-installer and partman-cross pass NEW review >> - Holger uploads version 2 for both, with note for translators (Thanks!) >> - No translation work is done for the two packages for now >> - Bookworm releases >> - The templates' original texts get reviewed for English >> - The packages are integrated to d-i l10n workflow >> - Translators start working on the packages for Trixie within d-i > > That would be my plan, yes. depthcharge-tools-installer is in unstable now, I guess you should be able to upload version 2? (partman-cros is still waiting in NEW.)
Re: Comments regarding depthcharge-tools-installer_1_amd64.changes
Hi, On 24/12/2022 21:57, Thorsten Alteholz wrote: > Hi, > > did anybody approve the new udeb? > > Thorsten Kibi sponsored it [1] (and another udeb-only src:partman-cros). I've been assuming that would count and be enough, is it not? Anything else I need(ed) to do? [1] Debian Installer support for Chromebooks https://lists.debian.org/debian-boot/2022/12/msg00030.html
Re: Compatibility between kernel and modules
(Bcc:'ed to debian-boot@) On 10/12/2022 16:27, Bastian Blank wrote: > Our documented, I think, policy is, that we don't support loading new > modules into an old kernel within the same ABI. This forces a reboot > after kernel installation. > > However in a lot of cases this just worked. You could update the kernel > package and continue loading most modules. > > Now we have BTF support enabled, which trashes this compatibility > mostly, as it requires a way more strict match between kernel image and > modules. One thing to note here is Debian Installer netboot images. Those built with a certain kernel-image-$ABI-di can download *-modules-$ABI-di udebs for that ABI at installation-time, but don't check the actual version. They do display an error if the archive doesn't have modules for that ABI name. I recently encountered this incompatibility with a slightly out-of-date custom netboot image I was testing, and it's not really visible to a user that this has happened. It complained about kernel not supporting RAID and so on, then inexplicably failed after partitioning (looked like it couldn't mount root as ext4). I needed to build a new image. > We need to fix that somehow. Options are as far as I see > - remove BTF from modules, > - allow to load modules even on BTF mismatch, or > - reinforce that a user can't do that. I fear I'm being ignorant here, but 'Bump ABI on every build' sounds to me like it would be technically valid. Although, that might defeat the purpose of tracking ABIs, is that the reason it's not an option? > If we go with the last option we would have also some direct advantages. > We could stop signing modules with the secure boot key, but use a > temporary key. This would for a system with signature checking enabled > effectively trash all possibilities to load modules for a different > kernel build. Anyway, I guess it would be possible to modify d-i to check modules more strictly, by using package version instead of ABI name (in src:anna ?).
Re: Debian Installer support for Chromebooks
On 13/12/2022 22:36, Holger Wansing wrote: > Ah, yes, you are right. > I mixed things up here: > those packages will come into unstable, if they are processed by ftpmaster in > NEW queue. > But they will then not migrate to testing automatically. > For that, a source-only upload is needed. > > Ok, so we have some time here... So if I understand it right, things will go mostly in this flow: - depthcharge-tools-installer and partman-cross pass NEW review - Holger uploads version 2 for both, with note for translators (Thanks!) - No translation work is done for the two packages for now - Bookworm releases - The templates' original texts get reviewed for English - The packages are integrated to d-i l10n workflow - Translators start working on the packages for Trixie within d-i >>> Kibi, could you provide me with the needed upload rights? >> >> I've added both packages to your UID's ACL via the right commands file >> but I'm not sure that's going to be successful since those are unknown >> packages at the moment. We'll see. > > Ok, thanks. FWIW, the packages show up on https://ftp-master.debian.org/dm.txt
Re: Debian Installer support for Chromebooks
On 12/12/2022 03:15, Cyril Brulebois wrote: > I've glanced at depthcharge-tools-installer and while I'm no debconf > expert and I can't assess the postinst with high certainty, the overall > impression was good enough for me to sign and upload; I did change the > Maintainer to debian-boot@ (same as other packages under installer-team/) > and moved you to Uploaders, so you might want to subscribe via tracker > once the package is accepted if you don't follow debian-boot@. Thanks for the upload, and for the tracker subscription tip. I filter debian-boot@ into a folder that I do try to read, but a way that could notify me more prominently could be better. > [...] > > A couple of nitpicks/questions anyway: > > - depthcharge_tools_set_board(): > >The generated comment mentions preseed while I don't think preseed is >involved at all, and I suppose the comment should just mention >debian-installer instead? It's only created if depthcharge-tools-installer/board is set. That template is not asked as a user-visible question, but can be set via a preseed file or in the kernel command line [1]. I do the latter for testing things in a VM, and meant that by 'preseed'. [1] Using boot parameters to preseed questions https://www.debian.org/releases/testing/amd64/apbs02.en.html#preseed-bootparms > - initramfs_tools_conf(): > >Having MODULES overriden in a separate config file might be surprising >to admins. Did you consider adjusting this variable directly in the >main initramfs-tools config file instead? I tried to match what base-installer does [2]. In general, I think it's better to prefer config.d mechanisms over modifying the config files, to avoid conffile conflicts if/when the defaults change later on. [2] base-installer initramfs-tools driver inclusion policy handling https://salsa.debian.org/installer-team/base-installer/-/blob/master/library.sh#L571-592 > - isinstallable: > >It mentions “these values” but only checks for one. Should there other >patterns in that grep? Outdated comment that I missed. There's also cros_efi and cros_legacy, but they are included in some (apparently broken) GRUB/syslinux .cfg files to tell ChromeOS that we're not using its verified boot method. I used to check for them until I figured out it doesn't make sense to.
Re: Debian Installer support for Chromebooks
On 04/12/2022 14:49, Holger Wansing wrote: > Since the packages contain translatable material, my 2 cents here: > I would propose to *not* add the new packages to the l10n machinery > before the release of bookworm, given were are late in the development > cycle. > Means, the new packages would be english-only (at least for the initial > release of bookworm). > I guess that's ok by you? That's definitely OK. I don't know the actual distribution, but my best guess is the vast majority of users would be in English-speaking countries.
Re: Debian Installer support for Chromebooks
On 04/12/2022 00:08, Cyril Brulebois wrote: > Alper Nebi Yasak (2022-12-03): >> I'd like these two udebs to be sponsored. [...] > > I don't think that's going to be an issue timing-wise. To be fair, if they > aren't perfect yet by the time the release happens, we could always fix > stuff in unstable and backport a few things to stable. > > The only thing I'll probably want to make extra sure of is that > introducing those packages doesn't have any nasty side effects for other > machines. I'll try to test UEFI installations with my custom images on actual hardware this week. Saw no problems on a QEMU VM so far. >> [...] > > All of this is very interesting, I'm not sure where it would be best to > keep all relevant documentation. Maybe some dedicated wiki page? I want to eventually write an InstallingDebianOn/Chromebooks page, but have been delaying that because my aim is to make it conceptually as small as "Enable 'Developer Mode', write this image to a USB disk, press CTRL + U to boot from it, follow the installer". Maybe as an appendix to that, or something like DebianInstaller/Chromebooks? I don't know.
Debian Installer support for Chromebooks
Hi, I've been trying to make Debian easier to install and use on Chromebooks by adding integration to support their stock firmware/bootloader. The major part of that work is 'depthcharge-tools' which manages bootloader-specific stuff and kernel/initramfs upgrade hooks, recently sponsored and now in the archive. Another part of this is making d-i install a bootable system, where we need to create a custom partition and then write a special image to it. For these I have two udeb packages: 'partman-cros' [1] that does partman integration and 'depthcharge-tools-installer' [2] which installs and runs depthcharge-tools in-target. I'd like these two udebs to be sponsored. I know I'm quite late with these, but hoping it's not too late for bookworm installer changes. They are somewhat small, `cat **/* | wc -l` gives around 400-600 lines each. I tested them on the two Chromebooks I have (one arm64, one x86). Here are the salsa links for the packages (I'd welcome moving them to the installer-team namespace), they are on mentors.debian.net as well if anyone prefers a dsc + tarball: [1] https://salsa.debian.org/alpernebbi/partman-cros [2] https://salsa.debian.org/alpernebbi/depthcharge-tools-installer They can be tested on non-ChromeOS devices as well (a VM or actual UEFI hardware), by roughly doing: - Build both my packages above and save the two resulting udeb files - Clone https://salsa.debian.org/installer-team/debian-installer - Place the newly built udebs in build/localudebs - Create a build/pkg-lists/local file with contents: partman-cros depthcharge-tools-installer live-installer - - (without indents, and the '-' on the last line is intentional) - Build that as a Debian package (or see its README for build details) - Check the resulting debian-installer-images tar.gz file for images - Extract netboot/gtk/mini.iso - Boot a QEMU VM with it as cdrom, and a disk image to install to - Prepend "cros_secure" to the kernel cmdline in the GRUB menu - Follow the installer prompts (ideally everything should be obvious) - There's a warning if you don't create ChromeOS Kernel partitions - Create one big enough (512MB is great) or get error at the very end - (The GRUB installation step will be skipped, manually run it afterwards if you want to UEFI boot into the resulting system) That should go through the most likely case. There's custom logic to ask to make initramfs smaller if it doesn't fit the board's size limit, but never triggered on x86 due to arch differences. If you do an arm64 build you can test that by adding "depthcharge-tools-installer/board=kevin" to the kernel cmdline. It's harder to test on chromebooks the native way. On the boards I have, the d-i netboot builds either doesn't fit the board's size limit (arm64) or doesn't show any graphics (x86). But using a secondary bootloader and adding the 'cros_secure' via GRUB works well to bootstrap their native boot flow. (I can try to provide instructions if anyone wants, but this email's already rather long.) There are some more details and screenshots of the whole thing at my DebConf22 talk [3], though I've changed some things a bit since then. AFAICT the next steps after this are modifying the debian-installer repo to build custom images bootable this way and kernel/initramfs/modules-udebs changes for more boards as needed... [3] Solving "How Can I Run Debian on My Chromebook?" For Good https://debconf22.debconf.org/talks/87-solving-how-can-i-run-debian-on-my-chromebook-for-good/
Re: Please release and upload rootskel
On 17/01/2021 12:10, John Paul Adrian Glaubitz wrote: > Hello Alper! > > On 1/17/21 10:02 AM, Alper Nebi Yasak wrote: >> Hope this is a good time to ask for this again, this time with a better >> email subject. > > Is someone working to fix this bug in the kernel? After all, we're adding a > hack in debian-installer here to work around an obvious kernel bug. > > So, I think the right approach in the long team is to fix the kernel bug as > other software relies on what's present in /proc/consoles as well. > > Adrian > I had sent this series [1] a while back, but didn't try anything on the kernel side again since then. [1] https://lore.kernel.org/linux-serial/20200430161438.17640-1-alpernebiya...@gmail.com/T/
Please release and upload rootskel
On 22/12/2020 00:18, Alper Nebi Yasak wrote: > On 02/12/2020 04:03, Cyril Brulebois wrote: >> Alper Nebi Yasak (2020-12-01): >>> There's a tiny unreleased change in the rootskel package that fixes d-i >>> not launching on the framebuffer on arm64 QEMU machines [1], can that be >>> also included in the next alpha? >>> >>> Steve (added to Cc) had merged it along with some other changes to >>> debian-installer but I forgot to ask him to make a release... >>> >>> [1] https://salsa.debian.org/installer-team/rootskel/-/merge_requests/3 >> >> I'm a little reluctant to try and squeeze in a package that needs to be >> built on all archs (as opposed to console-setup which is 'all' entirely) >> right before a release; I think it'll be a prime candidate for the >> following Alpha instead. ;) > > Just wanted to send a ping for this. There are already people sending > emails about the issue... Hope this is a good time to ask for this again, this time with a better email subject. > Assuming a new release is uploaded, is it worth adding a notice about > that in the errata which would be removed on the next Alpha?
Re: Recent console-setup uploads, D-I Bullseye Alpha 3
On 02/12/2020 04:03, Cyril Brulebois wrote: > Alper Nebi Yasak (2020-12-01): >> There's a tiny unreleased change in the rootskel package that fixes d-i >> not launching on the framebuffer on arm64 QEMU machines [1], can that be >> also included in the next alpha? >> >> Steve (added to Cc) had merged it along with some other changes to >> debian-installer but I forgot to ask him to make a release... >> >> [1] https://salsa.debian.org/installer-team/rootskel/-/merge_requests/3 > > I'm a little reluctant to try and squeeze in a package that needs to be > built on all archs (as opposed to console-setup which is 'all' entirely) > right before a release; I think it'll be a prime candidate for the > following Alpha instead. ;) Just wanted to send a ping for this. There are already people sending emails about the issue... Assuming a new release is uploaded, is it worth adding a notice about that in the errata which would be removed on the next Alpha?
Bug#977466: rootskel: bterm cannot start when requesting graphical console and serial console at the same time
On 15/12/2020 20:17, Samuel Thibault wrote: > Wang Shanker, le mer. 16 déc. 2020 01:05:58 +0800, a ecrit: >> I carried out a simple test by limiting memory of my qemu machine >> and appending `lowmem=2` to the kernel command line. I can confirm >> that btrem and its font file get deleted. > > Ok, good! > > Thanks for testing, I have uploaded the fix to lowmem. > > Samuel > I've tested with this and the patch for rootskel, and in the text-based installer on the framebuffer the black boxes are replaced with actual characters (arm64 QEMU, with console=ttyAMA0 console=tty0). Can you apply that and do a release for rootskel if that's fine? (also see: a small fix for the changelog [1]) [1] https://salsa.debian.org/installer-team/rootskel/-/merge_requests/4
Re: Switch gtk d-i to libinput (instead of evdev)?
On 12/12/2020 12:45, Shawn Guo wrote:
> On Sat, Dec 12, 2020 at 9:23 AM Cyril Brulebois wrote:
>> Alper Nebi Yasak (2020-12-11):
>>> Cyril: Shawn has filed a MR [1] on salsa to change arm64 cdrom gtk build
>>> from/to using xserver-xorg-input-{evdev->libinput}-udeb, is it OK do to
>>> that for all architectures/builds [2]?
>>
>> Since the udeb is installable, sure. Regarding the gudev thing, I had
>> local patches a while back and that worked back around August 2017
>> (DebConf), with trivial udeb additions in two packages. I'm happy to
>> have the wacom thing skipped instead if X maintainers are happy with
>> that change. :)
>
> Dropping wacom dependency from libinput [1] is already available in
> Sid release, and my MR was tested with it. I will follow Alper's
> comment to update my MR for covering other architectures as well.
Cyril: I'd say Shawn's new MR [1] is OK, have a look and maybe merge?
[1] https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/20
Switch gtk d-i to libinput (instead of evdev)?
(Subject was: "Re: Missing libgudev-1.0-0 udeb package?")
On 11/12/2020 04:22, Shawn Guo wrote:
> On Thu, Dec 10, 2020 at 11:21 PM Timo Aaltonen wrote:
It seems that there is no libgudev-1.0-0 udeb at all, while it becomes
a dependency of xserver-xorg-input-libinput-udeb like below.
xserver-xorg-input-libinput-udeb
libinput10-udeb
libwacom2-udeb
libgudev-1.0-0
Should we build libgudev-1.0-0 udeb to resolve this dependency problem?
>>> I guess one alternative would be to build libinput-udeb without libwacom
>>> support?
>> yeah, libwacom udeb was added just because libinput gained a dependency
>> on it.. I'll drop it from the next upload
>
> Appreciate the quick response! I just rebuilt the installer with
> libinput driver instead of evdev, and the cursor works now! \o/
Switching to libinput also fixes the same touchpad issue on two of my
devices (one arm64, one amd64). Thanks!
Cyril: Shawn has filed a MR [1] on salsa to change arm64 cdrom gtk build
from/to using xserver-xorg-input-{evdev->libinput}-udeb, is it OK do to
that for all architectures/builds [2]?
[1] https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/19
[2] $ git grep evdev
cdrom/grub/gtk/arm64.cfg:xserver-xorg-input-evdev-udeb
cdrom/isolinux/gtk/amd64.cfg:xserver-xorg-input-evdev-udeb
cdrom/isolinux/gtk/i386.cfg:xserver-xorg-input-evdev-udeb
hd-media/gtk/amd64.cfg:xserver-xorg-input-evdev-udeb
hd-media/gtk/i386.cfg:xserver-xorg-input-evdev-udeb
netboot/gtk/amd64.cfg:xserver-xorg-input-evdev-udeb
netboot/gtk/arm64.cfg:xserver-xorg-input-evdev-udeb
netboot/gtk/armel.cfg:xserver-xorg-input-evdev-udeb
netboot/gtk/armhf.cfg:xserver-xorg-input-evdev-udeb
netboot/gtk/i386.cfg:xserver-xorg-input-evdev-udeb
netboot/gtk/powerpc.cfg:xserver-xorg-input-evdev-udeb
netboot/gtk/ppc64.cfg:xserver-xorg-input-evdev-udeb
Bug#976808: Bullseye arm64 d-i Alpha 3: Items cannot be selected by space
On 09/12/2020 02:15, Ryutaroh Matsumoto wrote: > Hi Alper, thank you for paying attention. > >> On that specific question, you use the arrow keys to navigate between > > Neither the space bar nor arrow keys worked for me with Alpha 3... I tried running it under different terminals (tmux, xfce4-terminal, gnome-terminal, xterm, rxvt-unicode) in case that was the problem, but couldn't reproduce this. Other than that I have no idea why it wouldn't work. (Just in case, try running "cat -v" and pressing the arrow keys -- it prints ^[[A upto ^[[D or ^[0A upto ^[0D for me.) > When I tried a weekly build of d-i on November or October, > at least "v" and "^" worked, d-i failed on "tasksel", and > the installation cannot be completed > > But Alpha 3 does not seem to recognize "v" or "^" as subtitutes of arrow keys, > and the situation got worse. Ryutaroh For me, "v" and "^" work on the GRUB menu but not on the d-i menus (both in Alpha 3 and Alpha 2), but I didn't test that on any weekly builds.
Re: bullseye alpha3: graphical installer activated for arm64
On 07/12/2020 23:23, Holger Wansing wrote: > Alper Nebi Yasak wrote: >> I've tried debian-bullseye-DI-alpha3-arm64-netinst.iso on a QEMU VM, the >> gtk installer refused to run with less than 578MiB (falling back to >> newt). I could successfully go through the rest of the gtk installer >> with that much (English, priority=low), though I'm not sure if that's >> enough for everything. > > Yes, we had reports in the past, where it failed in a later installation > step (I think it was partitioning). So I guess, we could go with something > like 640MB as the minimum setting (including some reserve). Probably. (I don't really know much about measuring RAM requirements.) >> Probably not tested enough to call it stable, but functionality-wise >> I think almost everything is in place. It's likely that the graphics >> won't work on some devices since their display modules might not be in >> the fb-modules udeb. > > Hmm, that smells like some potential for problems :-) > Maybe we could call it a "preview", if "experimentell" is a bit harsh? Sounds OK to me. Things should hopefully get better as more people test on their devices and report in. :) >> In the GRUB menu it shows "Install" in the first place and "Graphical >> Install" in the second, so I think the character-based is the default >> for now. > > Ok, that's important info. I will change the paragraph accordingly. > (BTW: this fact could second the "preview"/"experimentell" state from above, > in the eyes of the users... ?) I think that's more related to the use-cases of the devices. AFAICT, most people are used to connecting to arm* devices over serial/ssh, but that's slowly changing as more arm64 laptops (or maybe even desktops?) get less niche.
Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64
On 08/12/2020 13:30, Marcin Juszkiewicz wrote: > W dniu 08.12.2020 o 11:13, Alper Nebi Yasak pisze: >> On 08/12/2020 12:26, Marcin Juszkiewicz wrote: > >>> Both standard and graphical installer contain kernel modules for virtio >>> framebuffer. And both ignore video output forcing user to use serial >>> console. Also while 'standard' installer gives "d-i in screen", >>> graphical one gave just d-i on serial console. >>> >>> /proc/consoles has only ttyAMA0 >> >> This only happens on arm64 ACPI systems with SPCR (QEMU VM is one) now. >> The arm64 graphical installer should be working fine in this release >> with device-tree systems, which do have tty0 in /proc/consoles. > > So maybe there should be message "Debian is for SBC, please use > $OTHER_DISTRO for servers/etc" on d-i website? I didn't mean that. On the contrary, I'm someone trying to fix it. >> You can still work around it with "console=tty0". Even more, the ACPI >> case is fixed on git (by explicitly checking /dev/tty0), but that didn't >> make into this alpha release. > > D-I has issues with AArch64/ACPI systems since probably forever. No idea about those.
Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64
On 08/12/2020 12:26, Marcin Juszkiewicz wrote: > W dniu 08.12.2020 o 09:06, Ryutaroh Matsumoto pisze: >> Hi Debian Arm users, >> >> I tried Bullseye d-i Alpha3 released on December 6 for >> building a qemu disk image usable by qemu-system-aarch64. >> To me, Alpha 3 d-i seems almost unusable for that purpose. >> I filed a report at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 >> >> If you have interest, please have a look. Ryutaroh > > You have started machine in QEMU without any graphics support and got > surprised by lack of graphics? (Also bug #976807 where Ryutaroh did try with graphics support) > But even with "-device virtio-gpu-pci" added Bullseye alpha3 installer > follows the path of Buster :( > > Both standard and graphical installer contain kernel modules for virtio > framebuffer. And both ignore video output forcing user to use serial > console. Also while 'standard' installer gives "d-i in screen", > graphical one gave just d-i on serial console. > > /proc/consoles has only ttyAMA0 This only happens on arm64 ACPI systems with SPCR (QEMU VM is one) now. The arm64 graphical installer should be working fine in this release with device-tree systems, which do have tty0 in /proc/consoles. You can still work around it with "console=tty0". Even more, the ACPI case is fixed on git (by explicitly checking /dev/tty0), but that didn't make into this alpha release.
Bug#976808: Bullseye arm64 d-i Alpha 3: Items cannot be selected by space
Control: severity -1 normal On 08/12/2020 10:59, Ryutaroh Matsumoto wrote: > Dear Maintainer, > As I reported at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976807 > Bullseye arm64 d-i does not provide graphical installation > to QEMU VMs. So I tried text-based installation. The > installer says: > moves; selects; activates buttons > > But is not recognized. When I type an alphabet letter, > the selection moves to an item starting with that letter, > but when there are multiple items starting with the same latter > (e.g. Africa and Asia), I cannot choose the second item (e.g. Asia). > This really prevents me from installation... On that specific question, you use the arrow keys to navigate between options and to choose the option you want. But, there are some questions where you mark which options you want with and continue to the next question with , you can identify those by the brackets before given the options which look like: [*] Selected option [ ] Unselected option For those questions does work on my machine with your command. It might be a small misunderstanding, so lowering severity. But I'd expect to answer the first kind of question as well.
Bug#976807: debian-installer: Bullseye d-i Alpha3: qemu ramfb and virtio-gpu are unusable for graphical installation
On 08/12/2020 10:33, Ryutaroh Matsumoto wrote: > I tried to use Debian Bullseye arm64 d-i Alpha 3 to install Bullseye > to a QEMU disk. I tried -device ramfb and -device virtio-gpu-pic > for graphical installation by d-i Alpha 3. But neither of them were > used by the Alpha 3 installer and text-based installation begun. > The full commands for starting qemu-system-aarch64 is as follows. > Host Debian Linux is ARM64 Bullseye, so I used -enable-kvm. When I run your command, I get a new QEMU window showing the TianoCore logo and then GRUB menu on the ramfb. I can select "Graphical Install" and it goes on to show a blinking cursor on the ramfb, and a text-mode installer on the serial0 (can switch from the "View" menu). Is that the same as what you're seeing? To actually get the installer to launch on the framebuffer, I have to add console=tty0 to the GRUB menu entries manually (press E, add it next to "quiet"). Can you try that?
Re: bullseye alpha3: graphical installer activated for arm64
On 07/12/2020 19:57, john doe wrote: > On 12/7/2020 5:18 PM, Alper Nebi Yasak wrote: >> On 06/12/2020 23:11, Holger Wansing wrote: >>> + >>> + >>> +For this architecture the supports two different user interfaces: a >>> +graphical one and a character-based one. The graphical interface is >>> +used by default unless you select an Install >>> +option in the boot menu. For more information about the >>> +graphical installer, please refer to . >> > > Is it for consistency that 'character' is used instead of 'text'? Yeah, I think it's copy-pasted from the existing text for other arches. > To me, 'text' is more descriptive than 'character'. I'd prefer calling it 'text-based' as well.
Re: bullseye alpha3: graphical installer activated for arm64
On 06/12/2020 23:11, Holger Wansing wrote: > Hi, > > I read in alpha3 release-notes about the activation of the graphical > installer for arm64. > > This needs to be documented in the installation-guide then. > > I have prepared a first patch for this, attached. > > There are two points remaining open: > - needed RAM: what is the minimal required RAM size for the use of > the graphical installer (minimum_memory_gtk in the patch) ? I've tried debian-bullseye-DI-alpha3-arm64-netinst.iso on a QEMU VM, the gtk installer refused to run with less than 578MiB (falling back to newt). I could successfully go through the rest of the gtk installer with that much (English, priority=low), though I'm not sure if that's enough for everything. > - status of the graphical installer: is this considered stable, or > do we want to call this "experimentell" for now? Probably not tested enough to call it stable, but functionality-wise I think almost everything is in place. It's likely that the graphics won't work on some devices since their display modules might not be in the fb-modules udeb. > + > + > +For this architecture the supports two different user interfaces: a > +graphical one and a character-based one. The graphical interface is > +used by default unless you select an Install > +option in the boot menu. For more information about the > +graphical installer, please refer to . In the GRUB menu it shows "Install" in the first place and "Graphical Install" in the second, so I think the character-based is the default for now.
Re: Recent console-setup uploads, D-I Bullseye Alpha 3
Hello, On 01/12/2020 04:36, Cyril Brulebois wrote: > [...] > > And since I'm considering getting an updated console-setup into testing, I > might try and squeeze the latest linux update into that release as well, > provided it's otherwise ready to migrate when it reaches 5/5 days. There's a tiny unreleased change in the rootskel package that fixes d-i not launching on the framebuffer on arm64 QEMU machines [1], can that be also included in the next alpha? Steve (added to Cc) had merged it along with some other changes to debian-installer but I forgot to ask him to make a release... [1] https://salsa.debian.org/installer-team/rootskel/-/merge_requests/3
Re: Cubieboard (Allwinner A10, armhf) install from SD card
On 01/11/2020 03:05, jeanneige666777888 wrote: > Also I just noticed that pressing alt+F2 to F4 on my keyboard actually allows > me to access the virtual terminals but I guess they are not handled by Debian > Installer. > Another weird behavior is that for virtual terminal 1, the HDMI output only > shows a blinking "_" while it works fine for U-Boot and the other terminals. > Virtual terminal 1 (the installer GUI) only shows useful output on the serial > line. > [0.00] Kernel command line: console=ttyS0,115200 It will most likely work if you add "console=tty0" before that in the kernel command line, since VTs work on the display based on what you said. Not entirely sure how to do it on U-Boot side. (The installer should try launching on tty0 regardless of that in the future, the necessary change is already merged to the rootskel package but not released yet.)
Re: sd-card-images
On 29/08/2020 12:58, Frank Mankel wrote: Hello, I have used these images for my RockPro64 in the past. But currently I get a 404, am I looking in the wrong place? With kind regards Frank https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ The daily images are frequently broken like this after a new kernel upload since the debian-installer sources are looking for the old kernel (which no longer exists), it has to be manually updated to build for the new one. It usually gets done in a few days.
Bug#967963: installation failure: rockpro64
On 06/08/2020 03:04, Forest wrote: I used the installer image from over a week ago, because d-i.debian.org has no newer daily images. That happens frequently, as when the kernel is updated in the archive the installer sources have to be manually updated to build for/with the new kernel. The old images are looking for the old kernel which no longer exists, so you get the installer-archive kernel mismatch error. It's updated now, so the current daily builds should work. Booting with my serial adapter set for 150 bps showed nothing but garbage. Using 115200 bps instead showed several bootloader messages clearly, and then nothing but garbage. Editing extlinux.conf to append console=ttyS2,115200n8 to the kernel command line and then setting my serial port to that speed made kernel boot messages visible and allowed me operate the debian installer. Can you check /sys/firmware/devicetree/base/chosen/stdout-path to see if it gives a reasonable serial configuration? AFAICT it should be "serial2:150n8", which should match what you'd normally set your serial adapter to. Otherwise I don't really know what would be causing the garbled output. Maybe try pressing Ctrl-A then 0 (or 1, 2, etc) (screen key bindings to switch windows) to see if it refreshes into something usable?
Re: Graphical installer on arm64 (netboot and cdrom)
Hi, I just wanted to remind you of some patches I sent a while back. Do you (or anyone else) have time to comment on / review / merge them? On 19/05/2020 17:17, Alper Nebi Yasak wrote: So I tested my earlier patch, and did a bit more. I've attached three patches, first two for debian-installer and the third for rootskel. The first patch fixes arm64 netboot and netboot-gtk mini.iso images which now have 'Graphical install' GRUB entries using /gtk/initrd.gz files which don't exist, by making that file identical to /initrd.gz. Also, instead of this, would it be fine to merge netboot-gtk into netboot in general? I think that would solve this issue better. The second patch adds "console=tty0" to GRUB entries marked as "Graphical" in grub-gencfg. Without this, "Graphical automated install" runs on the serial console (since that may be the "preferred" console due to stdout-path or SPCR on arm64). The console=tty0 cmdline argument also ends up in the installed system's /etc/default/grub.cfg, which is correct IMO. The third patch considers tty0 a possible console even if it's not in /proc/consoles (the patch I sent earlier). The text-mode installer already launches on the display in the stdout-path case, but not on the SPCR case. With this it launches on the display in that case as well. I've tested on an arm64 QEMU VM. After all the patches: - "Install" launches on serial and display - "Graphical install" launches on display and serial - "Automated install" launches only on serial - "Graphical automated install" launches only on display On systems where console is set with stdout-path instead, "Graphical install" would launch only on display, but the others would be the same. The three patches are available at [1] if you haven't received them, or I can resend them if you want. [1] https://lists.debian.org/debian-boot/2020/05/msg00178.html There's also a small change I posted for bug #961590 [2] that includes fb-modules in the netboot pkg-list, I'd be glad if that could be merged as well. [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961590#30
Bug#961590: Include drm modules in non-gtk arm64 cdrom initrds
Control: reassign -1 debian-installer
Control: severity -1 normal
Control: retitle -1 Include drm modules in non-gtk arm64 cdrom initrds
Control: tag -1 patch
On 26/05/2020 20:40, Marcin Juszkiewicz wrote:
There are two initrds in that iso, 'install.a64/initrd.gz' doesn't
have drm modules, but the 'install.a64/gtk/initrd.gz' one has them.
Can you try booting the gtk one? If you boot to GRUB, 'Graphical
Install' should be using that.
And that's plain wrong.
I want to run D-I on my monitor. Nevermind is it text mode one or gtk
one. My board does not require serial console to boot as I have
graphical output in U-Boot and can control it using USB keyboard.
I agree they should be included, so I'm changing bug metadata to that
(hopefully correctly).
And I prefer text mode D-I over gtk one.
You can also add DEBIAN_FRONTEND=newt to the kernel cmdline to force
that in the gtk builds.
--
Haven't really tested, but this change should be enough:
diff --git a/build/pkg-lists/cdrom/arm64.cfg
b/build/pkg-lists/cdrom/arm64.cfg
index bb5b3a6ff..672d00a64 100644
--- a/build/pkg-lists/cdrom/arm64.cfg
+++ b/build/pkg-lists/cdrom/arm64.cfg
@@ -1,6 +1,7 @@
fat-modules-${kernel:Version}
cdrom-core-modules-${kernel:Version}
input-modules-${kernel:Version}
+fb-modules-${kernel:Version}
console-setup-udeb
kbd-udeb
usb-modules-${kernel:Version}
Re: [installation-guide arm64] boot installer from USB / preparing installation-media
On 22/05/2020 15:22, Holger Wansing wrote: in the installation-guide, arm64 has the "bootable-usb" option set. That leads to this chapter being included in the manual: https://d-i.debian.org/doc/installation-guide/en.arm64/ch04s03.html Is this true for arm64? When I write netboot mini.iso images or CD images to a USB drive they work fine on a QEMU aarch64 VM with EFI firmware. But I couldn't easily create new partitions (for firmware) on the disk: - Gparted thinks the whole disk is iso9660 so it won't even try - Gnome Disks thinks it's MBR but fails to create a new partition - fdisk worked, but breaks the iso9660 part unless I pass "--wipe never" At least the hd-media/boot.img.gz (mentioned in chapter 4.3.2) is not existing on the mirrors for arm64 ... The hd-media configuration isn't enabled for arm64 yet, I'll probably work on enabling it eventually. It's enabled on armhf, but there it has an hd_media.tar.gz and "concatenateable images" (which may be analogous to that boot.img.gz). That's probably how it'd be on arm64 hd-media as well. See: https://d-i.debian.org/daily-images/armhf/daily/hd-media/SD-card-images/ https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ Other than that, it looks like 4.3.2 and 4.3.3 are already missing most of the instructions (compared to the amd64 version), so I don't think those two make sense in their current form.
Re: Graphical installer on arm64 (netboot and cdrom)
On 20/04/2020 19:36, Alper Nebi Yasak wrote:
On 20/04/2020 18:38, Steve McIntyre wrote:
Does /dev/tty0 show up in /proc/consoles in your setup? We might need
to tweak that yet...
Here is a small but untested patch for rootskel's reopen-console for that.
I don't think this (having to set console=tty0 on arm64) is going to
change on the kernel side, see:
https://lore.kernel.org/linux-serial/20200513143755.GM17734@linux-b0ei/
where Petr Mladek said:
My suggestion is:
+ Fix SPCR setting or device tree of your device when the defaults
are not as expected.
+ Use command line to force your value when the defaults are not
as expected and you could not change them.
So I tested my earlier patch, and did a bit more. I've attached three
patches, first two for debian-installer and the third for rootskel.
The first patch fixes arm64 netboot and netboot-gtk mini.iso images
which now have 'Graphical install' GRUB entries using /gtk/initrd.gz
files which don't exist, by making that file identical to /initrd.gz.
The second patch adds "console=tty0" to GRUB entries marked as
"Graphical" in grub-gencfg. Without this, "Graphical automated install"
runs on the serial console (since that may be the "preferred" console
due to stdout-path or SPCR on arm64). The console=tty0 cmdline argument
also ends up in the installed system's /etc/default/grub.cfg, which is
correct IMO.
The third patch considers tty0 a possible console even if it's not in
/proc/consoles (the patch I sent earlier). The text-mode installer
already launches on the display in the stdout-path case, but not on the
SPCR case. With this it launches on the display in that case as well.
I've tested on an arm64 QEMU VM. After all the patches:
- "Install" launches on serial and display
- "Graphical install" launches on display and serial
- "Automated install" launches only on serial
- "Graphical automated install" launches only on display
On systems where console is set with stdout-path instead, "Graphical
install" would launch only on display, but the others would be the same.
>From 2970cde5a6217a76a0b499987c4e9c40485db891 Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak
Date: Mon, 18 May 2020 22:35:07 +0300
Subject: [PATCH] Include a /gtk/initrd.gz in graphical arm mini.iso builds
Signed-off-by: Alper Nebi Yasak
---
build/config/arm.cfg | 4
1 file changed, 4 insertions(+)
diff --git a/build/config/arm.cfg b/build/config/arm.cfg
index 4e12bae63..fcf8858b2 100644
--- a/build/config/arm.cfg
+++ b/build/config/arm.cfg
@@ -46,6 +46,10 @@ arch_miniiso: arm_grub_efi
ln -f $(TEMP_KERNEL) $(TEMP_CD_TREE)/linux
ln -f $(TEMP_INITRD) $(TEMP_CD_TREE)/initrd.gz
+ if [ "$(GRAPHICAL_INSTALLER)" = y ]; then \
+ mkdir -p $(TEMP_CD_TREE)/gtk; \
+ ln -f $(TEMP_INITRD) $(TEMP_CD_TREE)/gtk/initrd.gz; \
+ fi
mkdir -p $(TEMP_CD_TREE)/.disk
echo "Debian GNU/Linux $(DEBIAN_VERSION) $(ARCH) - netboot mini.iso $(BUILD_DATE)"\
--
2.26.2
>From f776932c463ed2f921255e395a72373e8ef403b5 Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak
Date: Mon, 18 May 2020 22:50:34 +0300
Subject: [PATCH] Explicitly set console=tty0 for graphical GRUB entries
Signed-off-by: Alper Nebi Yasak
---
build/util/grub-gencfg | 1 +
1 file changed, 1 insertion(+)
diff --git a/build/util/grub-gencfg b/build/util/grub-gencfg
index 97fe42432..f4b6adbda 100755
--- a/build/util/grub-gencfg
+++ b/build/util/grub-gencfg
@@ -169,6 +169,7 @@ sub menuentry ($;%)
push @cmdline, "theme=dark" if $xattr{Dark};
push @cmdline, "---";
push @cmdline, "quiet" if $xattr{Quiet};
+push @cmdline, "console=tty0" if $xattr{Graphical};
my $cmdline = join(" ", @cmdline);
--
2.26.2
>From 1713b6544d4950d2861710b48aff16b4b0a119af Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak
Date: Mon, 20 Apr 2020 19:27:18 +0300
Subject: [PATCH] Use /dev/tty0 as a console even if it's not in /proc/consoles
Signed-off-by: Alper Nebi Yasak
---
src/sbin/reopen-console-linux | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 13b15a3..0816be4 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -78,6 +78,13 @@ do
fi
done
+# /dev/tty0 may not show up in /proc/consoles (at least on QEMU aarch64),
+# debian-installer should run on it anyway if it exists.
+if [ -c /dev/tty0 ] && ! { echo "$consoles" | grep -q "^tty0$"; }; then
+ consoles="${consoles:+$consoles$NL}tty0"
+ log " Adding tty0 to possible consoles list"
+fi
+
if [ -z "$consoles" ]; then
# Nothing found? Default to /dev/console.
log "Found no consoles! Defaulting to /dev/console"
--
2.26.2
Re: Bug#960390: x86_64: No serial port output
On 13/05/2020 03:43, Punit Agrawal wrote: Incidentally, this does not work if '-m 1024' is missing. Kernel boot fails to find 'init'. I suspect that the Qemu default RAM configuration is not sufficient to unpack the initrd. Thanks, that's it. I haven't noticed it the first time around because I normally run virtual machines with virt-manager... The default RAM is 128MiB and the messages also say "Initramfs unpacking failed: write error". Based on this, updated version of Alper's instructions now launch the DI without the need to extract the kernel / initrd. $ qemu-system-x86_64 -cdrom *.iso -nographic -vga none -m 1024 Edit the 'Install' option (by removing 'quiet' and 'vga=788') into: /install.amd/vmlinuz initrd=/install.amd/initrd.gz --- console=ttyS0 (BTW, we need console=ttyS0 here because /proc/consoles only has tty0. The exact opposite happens on arm64 VMs: there /proc/consoles only has ttyAMA0 so debian-installer only launches on the serial console and not on the graphics window.)
Re: Bug#960390: x86_64: No serial port output
On 12/05/2020 13:02, Punit Agrawal wrote: The above parameters do not launch the installer from the iso here. I am not quite sure what the right arguments are. I wonder if "root=" to the kernel will do the trick. Will give that a try. When I try: $ qemu-system-x86_64 -cdrom *.iso -nographic -vga none My terminal turns into a GRUB boot menu, where I can edit the 'Install' option (by removing 'quiet' and 'vga=788') into: /install.amd/vmlinuz initrd=/install.amd/initrd.gz --- console=ttyS0 Which gets me booting kernel messages, can you try that? (Booting still fails with a "Failed to execute /init (error -2)" in my case, but that'd be a separate bug if it's not a problem with my setup.)
Re: Graphical installer on arm64 (netboot and cdrom)
On 26/04/2020 05:54, Paul Wise wrote: ISTR that CCing Andrew Morton can help get patches into Linux if the maintainers of the code in question do not reply. I suggest you try that after you fix the issue pointed out by the bot. Thanks! Do you mean CCing at the version with the fix, or at further re-sends in case that gets no replies as well?
Re: Graphical installer on arm64 (netboot and cdrom)
On 21/04/2020 15:42, Wookey wrote: One thought - can we just perhaps use /dev/console 'anyway' and that'll get us the right thing even when tty0 has not been properly enabled when it should have been? (I've forgotten how all this works and would need to go read the runes again, and most of my test platforms are currently not easily accessible...) As I understand it /dev/console is essentially one of the consoles in /proc/consoles (one marked with C), so the current solution of launching on all consoles in /proc/consoles is better (e.g. wouldn't launch on tty0 on my chromebook since ttyS2 ends up being preferred, /dev/console would only be the latter while /proc/consoles has both). I think we can just launch debian-installer on /dev/tty0 regardless of it being in /proc/consoles (in addition to those in /proc/consoles), since the framebuffer and the virtual terminal parts work just fine (sending Ctrl+Alt+F4 switches to the installer log, for example). [1] https://lore.kernel.org/lkml/44156595-0eee-58da-4376-fd25b634d...@gmail.com/T/ Hmm. I have no idea if you are doing this right either, but it all sounds plausible. I guess a reports with the s/#elif/#else fix is in order anyway, and that might prompt a response from someone with console clue. I'll hopefully manage to fix it and resend this week, want me to CC: you?
Re: Graphical installer on arm64 (netboot and cdrom)
On 21/04/2020 14:14, Alper Nebi Yasak wrote: Since you've already pushed to master, I'll try to do a full installation once daily cdroms are available. I've tested with today's (2020-04-27) weekly-built debian-testing-arm64-xfce-CD-1.iso on my chromebook. Overall rushing through the graphical installation went just fine. Just some minor hardware-specific problems, and I had to handle chromeos bootloader stuff manually, but nothing wrong with the graphical parts from what I can tell. Thanks a lot!
Re: Graphical installer on arm64 (netboot and cdrom)
On 20/04/2020 20:22, Steve McIntyre wrote: On Mon, Apr 20, 2020 at 07:36:42PM +0300, Alper Nebi Yasak wrote: On 20/04/2020 18:38, Steve McIntyre wrote: Does /dev/tty0 show up in /proc/consoles in your setup? We might need to tweak that yet... Here is a small but untested patch for rootskel's reopen-console for that. Hmmm. Is this the right answer, though? I've got totally headless arm64 machines that also have a /dev/tty0. Would we want to run d-i there? Maybe, I'm genuinely not sure. It might be harmless, I guess...? Fedora's installer launches a graphical installer just fine on the same virtual machine I'm testing Debian installers on, regardless of tty0 not being in /proc/consoles. I'm not sure if it launches on a dummy tty0 as well, or even if Xorg can run on a dummy tty0 if we try to launch debian-installer there. An alternative that occurred to me later is putting console=tty0 on the "Graphical install" grub entries (in grub-gencfg), but that'd mean debian-installer wouldn't run on serial consoles when launched from those entries (probably OK, not sure). IMO, the right answer is "tty0 not even being in /proc/consoles in this case (where it should've also been the /dev/console) is a kernel bug". I tried to write a patchset [1] a while back, but received no feedback except from kbuild test bot saying it's broken (s/#elif/#else on the last patch). I don't know if I did anything wrong or anything right at all. [1] https://lore.kernel.org/lkml/44156595-0eee-58da-4376-fd25b634d...@gmail.com/T/
Re: Graphical installer on arm64 (netboot and cdrom)
On 20/04/2020 20:01, Steve McIntyre wrote:
On Mon, Apr 20, 2020 at 03:43:57PM +0100, Steve McIntyre wrote:
Try the image at
http://cdimage.debian.org/cdimage/unofficial/arm64-gi/
please?
OK, so this lot seems to work in a VM at least (thanks Marcin!), so
I've pushed this set of patches to master now. I'm not sure about
adding the graphical installer for armhf right now, but I'm open to
being convinced...
Once we have a working d-i daily build I'll also push my changes for
debian-cd to use it on arm64.
The installer's kernel is 5.5.0-2, but the ones in the cd image's
archive is 5.5.0-1, so the installer refuses to continue after mounting
the cdrom saying it can't any find kernel modules to install.
Other than that, boots fine to a graphical installer on the VM (with the
console=tty0), and on my chromebook (tty0's already in /proc/consoles,
but I don't know how to boot grub there yet so I'm directly using the
install.a64/gtk/{kernel,initrd.gz} files).
Since you've already pushed to master, I'll try to do a full
installation once daily cdroms are available.
I don't particularly care for armhf, but some things to consider:
- netboot-gtk build exists on armhf and might be enough
- non-graphical builds can still run on framebuffers in text mode
- devices may not be able to utilize a cdrom image due to bootloaders
- armhf chromebooks exist (veyron) where graphics would be prettier
- one might want to install armhf Debian on an arm64 device
Re: Graphical installer on arm64 (netboot and cdrom)
On 20/04/2020 18:38, Steve McIntyre wrote:
Does /dev/tty0 show up in /proc/consoles in your setup? We might need
to tweak that yet...
Here is a small but untested patch for rootskel's reopen-console for that.
(Thanks for the cd image, it'll probably take me until tomorrow to test
and report back on it)
>From 1713b6544d4950d2861710b48aff16b4b0a119af Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak
Date: Mon, 20 Apr 2020 19:27:18 +0300
Subject: [PATCH] Use /dev/tty0 as a console even if it's not in /proc/consoles
Signed-off-by: Alper Nebi Yasak
---
src/sbin/reopen-console-linux | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 13b15a3..0816be4 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -78,6 +78,13 @@ do
fi
done
+# /dev/tty0 may not show up in /proc/consoles (at least on QEMU aarch64),
+# debian-installer should run on it anyway if it exists.
+if [ -c /dev/tty0 ] && ! { echo "$consoles" | grep -q "^tty0$"; }; then
+ consoles="${consoles:+$consoles$NL}tty0"
+ log " Adding tty0 to possible consoles list"
+fi
+
if [ -z "$consoles" ]; then
# Nothing found? Default to /dev/console.
log "Found no consoles! Defaulting to /dev/console"
--
2.26.1
Re: Graphical installer on arm64 (netboot and cdrom)
On 20/04/2020 16:36, Steve McIntyre wrote:
I'm just going to test again with that change included, then I can
push a netinst image somewhere for you to test...
I'd appreciate it. Here's another patch, this time for the armhf
graphical cdrom. I checked that it boots into a graphical installer when
run in a QEMU arm VM (still with 'direct kernel boot') but no further.
If you can also make an armhf netinst image from this I can test that
too (at least in a VM, not sure the configs for my chromebook were
enabled on the armhf kernel..).
>From b194a1f9d4619eceb42e355d469c7cd8b54992f7 Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak
Date: Mon, 20 Apr 2020 16:50:07 +0300
Subject: [PATCH] Add modules and build files for armhf graphical installer
cdrom
Signed-off-by: Alper Nebi Yasak
---
build/config/armhf/cdrom.cfg | 2 +-
build/config/armhf/cdrom/gtk.cfg | 19 +++
build/pkg-lists/cdrom/grub/gtk/armhf.cfg | 11 +++
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 build/config/armhf/cdrom/gtk.cfg
create mode 100644 build/pkg-lists/cdrom/grub/gtk/armhf.cfg
diff --git a/build/config/armhf/cdrom.cfg b/build/config/armhf/cdrom.cfg
index 2a6fafd77..68cc87078 100644
--- a/build/config/armhf/cdrom.cfg
+++ b/build/config/armhf/cdrom.cfg
@@ -1,4 +1,4 @@
# el-torito is too large at the moment, so is disabled.
-FLAVOUR_SUPPORTED = grub
+FLAVOUR_SUPPORTED = grub gtk
MEDIA_TYPE = CD-ROM
diff --git a/build/config/armhf/cdrom/gtk.cfg b/build/config/armhf/cdrom/gtk.cfg
new file mode 100644
index 0..76024e2f1
--- /dev/null
+++ b/build/config/armhf/cdrom/gtk.cfg
@@ -0,0 +1,19 @@
+TARGET = $(INITRD) $(KERNEL) $(DEBIAN_CD_INFO)
+
+MANIFEST-KERNEL = "kernel for use with EFI to build a CD (graphical)"
+MANIFEST-INITRD = "initrd for use with EFI to build a CD (graphical)"
+MANIFEST-DEBIAN_CD_INFO = "EFI config files for CD (graphical)"
+
+TYPE = cdrom/grub/gtk
+
+EXTRANAME = gtk/
+
+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
diff --git a/build/pkg-lists/cdrom/grub/gtk/armhf.cfg b/build/pkg-lists/cdrom/grub/gtk/armhf.cfg
new file mode 100644
index 0..bda77cdab
--- /dev/null
+++ b/build/pkg-lists/cdrom/grub/gtk/armhf.cfg
@@ -0,0 +1,11 @@
+#include "gtk-linux"
+
+#mouse-modules-${kernel:Version}
+event-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
--
2.26.1
Re: Graphical installer on arm64 (netboot and cdrom)
On 16/04/2020 15:40, Steve McIntyre wrote:
On Tue, Apr 14, 2020 at 05:43:36PM +0100, Steve McIntyre wrote:
ACK.
Building locally to test here...
And I have a build that looks OK by eye. Unfortunately, my local test
machine (Macchiatobin) seems to be dying and I can't test this
effectively now. :-(
Ah, OK. Thanks for spending time on this.
It needs some tiny debian-cd changes and then we'll get
netinst, DVD images etc. also including the graphical installer. Final
thing missing - the grub.cfg that's generated for the CD/DVD/USB boot
doesn't include menu entries for graphical boot.
Adding INITRD_GTK to build/config/arm.cfg as in:
diff --git a/build/config/arm.cfg b/build/config/arm.cfg
index fe8cf80f9..898795658 100644
--- a/build/config/arm.cfg
+++ b/build/config/arm.cfg
@@ -23,6 +23,7 @@ arch_cd_info_dir: arm_grub_efi
grub-gencfg \
KERNEL /%install%/vmlinuz \
INITRD /%install%/initrd.gz \
+ INITRD_GTK /%install%/gtk/initrd.gz \
HEADER boot/$(ARCH)/grub/grub-efi.cfg \
> $(TEMP_CD_INFO_DIR)/grub/grub.cfg; \
cp -a $(GRUB_FONT) $(TEMP_CD_INFO_DIR)/grub/font.pf2; \
seems to be enough for the last part, I'm getting "Graphical install"
and others in both cdrom{,/gtk}/debian-cd_info.tar.gz files' grub.cfg files.
I expect that change will make the "Graphical" entries appear also on
armhf where there isn't a cdrom/gtk build yet, so I'll also have a look
at that.
Hopefully I can learn enough debian-cd to build and test with proper
images this time around :)
Re: Graphical installer on arm64 (netboot and cdrom)
On 06/04/2020 17:48, Steve McIntyre wrote: Alper Nebi Yasak: - added event-modules to arm64 netboot-gtk - commented-out serial-modules from arm64 netboot So why comment out the serial modules here? Do they cause a problem? The "serial-modules" udeb isn't built on arm64 yet and including it here causes an error while building the "stamps/get_udebs-netboot-stamp" target complaining it can't find the udeb (I haven't looked into it any further). Instead, we can enable the udeb on the kernel side, but I didn't want to wait for another kernel release before I sent these for review. (The "mouse-modules" udeb isn't built on arm64 either, it depends on "event-modules" and if enabled can/should replace that here.)
Graphical installer on arm64 (netboot and cdrom)
I posted a while ago about graphical installer on arm64, here's an
update. The first two patches I've attached are Wookey's patches with
two module changes (noted in the patch message). The third one is to
enable graphical cdrom builds, which I tested with the d-i bullseye
alpha2 arm64 xfce CD-1 image on both a QEMU virtual machine (via
virt-manager) and my chromebook (rk3399-gru-kevin).
On the VM: I've set the firmware to UEFI, mounted the iso file as a CD,
and used my patched vmlinuz/initrd files with "Direct kernel boot". The
installation went fine except I needed to pass "console=tty0" in the
command line arguments, but that's not a problem in these patches (an
ACPI SPCR table results in Linux not registering tty0 as a console).
On the chromebook: I've written the iso to a partition (/dev/sda1) and
used my patched (also with chromebook stuff) vmlinuz/initrd/dtb to boot.
There, I had to manually specify '/dev/sda1' as the cdrom device in the
cdrom-detect step. It worked for the base-installer step, but not for
the apt-setup step, but the installation continued anyway with a network
mirror and finished with success. I don't know if that apt-setup problem
is considered a bug, I probably wasn't supposed to use a partition as a
cdrom.
I think these patches will work fine on other hardware as well (but I
don't have anything else to test on). Thanks in advance if anyone can
have a look.
>From 171186b5b88903814ab6b0d4ea94b043d5ba1c73 Mon Sep 17 00:00:00 2001
From: Wookey
Date: Tue, 8 Jan 2019 18:14:22 +
Subject: [PATCH 1/3] Add support for graphical installer to arm64
---
build/config/arm64.cfg | 2 +-
build/config/arm64/netboot-gtk.cfg | 24
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 build/config/arm64/netboot-gtk.cfg
diff --git a/build/config/arm64.cfg b/build/config/arm64.cfg
index 29f1db8b0..8ada8ba29 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 0..0f1d246d1
--- /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
--
2.26.0
>From 1bbfb902cb984d83b2bb1ac40524a526ee13cdcd Mon Sep 17 00:00:00 2001
From: Wookey
Date: Sat, 19 Jan 2019 03:13:40 +
Subject: [PATCH 2/3] Add missing modules (usb, fat, virtio) to arm64 netboot
build and xorg modules to netbook-gtk
Alper Nebi Yasak:
- added event-modules to arm64 netboot-gtk
- commented-out serial-modules from arm64 netboot
Signed-off-by: Alper Nebi Yasak
---
build/pkg-lists/netboot/arm64.cfg | 15 ++-
build/pkg-lists/netboot/gtk/arm64.cfg | 11 +++
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 build/pkg-lists/netboot/gtk/arm64.cfg
diff --git a/build/pkg-lists/netboot/arm64.cfg b/build/pkg-lists/netboot/arm64.cfg
index d5635daa9..01fe2b0a5 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 0..bda77cdab
--- /dev/null
+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
@@ -0,0 +1,11 @@
+#include "gtk-linux"
+
+#mouse-modules-${kernel:Version}
+event-modules-${kernel:Version}
+xserver-xorg-input-evdev-udeb
+xserver-xorg-video-fbdev-udeb
+
+#speakup-modules-${kernel:Version}
+#sound-modules-
Re: Bug#950718: RFS: depthcharge-tools/0.3.1-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
On 03/03/2020 18:51, Cyril Brulebois wrote:
partman-* is of course fine for udebs shipping partman stuff, but
depthcharge-support-installer strikes me as something that could be
named depthcharge-support-udeb, or maybe just depthcharge-udeb?
I mimicked the flash-kernel & flash-kernel-installer naming for the
latter two, and *-installer seems to be the way bootloader-related udeb
packages are usually named (e.g. {grub,lilo,zipl}-installer currently in
the archive). But I will change it if you're not convinced -- I think
depthcharge-support-udeb is OK, but depthcharge-udeb feels weird as this
is definitely not depthcharge itself (see below).
Maybe I can merge depthcharge-support into depthcharge-tools, it's just
the easiest way I had thought of indicating "use this bootloader" like
grub-* packages do (vs. grub-*-bin packages); then we could just have a
depthcharge-tools and depthcharge-tools-installer/depthcharge-tools-udeb
whichever is better.
(Unfortunately I don't have any time to review this more thoroughly to
figure out exactly which part does what etc., but I thought sending
this quick note wouldn't hurt.)
Thanks for the reply. I tried to write up a somewhat short overview of
what my prospective packages do, to hopefully make things easier to
understand:
Depthcharge is a coreboot payload from Google which is shipped as part
of ChromeOS devices' firmware. It boots from images of a special format
written to partitions of a special type.
partman-cros:
- enables partman to create these partitions
- checks and alerts if these partitions are necessary but don't exist
depthcharge-tools provides scripts/commands that automate e.g.:
- building images for a known current machine or an arbitrary config
- writing images to partitions and setting boot priority
- blessing the currently booted partition
depthcharge-support only consists of:
- initramfs & kernel hooks to build and write an up-to-date image
- init.d script & systemd service to bless only successful boots
depthcharge-support-installer is an installer step that:
- installs depthcharge-tools to target
- makes target build and write an image for itself
- reconfigure initramfs if it's too big (machine-specific size limit)
- installs depthcharge-support if all is fine
Re: Bug#950718: RFS: depthcharge-tools/0.3.1-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
I've uploaded a new version of depthcharge-tools to mentors.debian.net.
General changes:
- New upstream release v0.3.1, set version to 0.3.1-1
- Use *.{service,init} symlinks to install systemd/init.d files
- Export build-configuration variables in debian/rules
- Change GPL-2.0+ to GPL-2+ in debian/copyright
Installer changes:
- Temporarily disable our initramfs hook if it already exists
- Fix warning on nonexistent /proc/device-tree/model file
- Add a template to override machine detection
- Clarify initramfs compression template (to match my patch at #950086)
Also, it's now possible to test debian-installer integration in a QEMU
virtual machine with a kernel cmdline like [0], by generating a d-i
image with localudebs including depthcharge-support-installer and
partman-cros, and installing both deb packages from this to the target
before the installer step is run.
[0] console=tty0 priority=low live-installer/enable=false
partman-cros/enable=true
depthcharge-support-installer/machine="Google Kevin"
Re: Bug#950718: RFS: depthcharge-tools/0.3.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
On 07/02/2020 17:31, Andrej Shadura wrote: Same here as with #950717: how about talking to the DI team and team-maintaining it and hosting it under https://salsa.debian.org/installer-team? That would be great. I'm not part of the installer team, but I'm willing to join. (Any formal process to do so?) P.S. I had a look at the package and apart from the fact I call the GPL "GPL-2+" not "GPL-2.0+", I don’t have any nitpicks, but then I don’t know anything about how the d-i integration should work. I don't really have a preference for the zero. Is it OK if I change that only if other changes are also requested?
Re: Bug#950717: RFS: partman-cros/1 [ITP] -- Add partman support for ChromeOS kernel partitions
On 07/02/2020 17:23, Andrej Shadura wrote: How about talking to the DI team and team-maintaining it and hosting it under https://salsa.debian.org/installer-team? I think that's the best way to do it, especially for this package (as other partman-* packages are).
Bug#950718: RFS: depthcharge-tools/0.3.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-boot@lists.debian.org Dear mentors, I am looking for a sponsor for my package "depthcharge-tools": * Package name: depthcharge-tools Version : 0.3.0-1 Upstream Author : Alper Nebi Yasak * URL : https://github.com/alpernebbi/depthcharge-tools * License : GPL-2.0+ * Vcs : https://salsa.debian.org/alpernebbi-guest/depthcharge-tools Section : admin It builds those binary packages: depthcharge-tools - Tools for ChromeOS firmware/bootloader integration depthcharge-support - ChromeOS firmware/bootloader integration depthcharge-support-installer - Make this ChromeOS machine bootable (udeb) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/depthcharge-tools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/depthcharge-tools/depthcharge-tools_0.3.0-1.dsc Changes since the last upload: * Initial release. (Closes: #950687) Regards, Alper Nebi Yasak
Bug#950717: RFS: partman-cros/1 [ITP] -- Add partman support for ChromeOS kernel partitions
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-boot@lists.debian.org Dear mentors, I am looking for a sponsor for my package "partman-cros": * Package name: partman-cros Version : 1 Upstream Author : Alper Nebi Yasak * URL : https://salsa.debian.org/alpernebbi-guest/partman-cros * License : GPL-2.0+ * Vcs : https://salsa.debian.org/alpernebbi-guest/partman-cros Section : debian-installer It builds those binary packages: partman-cros - Add partman support for ChromeOS kernel partitions (udeb) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/partman-cros Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/partman-cros/partman-cros_1.dsc Changes since the last upload: * Initial release. (Closes: #950686) Regards, Alper Nebi Yasak
Bug#950086: base-installer: please support configuring initramfs compression
On 30/01/2020 16:43, Ben Hutchings wrote: Oh, right, then I misunderstood what you were doing. I don't understand how the two templates work together, so it may well be that the first version was OK. I don't really grok debconf, but from what I can tell: 1. at build-time, x may be set differently per-arch 2. either x or y may be preseeded with a value by the user 3. if y is empty, it's set to the value of x at install-time 4. installer asks about y (based on priority) 5. value of y is used to configure initramfs-tools where: x is base-installer/kernel/linux/initramfs-tools/* (string) y is base-installer/initramfs-tools/* (select) If either is set to a wrong value, y is somehow reset to it's first choice. I searched a bit and came across bug #192889 which says it's the frontend that does sanitization, so step 4. The first version is probably good enough, except in contrived situations designed to break it. (You didn't reply to the bts, so I'm not doing either. Just pointing it out in case it was by accident. If you resend to bts, feel free to forward this mail as well.)
Bug#950086: base-installer: please support configuring initramfs compression
On 29/01/2020 21:31, Ben Hutchings wrote: This is definitely a rather niche option, so "wishlist" is appropriate. Thanks! (My reasoning was that it's a new feature.) So it's possible to set any arbitrary string, but if you set it to anything other than "gzip", "xz", or "lzma" then the required compressor might not be installed. (And it's possible to set a string that mkinitramfs doesn't install either.) I think this needs to be a "select" type question, so that only the supported compression types can be selected. Allowing arbitrary strings wasn't the intention. I had mimicked the driver-policy implementation. The template you quoted is only used to set a "select" type question, and I assumed doing that with an invalid value would cause an error. While testing I noticed that it would use the first choice when given invalid values (e.g. with kernel cmdline [0]), so I reordered the compression choices to match initramfs.conf, with "gzip" as the first choice. Anyway, I don't think checking the values would hurt, so I did that for my patch and for the driver-policy question too (as patch 1/2). I'm just running "exit 1" in the invalid cases, I'm not sure that's entirely right. Also I'm now calling apt-install before writing the configuration, and made it fail the installation step with (hopefully the appropriate error) if it can't install the compressor package. Attaching a series of two patch files to replace the previous one. Hope they resolve your concerns. [0] quiet console=tty0 priority=critical \ base-installer/initramfs-tools/compression=git \ base-installer/kernel/linux/initramfs-tools/compression=git >From e6949630a32e4930561e5fa9d9f443ab8ac044bc Mon Sep 17 00:00:00 2001 From: Alper Nebi Yasak Date: Thu, 30 Jan 2020 14:21:30 +0300 Subject: [PATCH 1/2] Verify answers to initramfs-tools driver-policy questions Also set "base-installer/kernel/linux/initramfs-tools/driver-policy" to type "select" with choices "most" and "dep". Signed-off-by: Alper Nebi Yasak --- debian/templates-arch | 3 ++- library.sh| 9 +++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/debian/templates-arch b/debian/templates-arch index 30e8f7a8..fbb18372 100644 --- a/debian/templates-arch +++ b/debian/templates-arch @@ -6,7 +6,8 @@ Description: for internal use only Use an (initramfs) initrd (linux 2.6 and later only) Template: base-installer/kernel/linux/initramfs-tools/driver-policy -Type: string +Type: select +Choices: most, dep Default: most Default[armel]: dep Description: for internal use diff --git a/library.sh b/library.sh index d7f05024..890f7087 100644 --- a/library.sh +++ b/library.sh @@ -583,12 +583,17 @@ EOF fi db_get base-installer/initramfs-tools/driver-policy - if [ "$RET" != most ]; then + IT_MODULES="$RET" + if [ "$IT_MODULES" != most ] && [ "$IT_MODULES" != dep ]; then + exit 1 + fi + + if [ "$IT_MODULES" != most ]; then cat > $IT_CONFDIR/driver-policy <>From f0dad1298cfb8f0e32616243f44ba776b647dc75 Mon Sep 17 00:00:00 2001 From: Alper Nebi Yasak Date: Thu, 30 Jan 2020 14:42:26 +0300 Subject: [PATCH 2/2] Support configuring initramfs compression Some machines/bootloaders do not support initramfs images larger than a certain size. Setting MODULES=dep in initramfs-tools config is usually enough to satisfy these size limits, and base-installer already asks a question for this (driver-policy, with priority medium). This patch implements a similar question for initramfs-tools' COMPRESS setting which can further reduce the initramfs size for these machines. Signed-off-by: Alper Nebi Yasak --- debian/bootstrap-base.templates | 11 +++ debian/templates-arch | 7 +++ library.sh | 34 + 3 files changed, 52 insertions(+) diff --git a/debian/bootstrap-base.templates b/debian/bootstrap-base.templates index 78a6f29a..8529fbf7 100644 --- a/debian/bootstrap-base.templates +++ b/debian/bootstrap-base.templates @@ -88,6 +88,17 @@ _Description: Drivers to include in the initrd: smaller targeted initrd there is a very small chance that not all needed drivers are included. +Template: base-installer/initramfs-tools/compression +Type: select +Choices: gzip, bzip2, lz4, lzma, lzop, xz +# :sl3: +_Description: Compression method for the initramfs image: + Compressing the initramfs is usually a trade-off between initramfs + size, memory use, compression speed, and the time your system takes to + boot (decompression speed). Gzip is reasonably balanced, xz and lzma + makes the initramfs significantly smaller, but lz4 has the highest + decompression speed. + Template: base-installer/kernel/failed-install Type: error # :sl2: diff --git a/debian/templates-arch b
Bug#950086: base-installer: please support configuring initramfs compression
Source: base-installer Version: 1.192 Severity: wishlist Tags: patch Dear Maintainers, Debian-installer can already configure initramfs-tools' MODULES setting to get a smaller initramfs. I've written a patch for configuring its COMPRESS setting as well, please consider applying it. I've tested it using an arm64 virtual machine with a custom built netboot image. I'm doing something like flash-kernel & flash-kernel-installer for chromebooks, which have size limits on kernel + initramfs + etc. If the installer step fails due to initramfs size I'll be asking these two questions to the user with a higher priority, regenerate the initramfs, and retry the step. Such a flow could be implemented for flash-kernel as well, and I think having at least the question template here would be great. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.4.0-3-arm64 (SMP w/6 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled >From 2864137a59bcfbc957a7e8960b65e3e39977106a Mon Sep 17 00:00:00 2001 From: Alper Nebi Yasak Date: Mon, 27 Jan 2020 21:16:10 +0300 Subject: [PATCH] Support configuring initramfs compression Some machines/bootloaders do not support initramfs images larger than a certain size. Setting MODULES=dep in initramfs-tools config is usually enough to satisfy these size limits, and base-installer already asks a question for this (driver-policy, with priority medium). This patch implements a similar question for initramfs-tools' COMPRESS setting which can further reduce the initramfs size for these machines. Signed-off-by: Alper Nebi Yasak --- debian/bootstrap-base.templates | 11 +++ debian/templates-arch | 6 ++ library.sh | 22 ++ 3 files changed, 39 insertions(+) diff --git a/debian/bootstrap-base.templates b/debian/bootstrap-base.templates index 78a6f29a..7a53cad3 100644 --- a/debian/bootstrap-base.templates +++ b/debian/bootstrap-base.templates @@ -88,6 +88,17 @@ _Description: Drivers to include in the initrd: smaller targeted initrd there is a very small chance that not all needed drivers are included. +Template: base-installer/initramfs-tools/compression +Type: select +Choices: lzop, lz4, gzip, bzip2, xz, lzma +# :sl3: +_Description: Compression method for the initramfs image: + Compressing the initramfs is usually a trade-off between initramfs + size, memory use, compression speed, and the time your system takes to + boot (decompression speed). Gzip is reasonably balanced, xz and lzma + makes the initramfs significantly smaller, but lz4 has the highest + decompression speed. + Template: base-installer/kernel/failed-install Type: error # :sl2: diff --git a/debian/templates-arch b/debian/templates-arch index 30e8f7a8..873dc001 100644 --- a/debian/templates-arch +++ b/debian/templates-arch @@ -12,6 +12,12 @@ Default[armel]: dep Description: for internal use Default driver inclusion policy for initramfs-tools +Template: base-installer/kernel/linux/initramfs-tools/compression +Type: string +Default: gzip +Description: for internal use + Default compression method for initramfs-tools + Template: base-installer/kernel/linux/extra-packages Type: string Default: diff --git a/library.sh b/library.sh index d7f05024..d2859566 100644 --- a/library.sh +++ b/library.sh @@ -575,8 +575,15 @@ EOF db_get base-installer/kernel/linux/initramfs-tools/driver-policy db_set base-installer/initramfs-tools/driver-policy "$RET" fi + if db_get base-installer/initramfs-tools/compression && \ + [ -z "$RET" ]; then + # Get default for architecture + db_get base-installer/kernel/linux/initramfs-tools/compression + db_set base-installer/initramfs-tools/compression "$RET" + fi db_settitle debian-installer/bootstrap-base/title db_input medium base-installer/initramfs-tools/driver-policy || true + db_input medium base-installer/initramfs-tools/compression || true if ! db_go; then db_progress stop exit 10 @@ -591,6 +598,21 @@ EOF MODULES=$RET EOF fi + + db_get base-installer/initramfs-tools/compression + if [ "$RET" != gzip ]; then + cat > $IT_CONFDIR/compression <
Re: Graphical installer on arm64
On 06/01/2020 23:48, andreimpope...@gmail.com wrote:
Ok, will look into it at some point. It seems Arch have a working kernel
for it.
Yeah, they have board-specific kernels built from Chrome OS sources.
Those could be a starting point, but other people might have tried first
and have more up-to-date elm-specific kernel patches (linux-oak covers
elm, is at v3.18).
Would testing on PINE A64+ be useful as well? It's supported pretty well
out of the box with 5.4 in Debian.
I'd appreciate it if you could. To be complete, I just tried generating
an installer image and these are what I had to do:
- git clone debian-installer [1]
- cd debian-installer
- dpkg-checkbuilddeps
- cd build
- make build_netboot build_device-tree
The outputs go to a dest/ directory. That netboot image should be
already working, you can try booting it to check that you can correctly
build working images. To build the graphical version, I did:
- git am enable-arm64-netboot-gtk.patch [2]
- git am -C0 add-missing-arm64-netboot-modules.patch [2]
- edit 'pkg-lists/netboot/arm64.cfg'
- comment-out the 'serial-modules-${kernel:Version}' line
- edit 'pkg-lists/netboot/gtk/arm64.cfg'
- add 'event-modules-${kernel:Version}' anywhere
- make build_netboot-gtk build_device-tree
This time the installer outputs to dest/netboot/gtk/.
(I missed serial-modules in my first email since I had removed some more
modules to fit into chromebook size limits, and I assumed I had removed
it for that reason.)
[1] https://salsa.debian.org/installer-team/debian-installer.git
[2] https://lists.debian.org/debian-boot/2019/01/msg00183.html
Re: Graphical installer on arm64
On 05/01/2020 23:30, Andrei POPESCU wrote: I'd be interested to test this on the Acer Chromebook R13 (elm). Where / how do I start? From what I can find on the internet: it doesn't look like mainline Linux works on elm yet and Debian arm64 kernel doesn't even have CONFIG_ARCH_MEDIATEK (and probably more CONFIGs that would be necessary for elm) enabled. You'd need to get the Debian-built kernel to run on your hardware first. So I'm assuming you're running a custom kernel. I guess you could build an installer image with that but it would be an alternative to these changes, i.e. would not test them :) . I don't know how exactly that experiment would go. See d-i [1] for how to build installer images in general. Anyway, your roadmap to getting Debian and Debian installer running would be roughly: - Get mainline Linux working on elm - Enable necessary CONFIGs in the Debian Linux source package - Make sure initramfs-tools includes essential modules for booting elm - Add those modules to udeb packaging lists in Linux source package - (Do a lot of chromebook-specific work that I'm also doing) Thanks for the offer. Unfortunately I can't help with the mainlining part. But if you or anyone else gets past that I could give pointers about the rest. [1] https://salsa.debian.org/installer-team/d-i/
Graphical installer on arm64
I've been working on getting Debian installer to run on my chromebook
(kevin) for a while and I've also tested Wookey's patches [1] for
enabling the graphical parts. The inputs didn't work with just those
udebs as reported then, but adding 'event-modules-${kernel:Version}' as
well to the pkg-list fixed that for me.
I also had to add device-specific modules to appropriate udebs, but my
chromebook's keyboard, touchpad (only the buttons), touchscreen, pen and
a wireless USB mouse works in my tested build.
Can anyone else test this on other arm64 machines? I'm pretty sure it
would work, but I suspect chromebook hardware to be weird so my success
might not be indicative of general success.
AFAIK similar changes are needed for other installer types and I intend
to eventually work on those (though not immediately), unless someone
else does it first (in which case I'd be glad to help if I can). Other
than that, is there anything missing for these patches to be merged?
[1] https://lists.debian.org/debian-boot/2019/01/msg00183.html
(I'm not subscribed to the lists, please CC: me for replies.)
Bug#831003: support gzip'd kernel image
On Thu, 23 May 2019 10:36:15 -0700 Vagrant Cascadian wrote:
Untested and refreshed patch against current git attached.
I wanted to extend this, but I ended up almost completely rewriting it:
https://salsa.debian.org/installer-team/flash-kernel/merge_requests/15/
Instead of only using a compressed kernel as-is, my implementation can
also decompress/recompress into a preferred format, with many more
compression types.
Regardless of my MR,
+compress_type() {
+local file="$1"
+magic="$(od -x -N2 $file | head -1 | cut -d' ' -f2)"
If compress_type is called without an argument, od reads from stdin
which might cause flash-kernel to 'hang' unexpectedly. Quoting "$file"
instead exits in error.
Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD
On Tue, 13 Feb 2018 01:03:43 + Ben Hutchings wrote: Now that I think about it, initramfs-tools does allow other packages to override the configuration for mkinitramfs through shell scripts in /usr/share/initramfs-tools/conf-hooks.d. This seems like a good reason to do that. I've recently implemented doing this: https://salsa.debian.org/installer-team/flash-kernel/merge_requests/16/ (But I didn't add the relevant machine db entries for this device).
Merge requests for flash-kernel
Hi, I have been working on getting flash-kernel to work on some
Chromebooks (they have an unconventional way of booting). To help with
that situation I also did some work that could help flash-kernel in general.
Set root in kernel cmdline when there is no initramfs:
https://salsa.debian.org/installer-team/flash-kernel/merge_requests/14/
Support compressed kernel images:
https://salsa.debian.org/installer-team/flash-kernel/merge_requests/15/
Support overriding initramfs-tools configuration:
https://salsa.debian.org/installer-team/flash-kernel/merge_requests/16/
They are mainly intended to reduce the flashed initramfs/kernel sizes,
and about not breaking installations with a custom kernel where it may
be packaged as a gzip and/or not have an initramfs for some reason.
I also have an older MR about supporting the Chromebook firmware /
bootloader ("depthcharge"). The first few commits of that are actually
independent changes to flash-kernel, not really depthcharge-specific
(e.g. the very first commit evolved to be the first MR above). It would
be nice if you could review them too:
https://salsa.debian.org/installer-team/flash-kernel/merge_requests/6/commits
- Add mkimage function to make U-Boot FIT images
- Extend write_mtd as write_device to support non-mtd devices
- Extend check_mtd_size as check_size to support non-mtd devices
- Move root device detection to functions as get_fstab_device
I'd appreciate reviews from all.
(I'm not subscribed to the ML. Please CC: me for replies.)
