On the Librem 5, what’s the way to modify or append to the kernel boot parameters (/proc/cmdline)?
I found no info about this.
1 Like
Edit /etc/default/flash-kernel and issue sudo flash-kernel afterwards. Be ready to boot your device over USB with uuu in case something goes wrong.
1 Like
Ok, thank you for the pointer, so I’d need to know what flash-kernel does, in order to be able to recover if something goes wrong.
I found https://source.puri.sm/Librem5/flash-kernel but I’m sorry the readme only added to the confusion. It is missing in its overview (some words of) what kind of actions it performs and for what reason.
It only says it flashes the kernel and init ramdisk to some untold place, but later also talks about some quite extensive amounts of uboot script magic that it supports. For example, .deb package hooks and /etc/flash-kernel override.d directories.
I first assumed it would flash the files from /boot into yet another location (where?), but this forum thread suggested some leftovers in /boot there were actually created by flash-kernel: Old kernel files in /boot
Be ready to boot your device over USB with uuu in case something goes wrong.
I think booting the jumpdrive system in order to telnet into that is easy enough, but would that rescue system actually allow to run flash-kernel to fix things? Because the “flashing” part of this tool makes me think it’s not enough to simply rename boot.scr (directly on the /boot partition) to get a default rescue boot, or restore a backup copy of it, or is it?
1 Like
Well, um, here’s what I do: Use Jumpdrive to use dd to image the drive.
There’s not much that can’t be fixed by then using dd to restore the image in the scenario that something is broken.
It’s possible that you can limit dd to the boot partition, which will make image and restore faster - but not as all-encompassing if something beyond that is broken - and this is not something that I have tested.
1 Like
Good point, I kind of didn’t think of the “full backup” fallback for this.
However, this would also require, or better said, just assume that ‘flash-kernel’ does actually not flash anything to locations outside of the /boot partition. (And recovery could fail otherwise.)
It seems there is actually a long-standing “only awaiting the merge” mostly done issue to use hardware boot1/boot2 partitions for a more permanent, generally more interoperable, and redundancy providing install of the uboot bootloader. Seems like all tasks are done, and just a couple are still waiting on merge requests.
Thinking about this, I don’t see how the particular feature of moving uboot+uboot-environment into the hardware boot partitions would create a conflict with boot.scr and boot.scr.bak updates done by flash-kernel in /boot.
More to the contrary, the hardware boot1/boot2 partitions would actually provide a much better and safer way to adjust the uboot environment (which includes e.g. the kernel boot parameters as ‘bootargs’). The saveenv from uboot, and thus the fw_saveenv command (from u-boot-tools package) would just always write to the “other” (currenty not booted) hardware boot partition and activate it for the next boot, always leaving the currently working configuration as fallback option.
However, @angus.ainslie I don’t completely understand your latest, dismissing comment there: “Using the boot partitions to store u-boot really doesn’t gain us anything” with the call to first placing and mixing in more OS related stuff (flash-kernel) into the hardware boot partitions.
Even if the CPU can only load uboot itself from just one of the hardware partitions (a limitation of the pevious boot code), I think a redundant uboot environment with a fall back option should still work.
And wouldn’t a boot status flag for the partitions actually gain us an automatic fallback (recovery from uboot configuration errors) to the last working state on the next retry. (Practical partition flagging examples described in the postmarketOS wiki.)
This seems to me a considerable gain without first needing any further resizing and additions to the hardware partitions, flash-kernel, and u-boot as postulated there? (And actually, with flash-kernel not-flashing to other places, the setup would retain much better OS disk image fallback reliability, as found above. Much better separation of bootloader- and OS-managed concerns.)
Maybe it would make sense to update that issue, removing the dev-kit label, and moving it to a still current project?
Yep. That’s why I myself dd the entire disk, even though it takes longer.
As far as knowing what flash-kernel actually does, I think you would have to look at the sources.
You never said (I think) what kernel parameters you want to mess with. Unless those kernel parameters are going to provide something really good for Librem 5 users, I am unconvinced that there should be much priority to any of this at the current time.
The Librem 5 already provides a very robust fallback boot option i.e. uuu, as was suggested indirectly by an earlier post. That gives you a “recovery shell” that can fix anything that can be readily fixed by executing shell commands. However obviously sometimes the only reliable recovery is to restore an image.
The main actual problem that has occurred is /boot filling up.
Just thinking aloud …
The next best option for my money is: someone develops a module that is loaded via uuu and which enables booting from the USB-C port and then, after changing what is connected to the USB-C port, I can boot my Librem 5 from a USB flash drive if I have badly borked my eMMC drive (same as I would on an x86 computer). Options available could then include
a) reinstating uboot, regardless of where it is stored on the eMMC drive
b) editing files in /boot or in / on the eMMC drive
c) restoring an image to the eMMC drive (but noting that the USB-C port is tied up with the boot drive, so would need care for what choices are available)
d) who knows, maybe just running the phone from the USB flash drive for a while until I have time to sort out what I borked.
The deluxe version of that would be a dual personality USB flash drive that starts off playing the role of using uuu (USB host) then changes to being a vanilla USB mass storage device class. 
As far as I know, jumpdrive does not expose the hardware partitions of the eMMC. And that should stay so. As that’s a proper separation of OS and hardware specific installation realms.
The bare-bones uuu access is always exposed, currently. The possibility to disable it for everyday usage of the phone would, I guess, require 1) changing the uboot environment that’s saved in the hardware boot partitions, and 2) a password protected uboot console (could be just on the usb port) to still allow re-enabling uuu in recovery situations (say when booting with vol+ pressed).
IMHO it may be good to add jumpdrive as a recovery option readily installed to the hardware boot partition(s) and accessible with a password protected uboot menu. (OS kernels etc. should not be installed into the hardware boot partitions.)
Updates of the uboot environment and jumpdrive installation would then be protected by the two redundant (and usually single-level-cell mode) hardware partitions boot1/boot2. (Even if it really is the case that uboot itself can currently only be automatically loaded from only one of the boot partitions.)
As far as I know, the eMMC just has a vanilla partition table (with two partitions), and when I boot Jumpdrive the entire eMMC disk is exposed to the host as /dev/sda and the two partitions are created by the host, as is usual behaviour, as /dev/sda1 and /dev/sda2 .
Logged into the phone you can see the hardware partitions as /dev/mmcblk0boot0 and /dev/mmcblk0boot1.
And there is even more: /dev/mmcblk0rpmb.
1 Like
Ok, I can confirm that this works:
- Read
man flash-kernel. - Edit
/etc/default/flash-kernelon the phone. - Execute
flash-kernel.
It seems flash-kernel is actually (and correctly as discussed above) not “flashing” (copying) anything to locations outside of /boot on the eMMC user partition. (Not putting any OS managed files in hardware partitions.)
The output is not 100% clear about it, though:
purism@pureos:~$ sudo flash-kernel
Using DTB: freescale/imx8mq-librem5-r4.dtb
Installing /usr/lib/linux-image-6.4.0-1-librem5/freescale/imx8mq-librem5-r4.dtb into /boot/dtbs/6.4.0-1-librem5/freescale/imx8mq-librem5-r4.dtb
Taking backup of imx8mq-librem5-r4.dtb.
Installing new imx8mq-librem5-r4.dtb.
flash-kernel: installing version 6.4.0-1-librem5
Generating boot script u-boot image... done.
Taking backup of boot.scr.
Installing new boot.scr.
But at least when trying out non-working changes in /etc/default/flash-kernel, that triggered boot failures…
Recovery was possible by using jumpdrive to simply rename the /boot/boot.scr.bak into /boot/boot.scr.
1 Like
As an aside, I don’t think RPMB is viable in an open environment - and Purism strives for the most open of open environments.
RPMB would be great for locked down environments where the vendor pwns your computer and you are just lodging in it. Like say an Android phone or an Apple phone. But also other tightly controlled embedded environments.
So I would be surprised if the Librem 5, i.e. the software supplied with it, uses RPMB. On the other hand, if the eMMC drive in the Librem 5 supports RPMB then I guess you are free to use it for your own purposes.
Do you have any information as to whether these are being used at all on the Librem 5?
On mine they are each 4MB but they read as zeroes. Maybe that’s because of some security setting. Or maybe they really aren’t used.
There may be no harm in exposing these two partitions read-only. However over USB there may or may not be a way of enabling write access. And if there’s no way to enable write access then that should stay so.
I don’t think it will fit. That’s not to say that it couldn’t be slimmed down but that could be a fair bit of work.