Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #68810 > unrolled thread

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

Started byRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
First post2020-12-11 11:20 +0100
Last post2020-12-15 08:50 +0100
Articles 12 — 3 participants

Back to article view | Back to linux.debian.kernel


Contents

  Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2020-12-11 11:20 +0100
    Processed: Re: Bug#977126: linux: No armel kernel can be booted  by grub-efi-arm:armel "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-12-13 18:00 +0100
    Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel Ben Hutchings <ben@decadent.org.uk> - 2020-12-13 18:00 +0100
      Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2020-12-13 21:40 +0100
        Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel Ben Hutchings <ben@decadent.org.uk> - 2020-12-13 21:50 +0100
          Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2020-12-14 02:30 +0100
            Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel Ben Hutchings <ben@decadent.org.uk> - 2020-12-14 03:10 +0100
              Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2020-12-14 03:30 +0100
                Bug#977126: linux-image-rpi does not boot by qemu-system-arm -machine raspi0 Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2020-12-14 10:10 +0100
                  Bug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0 Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2020-12-14 22:30 +0100
                    Bug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0 Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2020-12-15 08:50 +0100
    Processed: Re: panic log attached Re: linux-image-rpi does not  boot by qemu-system-arm -machine raspi0 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-12-15 08:50 +0100

#68810 — Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

FromRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date2020-12-11 11:20 +0100
SubjectBug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel
Message-ID<BkNGN-3td-1@gated-at.bofh.it>
Source: linux
Version: 5.9.11-1
Severity: important
X-Debbugs-Cc: pkg-grub-devel@alioth-lists.debian.net

Dear Maintainer,

grub-efi-arm:armel package remains almost unusable for very long time.
To boot a kernel in UEFI mode, it must be compiled with CONFIG_EFI.
But no Debian armel kernel (specifically linux-image-marvell or
linux-image-rpi) is built with CONFIG_EFI.
This leaves armel grub-efi-arm package almost useless.

For example, trying to boot linux-image-marvell by grub-efi-arm:armel
shows the following message:

Welcome to GRUB!

error: no suitable video mode found.
  Booting `Debian GNU/Linux'

Loading Linux 5.9.0-4-marvell ...
error: plain image kernel not supported - rebuild with CONFIG_(U)EFI_STUB
enabled.
Loading initial ramdisk ...
error: you need to load the kernel first.

On the other hand, grub-efi-arm:armel can boot linux-image-armmp:armhf.

This feature/bug leaves grub-efi-arm:armel almost useless,
so I chose "important" priority.

Best regards, Ryutaroh Matsumoto


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.9.0-4-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[toc] | [next] | [standalone]


#68834 — Processed: Re: Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2020-12-13 18:00 +0100
SubjectProcessed: Re: Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel
Message-ID<BlCSZ-13N-3@gated-at.bofh.it>
In reply to#68810
Processing control commands:

> tag -1 moreinfo
Bug #977126 [src:linux] linux: No armel kernel can be booted by grub-efi-arm:armel
Added tag(s) moreinfo.

-- 
977126: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977126
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#68835

FromBen Hutchings <ben@decadent.org.uk>
Date2020-12-13 18:00 +0100
Message-ID<BlCSZ-13N-5@gated-at.bofh.it>
In reply to#68810

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Fri, 2020-12-11 at 19:09 +0900, Ryutaroh Matsumoto wrote:
> Source: linux
> Version: 5.9.11-1
> Severity: important
> X-Debbugs-Cc: pkg-grub-devel@alioth-lists.debian.net
> 
> Dear Maintainer,
> 
> grub-efi-arm:armel package remains almost unusable for very long time.
> To boot a kernel in UEFI mode, it must be compiled with CONFIG_EFI.
> But no Debian armel kernel (specifically linux-image-marvell or
> linux-image-rpi) is built with CONFIG_EFI.
> This leaves armel grub-efi-arm package almost useless.

I wasn't aware that this package existed until now...

> For example, trying to boot linux-image-marvell by grub-efi-arm:armel
> shows the following message:
[...]

The marvell flavour is constrained by memory and partition limits on
many of the supported machines, so it is unlikely that we would want to
increase its size further by enabling EFI support.

The rpi flavour doesn't have those constraints, though.  What would be
the benefit of booting it in UEFI mode?

Ben.


-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.

[toc] | [prev] | [next] | [standalone]


#68846

FromRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date2020-12-13 21:40 +0100
Message-ID<BlGjU-3fI-13@gated-at.bofh.it>
In reply to#68835
> The rpi flavour doesn't have those constraints, though.  What would be
> the benefit of booting it in UEFI mode?

Thank you for paying your attention!
I considered extending autopkgtest-virt-qemu to armel (and other archs) testbeds at
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100#note_205984

To boot a qemu disk image by qemu-system-*, a booting firmware seems
indispensable, as the autopkgtest maintainer does not like giving -kernel=something
qemu option as
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/97#note_205357

A booting firmware for an armel Debian disk image seems only
the qemu-efi-arm Debian package (is there anything else??).
So I resorted to the UEFI booting.
Currently I proposes to use linux-image-armmp-lpae for armel testbed.

Best regards, Ryutaroh

[toc] | [prev] | [next] | [standalone]


#68848

FromBen Hutchings <ben@decadent.org.uk>
Date2020-12-13 21:50 +0100
Message-ID<BlGtz-3j6-3@gated-at.bofh.it>
In reply to#68846

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2020-12-14 at 05:13 +0900, Ryutaroh Matsumoto wrote:
> > The rpi flavour doesn't have those constraints, though.  What would be
> > the benefit of booting it in UEFI mode?
> 
> Thank you for paying your attention!
> I considered extending autopkgtest-virt-qemu to armel (and other archs) testbeds at
> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100#note_205984
> 
> To boot a qemu disk image by qemu-system-*, a booting firmware seems
> indispensable, as the autopkgtest maintainer does not like giving -kernel=something
> qemu option as
> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/97#note_205357

OK, this seems like a good reason.

We used to provide a 'versatile' flavour on armel, for the ARM
Versatile boards that QEMU has supported for a long time.  I removed
this flavour back in 2016 after finding that it had been broken for a
while and no-one had reported it.  Adding that back might be an option,
if the Raspberry Pi device emulation in QEMU is slow.  What do you
think?

> A booting firmware for an armel Debian disk image seems only
> the qemu-efi-arm Debian package (is there anything else??).

The usual practice is to use u-boot or some other board-specific boot
loader, which can be configured by the flash-kernel package.  I don't
think that works in QEMU.

Ben.

> So I resorted to the UEFI booting.
> Currently I proposes to use linux-image-armmp-lpae for armel testbed.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.

[toc] | [prev] | [next] | [standalone]


#68854

FromRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date2020-12-14 02:30 +0100
Message-ID<BlKQy-63S-9@gated-at.bofh.it>
In reply to#68848
Hi Ben, thanks again for your response.

> We used to provide a 'versatile' flavour on armel, for the ARM
> Versatile boards that QEMU has supported for a long time.  I removed
> this flavour back in 2016 after finding that it had been broken for a
> while and no-one had reported it.  Adding that back might be an option,
> if the Raspberry Pi device emulation in QEMU is slow.  What do you
> think?

If nobody uses linux-image-versatile now, I don't want to request the
kernel team to revive it. It may/might increase the maintainance effort...

The minimum requirements by autopkgtest-virt-qemu are
* VM has at least two serial ports,
* the Linux kernel has a driver for them, and
* the Linux kernel has a driver for a storage attached to the VM.

On the other hand, RPi series has only one serial port by PL011.
So we need to attach another serial port to the VM. For armhf, arm64,
and ppc64el, I was advised to use virtconsole by Simon McVittie,
and it has worked fine as far as I see.

But linux-image-rpi does not have the virtio driver, this option cannot
be used (at least for now). Another option is to attach "pci-serial-2x"
to the qemu VM, but linux-image-rpi does not seem to have a PCI driver...
Yet another option is to attach "qemu-xhci" and "usb-serial" to the VM,
but "usb-serial" behaves much differently from isa/pci-serial and virtconsole
and it cannot be used by the current autopkgtest-virt-qemu as reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038#40

> The usual practice is to use u-boot or some other board-specific boot
> loader, which can be configured by the flash-kernel package.  I don't
> think that works in QEMU.

I have not intensively investigated if we can boot linux-image-marvell
by qemu-system-arm and some u-boot Debian package...
I will see it within several days and report it back here.
First I will see u-boot-qemu Debian package and the qemu "virt" machine
can boot linux-image-marvell as suggested at
https://github.com/ARM-software/u-boot/blob/master/doc/README.qemu-arm

linux-image-marvell seems capable of handling PCI serial ports.
Storage options for QEMU VM seems only "ich9-ahci" and "sdhci-pci"...

Best regards, Ryutaroh

[toc] | [prev] | [next] | [standalone]


#68856

FromBen Hutchings <ben@decadent.org.uk>
Date2020-12-14 03:10 +0100
Message-ID<BlLtg-6y3-11@gated-at.bofh.it>
In reply to#68854

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2020-12-14 at 10:24 +0900, Ryutaroh Matsumoto wrote:
Hi Ben, thanks again for your response.

> We used to provide a 'versatile' flavour on armel, for the ARM
> > Versatile boards that QEMU has supported for a long time.  I removed
> > this flavour back in 2016 after finding that it had been broken for a
> > while and no-one had reported it.  Adding that back might be an option,
> > if the Raspberry Pi device emulation in QEMU is slow.  What do you
> think?

If nobody uses linux-image-versatile now, I don't want to request the
kernel team to revive it. It may/might increase the maintainance
effort...

It will, though probably not very much.

The minimum requirements by autopkgtest-virt-qemu are
* VM has at least two serial ports,
* the Linux kernel has a driver for them, and
* the Linux kernel has a driver for a storage attached to the VM.

On the other hand, RPi series has only one serial port by PL011.
So we need to attach another serial port to the VM. For armhf, arm64,
and ppc64el, I was advised to use virtconsole by Simon McVittie,
and it has worked fine as far as I see.

But linux-image-rpi does not have the virtio driver, this option cannot
be used (at least for now).

Can you try adding it?  You should be able to cross-build the kernel
package quite easily if you use the profiles "cross,pkg.linux.notools".
There are generic instructions at
<https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official>.

[...]
> The usual practice is to use u-boot or some other board-specific boot
> loader, which can be configured by the flash-kernel package.  I don't
> think that works in QEMU.

I have not intensively investigated if we can boot linux-image-marvell
by qemu-system-arm and some u-boot Debian package...
I will see it within several days and report it back here.
First I will see u-boot-qemu Debian package and the qemu "virt" machine
can boot linux-image-marvell as suggested at
https://github.com/ARM-software/u-boot/blob/master/doc/README.qemu-arm

It won't - it has very different hardware.  Even the CPU will be
incompatible (ARMv7 whereas marvell is built for v5).

Ben.

linux-image-marvell seems capable of handling PCI serial ports.
Storage options for QEMU VM seems only "ich9-ahci" and "sdhci-pci"...

Best regards, Ryutaroh

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[toc] | [prev] | [next] | [standalone]


#68857

FromRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date2020-12-14 03:30 +0100
Message-ID<BlLMC-6Ef-3@gated-at.bofh.it>
In reply to#68856
Hi Ben,

> But linux-image-rpi does not have the virtio driver, this option cannot
> be used (at least for now).
> 
> Can you try adding it?  You should be able to cross-build the kernel
> package quite easily if you use the profiles "cross,pkg.linux.notools".
> There are generic instructions at
> <https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official>.

Thanks. I will. But please give me some time as I am in my working hour... 
I didn't have experience with u-boot'ing a Debian kernel, so maybe I need some
time to correctly build a qemu bootable image by u-boot-rpi:armel package...
Ryutaroh

[toc] | [prev] | [next] | [standalone]


#68859 — Bug#977126: linux-image-rpi does not boot by qemu-system-arm -machine raspi0

FromRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date2020-12-14 10:10 +0100
SubjectBug#977126: linux-image-rpi does not boot by qemu-system-arm -machine raspi0
Message-ID<BlS1H-2ez-1@gated-at.bofh.it>
In reply to#68857

[Multipart message — attachments visible in raw view] — view raw

Hi Ben,
I found that "qemu-system-arm -machine raspi0",
u-boot-rpi:armel and linux-image-rpi do not seem bootable.

Specifically, I did the following (qemu-system-arm is from Sid):
qemu-system-arm -machine raspi0,firmware=/usr/lib/u-boot/rpi_0_w/u-boot.bin \
-display gtk -sd disk-image.qcow2

In "disk-image.qcow2", linux-image-rpi and u-boot-menu are installed.
"u-boot-rpi:armel" is installed only on a host.
u-boot-menu is used for only generating /boot/extlinux/extlinux.conf in the guest.
In the guest "u-boot-update" command created the following /boot/extlinux/extlinux.conf:

## The configuration of this file is generated automatically.
## Do not edit this file manually, use: u-boot-update

default l0
menu title U-Boot menu
prompt 0
timeout 5


label l0
	menu label Debian GNU/Linux bullseye/sid 5.9.0-4-rpi
	linux /boot/vmlinuz-5.9.0-4-rpi
	initrd /boot/initrd.img-5.9.0-4-rpi
	fdtdir /usr/lib/linux-image-5.9.0-4-rpi/
	append LABEL=ROOT net.ifnames=0 consoleblank=0 rw

label l0r
	menu label Debian GNU/Linux bullseye/sid 5.9.0-4-rpi (rescue target)
	linux /boot/vmlinuz-5.9.0-4-rpi
	initrd /boot/initrd.img-5.9.0-4-rpi
	fdtdir /usr/lib/linux-image-5.9.0-4-rpi/
	append LABEL=ROOT net.ifnames=0 consoleblank=0 rw single

"disk-image.qcow2" has msdos partition table with a single ext4 partition.
I got the attached kernel panic (screenshot attached).

I put disk-image.qcow2 at
http://153.240.174.134:64193/disk-image.qcow2  (336 MB).

I am unsure if I should file a bug report to some Debian package
regarding on this...

Best regards, Ryutaroh

[toc] | [prev] | [next] | [standalone]


#68873 — Bug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0

FromRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date2020-12-14 22:30 +0100
SubjectBug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0
Message-ID<Bm3zP-I1-1@gated-at.bofh.it>
In reply to#68859

[Multipart message — attachments visible in raw view] — view raw

Hi Ben, I figured out how to collect the kernel panic logs and they are attached.
I tried both "-machine raspi0,firmware=/usr/lib/u-boot/rpi_0_w/u-boot.bin" and
"-machine raspi1ap,firmware=/usr/lib/u-boot/rpi/u-boot.bin".
Both failed in the same way as attached.

If you think this symptom deserves a seperate bug report against
qemu-system-arm or linux-image-api, please tell me to do so.
I will file it.

An updated image (just "earlyprintk console=ttyAMA0" are added) is placed at
http://153.240.174.134:64193/disk-image-console-ttyAMA0-earlyprintk.qcow2

Best regards, Ryutaroh

[toc] | [prev] | [next] | [standalone]


#68877 — Bug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0

FromRyutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date2020-12-15 08:50 +0100
SubjectBug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0
Message-ID<BmdfP-6Aa-1@gated-at.bofh.it>
In reply to#68873
Control: retitle -1 linux-image-rpi does not boot by qemu-system-arm -machine raspi0 or raspi1ap

Booting a Debian armel kernel by grub-efi-arm:armel seems unnecessary
to everyone (?). So I changed the title.
If linux-image-rpi can boot on qemu-system-arm, then I can modify
autopkgtest-virt-qemu to use linux-image-rpi with no change.
Ryutaroh

[toc] | [prev] | [next] | [standalone]


#68878 — Processed: Re: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2020-12-15 08:50 +0100
SubjectProcessed: Re: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0
Message-ID<BmdfR-6Aa-7@gated-at.bofh.it>
In reply to#68810
Processing control commands:

> retitle -1 linux-image-rpi does not boot by qemu-system-arm -machine raspi0 or raspi1ap
Bug #977126 [src:linux] linux: No armel kernel can be booted by grub-efi-arm:armel
Changed Bug title to 'linux-image-rpi does not boot by qemu-system-arm -machine raspi0 or raspi1ap' from 'linux: No armel kernel can be booted by grub-efi-arm:armel'.

-- 
977126: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977126
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web