btrfs doesn't boot

[solskogen]

Describe the bug

After running rpi-update (without any arguments) I cannot boot my SD card with btrfs anymore

Steps to reproduce the behaviour

Write RPi OS to sd card. Boot it up and do the initial setup. Boot from another device and do a btrfs-convert, replace ext4 with btrfs in fstab and cmdline.txt. Boot (success) Run rpi-update and reboot Stuck in BusyBox.

If I try to mount the filesystem manually I get: Invalid argument. I can still run "btrfs check /dev/mmcblk0p2" without errors.

Device (s)

Raspberry Pi 5

System

Raspberry Pi OS

Logs

No response

Additional context

No response

[solskogen]

Same happens with a external USB SSD

[JamesH65]

I cannot comment on the BTFS issue, but just some advice that you should not be using rpi-update as part of a routine update process as it installs alpha/beta software and there is no guarantee that your OS install will operate correctly as a result. On the whole you should only be using it on recommendation from a Pi engineer in order to fix a specific issue, and it should never be used on production systems. Is there a particular reason you used rpi-update?

[solskogen]

Yeah, I wanted to test the NUMA stuff and CQE mentioned on the forum, but all of a sudden my system was unbootable :-)

[pelwell]

James is right about not using rpi-update as a matter of course, but we are grateful to people who know what they are doing rpi-updating every now and again to help spot issues such as this. There are a couple of btrfs patches that have gone in very recently - we'll take a look.

[JamesH65]

Yeah, I wanted to test the NUMA stuff and CQE mentioned on the forum, but all of a sudden my system was unbootable :-)

Fair enough! Just wanted to make sure you knew what you were doing, and you do. We do get a significant number of people using rpi-update when they shouldn't be (with the consequent support burden), so always worth asking the question.

[solskogen]

I'm fully aware that by using rpi-update I risk this, so I'm not using it on "production" media :-)

[pelwell]

If you've got time, you could narrow down the problem by trying some of the previous rpi-update releases: https://github.com/raspberrypi/rpi-firmware/commits/master

Looking at the commit hashes on the right of each line, the current default release is 15869f6 ("kernel: Bump to 6.6.58"). On the basis that a successful update is significantly quicker than having to unbrick it (if this is not the case, you may want to use a different strategy such as binary chop), I suggest you start with eb9cee1 ("kernel: dts: align PCI BAR allocation on bcm2711 and bcm2712 to start at 2GB") - sudo rpi-update eb9cee1 - and work forwards in time from there until it fails to boot.

[solskogen]

Now I begin to wonder if is has ever worked with btrfs and kernels gotten from "rpi-update" Even a0d314ac077cda7cbacee1850e84a57af9919f94 won't boot, and that's from 23th of August.

[solskogen]

I think I've found the culprit. Since btrfs is compiled as a module, and rpi-update does not use initramfs it will crash. I had to do a very hacky cp /boot/config-6.6.51+rpt-rpi-2712 /boot/config-6.6.58-v8-16k+ and mkinitramfs -o /boot/firmware/initramfs_2712 6.6.58-v8-16k+ to make it boot.

[popcornmix]

Yes, rpi-update doesn't rebuild initramfs, so that needs to be done manually if you rely on modules in initramfs to boot.

[solskogen]

Not only does it not rebuild initramfs. It doesn't build it at all, and it requires some dirty hacks (as explained over) to get it build it.

[popcornmix]

I'm willing to hear suggestions for what rpi-update should do.

But when discussing it with @XECDesign (who has worked on the apt side of initramfs generation), the conclusion was this wasn't something simple to handle, and should be left to user.

We do actually warn in some circumstances: https://github.com/raspberrypi/rpi-update/pull/5 But I don't think this covers auto_initramfs (and possibly other ways of having initramfs enabled).

[solskogen]

Not that I know the inner workings of rpi-update, but if you provide the config file like the dpkg file does the user can at least run the mkinitramfs manually. If it were all up to me, I'd rather created deb packages for the testing kernels (and firmware) and put them in a testing-repo for apt or just as simple deb files the user can download and install. That should work fine even with github actions, so both branches and PRs create deb files. It makes it a lot easier to go back to the default / stable kernel and firmware as well.

[pelwell]

To me, apt and rpi-update are different tools for different jobs. As soon as something can be installed by apt is has a degree of respectability, and an implicit guarantee that is has had some degree of testing. rpi-update is not that.

[solskogen]

To me, apt and rpi-update are different tools for different jobs. As soon as something can be installed by apt is has a degree of respectability, and an implicit guarantee that is has had some degree of testing. rpi-update is not that.

I can't say I share your opinion on that, as long as the deb is in a testing or staging repository. But even so, it doesn't have to be in a apt repo. My point is that the kernel from rpi-update and the official repositories should at least behave the same way with regards to initramfs. But hey, that's just /my/ opinion :-) You're the boss(es) here.

[XECDesign]

Maybe we could add a github workflow to build debs as well?

[pelwell]

Only if they can be made to include the dtbs and overlays as well.

[XECDesign]

They can, yeah. The same way the ones we ship in the apt repo do.

[bincat233]

I think I've found the culprit. Since btrfs is compiled as a module, and rpi-update does not use initramfs it will crash. I had to do a very hacky cp /boot/config-6.6.51+rpt-rpi-2712 /boot/config-6.6.58-v8-16k+ and mkinitramfs -o /boot/firmware/initramfs_2712 6.6.58-v8-16k+ to make it boot.

~For future readers: the config file can be found in the official RPi kernel repository.~

sudo wget https://raw.githubusercontent.com/raspberrypi/linux/rpi-6.12.y/arch/arm64/configs/bcmrpi3_defconfig -O /boot/config-6.12.12-v8+

[pelwell]

@bincat233 That's not correct, for two reasons:

1. A defconfig file is not a complete config file - it contains differences to the default configuration. Running make ... whatever_defconfig results in a .config being created that matches the defconfig.
2. bcmrpi3_defconfig is not used in any of our images. It was contributed by a user before 64-bit builds were common, and we've tried to keep it vaguely up to date, but I don't know if anybody is using it. As of rpi-6.14.y the file has been deleted. Our standard 64-bit kernel that will run on any of the 64-bit capable Pis is built using bcm2711_defconfig.