"You need to load a kernel first" on trying to boot

[wupgop]

Howdy. I'm trying to make an external USB boot drive to set up LUKS encryption as per:

https://davidalger.com/posts/fedora-asahi-remix-on-apple-silicon-with-luks-encryption/
The process has a few snags. First it kept saying "you have to run this script as root and not as sudo." I was actually running as root. I opened a terminal in my user account and did $sudo -i as well as $sudo su root and each time the script kept giving that error. I commented out the check and the install ran fine and appeared to succeed without any error messages.

When I tried to boot from the drive by cancelling the boot process and trying "env set boot_efi_bootmgr" and "run usb_boot", it was saying no usb devices found.

When I tried to boot from the drive by adding an entry in the Grub boot menu, it did show the apparent install to the device, but there doesnt seem to be a kernel. See screenshots.

When I boot from the internal drive I do see this file which is 1.7 GB

/run/media/user/fedora-usb-boot/vmlinuz-6.6.3-408.asahi.fc39.aarch64+16k.hmac

Is that the kernel sought?

There is also a file in that directory, initramfs-6.6.3-408.asahi.fc39.aarch64+16k.img

Could you offer any advice? Thank you. This is a MBP 16" with an M2 pro max chip.

[leifliddy]

I just pushed out a new change to sort out the sudo issue. I didn't account for users using sudo -i .

Your grub menu looks a bit funky
edit /etc/default/grub and ensure this is set to the blank string (and not to console)
GRUB_TERMINAL_OUTPUT=""
then run grub2-mkconfig -o /boot/grub2/grub.cfg to enable the change.

If you want to inspect the contents of the usb drive -- just run ./build.sh chroot
That will chroot you into the usb drive where you can inspect the contents of it.

[root@m1 usb]# ./build.sh chroot
### Chrooting into /root/usb/mnt_usb
[root@m1 /]# ll /boot/
total 41648
-rw-------.  1 root root  7682703 Dec 15 00:00 System.map-6.6.3-408.asahi.fc39.aarch64+16k
-rw-r--r--.  1 root root   301917 Dec 15 00:00 config-6.6.3-408.asahi.fc39.aarch64+16k
lrwxrwxrwx.  1 root root       36 Dec 17 07:19 dtb -> dtb-6.6.3-408.asahi.fc39.aarch64+16k
drwxr-xr-x. 18 root root     4096 Dec 17 07:19 dtb-6.6.3-408.asahi.fc39.aarch64+16k
drwxr-xr-x.  3 root root     4096 Jan  1  1970 efi
drwx------.  4 root root     4096 Dec 17 07:20 grub2
-rw-------.  1 root root 18042674 Dec 17 07:19 initramfs-6.6.3-408.asahi.fc39.aarch64+16k.img
drwxr-xr-x.  3 root root     4096 Dec 17 07:19 loader
lrwxrwxrwx.  1 root root       56 Dec 17 07:19 symvers-6.6.3-408.asahi.fc39.aarch64+16k.xz -> /lib/modules/6.6.3-408.asahi.fc39.aarch64+16k/symvers.xz
-rwxr-xr-x.  1 root root 16597504 Dec 15 00:00 vmlinuz-6.6.3-408.asahi.fc39.aarch64+16k

I ran into this same issue that you're experiencing yesterday and posted about it on this channel.
https://app.element.io/#/room/#asahi:fedoraproject.org

According to marcan, there's some sort of race condition occurring with uboot -- and he doesn't have time to fix it at the moment.

Here are some cmds you can run at the uboot prompt

usb reset
usb info
usb storage

usb storage should display the details of your usb device. If it doesn't then somethings wrong with uboot/m1n1 -- not with the usb drive itself.

Yesterday, I ran into the same issue so I downgraded to m1n1-1.4.8 by running these three cmds

rpm -e --nodeps m1n1
rpm -ivh https://leifliddy.com/asahi-linux/39/aarch64/m1n1-1.4.8-1.fc39.aarch64.rpm
update-m1n1 

And it worked after that. In fact I just upgraded to m1n1-1.4.9 and now uboot is not recognizing the usb drive any longer. So, there's something off with that update in some form or fashion . Try downgrading to m1n1-1.4.8 and see if that works for you.

[leifliddy]

You can also encrypt a drive using this project:
https://github.com/leifliddy/fedora-macos-asahi-qemu

Which creates a Fedora VM in macos and mounts the internal Linux partitions.
Let me know if you'd like more details.....

[wupgop]

Thanks! Downgrading to m1n1-1.4.8 worked.

I'll definitely install the qemu solutions for other times when I need to access the Linux partitions though, thanks for your work on that as well.

[leifliddy]

marcan fixed the issue. The fix will be in m1n1-1.4.11 -- it's always nice when another person can reproduce the exact same issue -- I don't think this bug would have been resolved so fast if you hadn't submitted this bug report, thanks!!