Skip to content

initramfs selection broken when kernel=kernel8.img #1965

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
gitbls opened this issue Apr 20, 2025 · 6 comments
Open

initramfs selection broken when kernel=kernel8.img #1965

gitbls opened this issue Apr 20, 2025 · 6 comments

Comments

@gitbls
Copy link

gitbls commented Apr 20, 2025

Describe the bug

Something is broken in initramfs loading with kernel=kernel8.img on a Pi5, such that the wrong initramfs is loaded.

Steps to reproduce the behaviour

  • Boot a Pi5 with the normal kernel. Add break=premount to /boot/firmware/cmdline.txt
  • Reboot and the system will stop in initramfs
  • Observe that the output from lsmod displays a few modules that have already been loaded
  • exit initramfs and the system will continue booting
  • Edit /boot/firmware/config.txt
    • Add kernel=kernel8.img
  • Shutdown and reboot into initramfs
  • Observe that the output from lsmod displays only the listing header and NO modules
  • exit initramfs and the system will continue booting
  • Edit /boot/firmware/config.txt
    • Comment out auto_initramfs=1
    • Add initramfs initramfs8 followkernel
  • Shutdown and reboot init initramfs
  • Observe that the output from lsmod works again, showing loaded modules

While this is not a problem in the normal use case, trying to use cryptsetup in initramfs fails due to the incorrect initramfs being loaded.

See https://gitlab.com/cryptsetup/cryptsetup/-/issues/940 for additional details and comments from the cryptsetup developer, Milan Broz.

Device (s)

Raspberry Pi 5

System

https://pastebin.com/UEh3iz2h

Logs

No response

Additional context

No response

@pelwell pelwell transferred this issue from raspberrypi/linux Apr 20, 2025
@pelwell
Copy link
Contributor

pelwell commented Apr 21, 2025

Thanks for reporting this - it's clearly a bug, and an easy one to fix. https://drive.google.com/file/d/1OxmVXmUHBH5woHupzSoWrubbax0SXfdg/view?usp=sharing contains an EEPROM image with a patch that should fix the problem. Once you've extracted the .bin file from the zip, install it with:

$ sudo rpi-eeprom-update -f pieeprom_is1965.bin

@gitbls
Copy link
Author

gitbls commented Apr 21, 2025

Tested and confirmed fix.

Will it be in the next eeprom update?

Thx!

@pelwell
Copy link
Contributor

pelwell commented Apr 21, 2025

The change hasn't been approved and merged yet, but I think it's unlikely we'll make a release before it gets merged, so yes.

@gitbls
Copy link
Author

gitbls commented Apr 21, 2025

Perfect. Thanks again!

@mbroz
Copy link

mbroz commented Apr 21, 2025

Thanks! Maybe you can also update auto_initramfs documentation.

While debugging this issue, the description was confusing. It should probably say that it selects initramfs based on the autodetected kernel name. But how does it behave when an explicit kernel is selected (but no initramfs)?

@pelwell
Copy link
Contributor

pelwell commented Apr 23, 2025

There's another auto_initramfs implementation that works for custom kernel names. The only requirements are that the kernel image name starts with kernel, the initramfs with initramfs, and that the rest matches (except that initramfs doesn't have .img on the end). Put another way, the names are of the form kernel<variant>.img and initramfs<variant>, where <variant> can be any reasonable string (don't go looking for exceptions).

Update: The .img suffix is optional - anything after the last . in the kernel name is removed (so don't go using . in the middle of a variant name without including a suffix...)

This scheme obviously works with the names currently used with RPiOS, but also allows for other variations.

The new image is available here: https://drive.google.com/file/d/1RL4HNb-5AyyIOc_JyNqqAumqc2SZxJwE/view?usp=drive_link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants