Fedora 44 on the Raspberry Pi 5 | Hacker News Reader

Fedora 44 on the Raspberry Pi 5

nullr0ute.com

123 pointsjandeboevrie40 comments

I replaced my custom nightmare of nixos on rpi5 (too much disk space used, too much IO used for raspberry) to a raspbian+arm+homebrew and i could not be happier

Sadly, I came to the same conclusion. This is also why I no longer buy raspberry pis.

Oh no, i was going to setup the same, would you mind sharing more details? I just need a text-only linux for basic stuff. Do you share your nixos config anywhere?

Good reminder that the Raspberry Pis only have good software support if you stick to whatever the foundation is releasing. Because that same foundation has stayed obsessed with their weird custom ways of doing things, instead of furthering efforts like UEFI on ARM. Some of it is insultingly stupid - like for revD of the 5, you better now update the magic boot partition of your RPi with the device tree overlay for revD, because it will use the old device tree, but also expect the overlay to be there so it can actually work. To say the least, that is never what overlays were supposed to be for.

Could these choices have anything to with the alleged focus on Compute Module and less focus on the "normal" Raspberry? Does anyone know?

not really, it has been like that since day1. it has more to do with the weird architecture of the bcm chips they use.

When your SoC is a GPU with CPU cores tacked on, it's a bit weird to boot things up.

> custom ways of doing things, instead of furthering efforts like UEFI on ARM.

I thought uBoot was more or less the standard way of booting embedded Linux? Is it really worth bringing the entire UEFI environment, which is basically a mini OS, to such devices? Embedded devices are often designed to handle power loss or even be unplugged by users, so the boot up process is generally as lean as possible.

SecureBoot might be more useful than UEFI on SBC like Pi.

The grub EFI shim is signed, but does or doesn't verify kernel image and initrd and module (and IDK optionally drive and CPU and RAM hw) signatures?

mokutil does module signature key enrollment. Kernel modules must be signed with a key enrolled in the BIOS otherwise they won't be loaded.

To implement SecureBoot without UEFI would be to develop an alternate bootloader verification system.

But what does grub or uboot or p-boot do after the signed grub shim is verified?

mokutil and these commands don't work without UEFI:

  mokutil --sb-state
  mokutil --help
  mokutil --import key.der
  mokutil --list-new
  reboot

  efibootmgr
  efivar

  fwupd
  fwupdtool
  fwupdmgr get-updates && \
  fwupdmgr update

  tree /sys/firmware/efi

  systemctl reboot --firmware-setup

Note that UEFI doesn't mean supporting most of those.

UEFI without runtime UEFI variable writes is a thing, and that configuration is incompatible with mokutil.

FWIU,

There is no SecureBoot without UEFI.

UEFI without SecureBoot does have advantages over legacy BIOS with DOS MBR.

> UEFI without runtime UEFI variable writes is a thing

Which vendors already support this?

Do any BIOS - e.g. coreboot - support disabling online writes to EFI? (with e.g. efibootmgr or efivar or /sys/firmware/efi)

One of the initial use cases for SecureBoot is preventing MBR malware.

What there be security value to addding checksums or signatures as args to each boot entry in grub.cfg for each kernel image and initial ramdrive?

Unless /boot is encrypted, it's possible for malware to overwrite grub.cfg to just omit signatures for example.

> Which vendors already support this?

One implementation I've seen in the wild is: https://docs.nvidia.com/jetson/archives/r36.4/DeveloperGuide...

Secure Boot is still supported in that configuration, but with PK/db/dbx being part of the firmware configuration and updating them requiring a UEFI capsule update.

Looks like UKI include the initrd in what EFI checks the signature of.

Add signature checking for grub.cfg (instead of just the EFI shim) but that requires enrolling a local key

Add initrd signatures to grub.cfg

U-Boot nowadays speaks UEFI :) (and so does LK)

New Android devices all use a UEFI bootloader: https://source.android.com/docs/core/architecture/bootloader...

This is exactly why I’ve to replaced my home server by a low-power x86 NUC instead. No custom build needed to run NixOS and idle power consumption turns out to be slightly lower than the Raspberry Pi 5.

Allow me to ask you what’s the NUC computer you are using?

I am not the OP, but I got an $150 (at a time) fanless quad core Celeron box at Aliexpress about 5 years ago, and it just runs with zero problems with openmediavault and dockers. Attached is external HDD over USB 3, it’s still fast enough (and the HDD is the bottleneck, not the USB interface).

I wonder if I can run this on a 2 year old celeron laptop

You can run this on a 10 year old celeron laptop.

Few months ago it was possible to get Intel N100 (i5-6400 performance at much lower power) based mini PC with 8GB RAM and 256GB SSD for 100-120 USD on sale. Unfortunately, 'rampocalypse' happened.

I’m using an ASUS NUC 14 Essential Kit N355. It’s a bit more expensive than the Pi 5, but also more powerful (8 cores and decent GPU). There is also a more affordable N150 model. And even lower budget are the N150 mini PCs from Chinese manufacturers, but they often mess up things like cooling in a hardware revision (compared to the favorable review that you’d read).

And forgot to mention this before: Intel CPUs with built-in GPUs have very performant and energy efficient hardware video codecs, whereas the Raspberry Pi 5 is limited and lacks software support.

And what is the idle power draw that you're seeing on the NUC? Out of the box or did you have to mess around with BIOS and powertop?

I get 3-5W, mostly 4W on my N100 nuc. WiFi disabled through bios. And I ran powertop and made the suggested changes. 1 stick of 16gib lpDDR5, 1 nvme ssd, 1 4TB SATA ssd. Under full cpu load usage goes up to 8-12W. When also the gpu is busy with encoding the consumption grows to 20-24W. This is with turbo clock enabled. With it disabled power draw stays around 4W, but it is annoyingly slow I enabled turbo again and just content with the odd power peak.

I'm seeing 4-4.5 Watt idle. I've disabled WiFi in the BIOS (using wired Ethernet) and ran `powertop --auto-tune`, but not much else.

Idle consumption is truly horrid on the Pi 5, even with all the hacks and turning absolutely everything off and hobbling the SoC to 500 Mhz it's imposible to get it under 2W. I'm convinced that the Pi Foundation doesn't think battery powered applications are like, a thing that physically exists.

The first rule of bringup is thermal support.

and sleep

Just another Raspberry Pi HAT ;)

great

Reply on news.ycombinator.com