I can reproduce, and I've attached the full console log (!quiet,
+debug). Here's some interesting pieces of the log:

EFI stub: Booting Linux Kernel...
EFI stub: Generating empty DTB
error: couldn't send network packet.
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services...
[    0.000000] Booting Linux on physical CPU 0x0000120000 [0x413fd0c1]
[    0.000000] Linux version 5.15.0-25-generic (buildd@bos02-arm64-058) (gcc 
(Ubuntu 11.2.0-19ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.38) 
#25-Ubuntu SMP Wed Mar 30 15:57:31 UTC 2022 (Ubuntu 5.15.0-25.25-generic 
5.15.30)
[...]
[   15.338070] Trying to unpack rootfs image as initramfs...
[   15.439137] Initramfs unpacking failed: invalid magic at start of compressed 
archive
[   15.461425] Freeing initrd memory: 103244K
[...]

We can see at the end there that the initrd failed to unpack, and that
will definitely lead to a "Unable to mount root fs" panic. But why did
it fail to unpack? One possibility is that the initrd failed to
download. The TFTP server does report that it downloaded:

Apr  8 19:38:59 avoton02 in.tftpd[4218]: RRQ from 10.229.58.47 filename 
/casper/vmlinuz
Apr  8 19:39:02 avoton02 in.tftpd[4220]: RRQ from 10.229.58.47 filename 
/casper/vmlinuz
Apr  8 19:39:06 avoton02 in.tftpd[4221]: RRQ from 10.229.58.47 filename 
/casper/initrd

OK, then maybe it only partially downloaded? Well, the amount of memory
the kernel reports freeing is close to the size of the initrd, so that's
probably not it:

$ du -s /srv/tftp/casper/initrd 
103248  /srv/tftp/casper/initrd

Then perhaps the kernel doesn't support decompressing this compression
format. What is the compression format?

$ file /srv/tftp/casper/initrd 
/srv/tftp/casper/initrd: Zstandard compressed data (v0.8+), Dictionary ID: None

Does the kernel support that? Let's look at the kernel config:

ubuntu@avoton02:/tmp$ dpkg-deb -x 
linux-modules-5.15.0-25-generic_5.15.0-25.25_arm64.deb x
ubuntu@avoton02:/tmp$ grep ZSTD_DECOMPRESS x/boot/config-5.15.0-25-generic 
CONFIG_ZSTD_DECOMPRESS=y

hm.. it does. That's weird. The other mystery is that this all seems to
work when booted from the ISO. Let's take a look at that boot log and
see if we can spot anything different.

** Attachment added: "howzit-pxe-console.log"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1967562/+attachment/5578333/+files/howzit-pxe-console.log

** Changed in: subiquity (Ubuntu)
       Status: Incomplete => Invalid

** Changed in: linux (Ubuntu)
     Assignee: (unassigned) => dann frazier (dannf)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1967562

Title:
  jammy beta (220330) arm iso pxe boot kernel panic on Ampere Mt. Jade

Status in linux package in Ubuntu:
  Incomplete
Status in subiquity package in Ubuntu:
  Invalid

Bug description:
  = Description =
  Platforms: Ampere Mt. Jade Altra (bizzy), Cavium thunderX crb2s (recht)
  Image: Jammy Beta (220330)

  I setup my pxe server to provision jammy beta and got the following
  kernel panic message after grub stage:

  log from console log

  [    1.176614] integrity: Couldn't parse dbx signatures: -74^M
  [    1.371630] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)^M
  [    1.379891] CPU: 42 PID: 1 Comm: swapper/0 Not tainted 5.15.0-23-generic 
#23-Ubuntu^M
  [    1.387535] Hardware name: WIWYNN Mt.Jade Server System 
B81.030Z1.0007/Mt.Jade Motherboard, BIOS 1.6.20210526 (SCP: 1.06.20210526) 
2021/05/26^M
  [    1.400215] Call trace:^M
  [    1.402649]  dump_backtrace+0x0/0x1ec^M
  [    1.406310]  show_stack+0x24/0x30^M
  [    1.409614]  dump_stack_lvl+0x68/0x84^M
  [    1.413271]  dump_stack+0x18/0x34^M
  [    1.416573]  panic+0x18c/0x39c^M
  [    1.419616]  mount_block_root+0x160/0x210^M
  [    1.423622]  mount_root+0x12c/0x14c^M
  [    1.427097]  prepare_namespace+0x140/0x1a0^M
  [    1.431182]  kernel_init_freeable+0x1c8/0x214^M
  [    1.435527]  kernel_init+0x30/0x160^M
  [    1.439006]  ret_from_fork+0x10/0x20^M
  [    1.442573] SMP: stopping secondary CPUs^M
  [    1.447323] Kernel Offset: 0x55263ee90000 from 0xffff800008000000^M
  [    1.453404] PHYS_OFFSET: 0x80000000^M
  [    1.456879] CPU features: 0x000085c1,a3302e42^M
  [    1.461225] Memory Limit: none^M
  [    1.464271] ---[ end Kernel panic - not syncing: VFS: Unable to mount root 
fs on unknown-block(0,0) ]---^M

  = Steps to Reproduce =
  1. Followed this guide to setup the pxe server 
https://discourse.ubuntu.com/t/netbooting-the-live-server-installer-via-uefi-pxe-on-arm-aarch64-arm64-and-x86-64-amd64/19240
 with the jammy beta image (220330) 
http://cdimage.ubuntu.com/ubuntu-server/daily-live/20220330/jammy-live-server-arm64.iso
  1-1. You may use this script to perform the set-up 
https://github.com/tai271828/ubuntu-autoinstall-pxe-server by invoking: `sudo 
./setup-pxe-server.sh --url 
http://cdimage.ubuntu.com/ubuntu-server/daily-live/20220330/jammy-live-server-arm64.iso`
  2. Boot the system via PXE
  3. Select Ubuntu at Grub menu

  = Expected Result =
  The image is loaded to the system locally via PXE, and subiquity is launched

  = Actual Result =
  Console log simply shows nothing for 10 seconds and then the kernel panic 
shows up.

  = Additional Information =
  - If we install via the virtual CD of the server, subiquity could be launched 
and the installation process completes successfully.
  - MAAS could deploy Jammy to the Mt. Jade server as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1967562/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to