Hello folks!
This is my first post in this forum. I just got my Librem5 (I was one of the backers of the L5 campaign).
I’m wondering if there is any way to get a multi-boot with this device. Something like this:
It’s not convenient to flash the device in order to test another OS.
Thanks
No idea how to port multi-boot image to Librem 5, but it’s possible to boot Librem 5 from USB according to Librem5 sd and boot order.
Great! If you would like to share your info about the timing in this other thread Estimate your Librem 5 shipping that would be much appreciated by those of us trying to guess how the shipping is going, how many they send each month and so on. I understand of course if you don’t want to tell everyone.
About multi-boot I don’t know, I would also like to find out more about if/how that could work. All I know is that it works differently to various GNU/Linux laptops where I have used multiboot, because the Librem 5 does not use grub. Maybe multi-boot is possible, but not the way I am used to.
If you put an L5 image in the microSD card and connect the L5 to a PC using a USB cable, then you can boot from USB while holding down the Volume Up key and then use jumpdrive to boot from the microSD card. (At least that is how I think it works from the Jumpdrive instructions.)
Looking at how Jumpdrive works, you can probably have multiple images on your PC and boot from USB and then manually load one of the images. Maybe @dos can provide instructions how to do it.
No, you would boot the other system like you would boot Jumpdrive, not using Jumpdrive.
Jumpdrive is a tiny OS by itself which exports eMMC as a mass storage device to your PC, so your L5 disk is seen by your PC as a USB drive.
I’m a newbie in booting mobile devices. As far as I understand u-boot is the “real” bootloader of L5.
Let’s say that “multi” is too much, so let’s focus on “dual” boot or chainloading.
Using u-boot
You say
u-boot then loads the kernel, dtb and initramfs, also either from eMMC or USB (with uuu). Loading those from an SD card is theoretically possible, but will require drivers in u-boot since the SD card reader is a mass storage USB device behind a USB hub.
Is such kind of drivers available? Does L5 include them? If not, is the L5 team working for providing this feature?
Once the kernel is loaded, it can mount the rootfs from any device. I’ve already successfully booted operating systems on Librem 5 with rootfs on microSD or external USB drive this way.
This is a good point. Is there any documentation about it?
Reboot another kernel
What about kexec? Is it supported by the PurismOS kernel?
Chainloader
Is there any u-boot --> (grub|other-boot-loader) solution?
We can open different thread for each topic that we can discuss, if you agree.
Thanks
No. Currently u-boot does not know how to talk to the microSD card on the L5 and I’m not aware of any work to make it able to so far.
Actually, I’m not sure. I learned that myself by reading and modifying uuu scripts from https://source.puri.sm/Librem5/librem5-devkit-tools/-/tree/pureos/byzantium/uuu_scripts
It should be supported and I think it worked at some point, but it’s not a thing that’s being regularly tested so it may break. I imagine that once someone builds a kexec “bootloader” this would likely change though 
Possibly. I haven’t tried though and I don’t know whether anyone else did. Technically nothing should prevent you from chainloading.
This seems a limitation of the Librem 5, since u-boot should be able to boot from SD/MMC cards (from this video at 20:00).
I see kexec is available in PureOS repo, along with Petitboot. Using Petitboot seems to be a reasonable simple way to re-boot the device from another source, isn’t it? But kexec must be supported by the PureOS kernel.
SD readers aren’t equal. Our one is integrated into a USB hub and uses USB interface. u-boot would be already able to boot straight from SD card on L5 if the reader used the MMC interface of the SoC, but we’ve got only two of those and they’re already taken by eMMC and WiFi. So, u-boot needs to learn how to be a USB host on L5 and then access the mass storage drive in order to boot from it.
It seems not to be supported at all:
root@pureos:~# kexec --load ...
kexec_load failed: Function not implemented
entry = 0x46531690 flags = 0xb70000
nr_segments = 4
...
root@pureos:~# grep -i kexec /boot/config-5.11.0-1-librem5
# CONFIG_KEXEC is not set
# CONFIG_KEXEC_FILE is not set
Is there any technical limitation about this or it’s a matter of choice?
That’s something that I would certainly welcome. Not only would it allow booting from the uSD card but it would allow booting from a USB drive attached to the USB-C port. Not urgent, but one day …
Nice, but maybe this is a bit insecure for a phone: you could boot another OS wihout requiring authentication. Furtermore you need a bootable installation on the external usb drive. IMO, by supporting kexec+petitboot you should be able to reboot your phone using another kernel/OS only after login.
True, but you can boot ‘anything’ anyway by connecting to a PC and booting a program loaded from the PC. I think.
Yep basically,
secureboot can block some things from booting. Though I think most if not all systems can have that turned off fairly easily in the bios.
Since the phone can be flashed over usb, I’m having a hard time thinking of what risk one would have by being able to boot off of usb. Since being able to flash it implies access to the local disk.
I compiled the 5.11.4-librem5 kernel with kexec support, so kexec --load ... worked fine, but I got a black screen on kexec -e… perhaps kexec is broken at the moment? However, I never worked with it before, so maybe I didn’t use it correctly 
There also seems to be some bootmenu support in u-boot, but I don’t know if all required drivers are available in u-boot yet (video/framebuffer etc)?
As a workaround, one could modify the u-boot script to get kexec-like functionality. For this, I added the following at the top of /etc/flash-kernel/bootscript/bootscr.uboot-generic:
if test -z "${alt_boot}"; then
setenv alt_boot 0
saveenv
fi
if test "${alt_boot}" -ne 0; then
setenv alt_boot 0
saveenv
setenv bootargs "${alt_cmdline}"
load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${alt_kernel} \
&& load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${alt_fdt} \
&& load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} ${alt_initrd} \
&& echo "Booting alternative kernel from ${devtype} ${devnum}:${partition}..." \
&& booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
setenv bootargs
fi
Then run flash-kernel and reboot. Perhaps one should backup the u-boot script /boot/boot.scr before that in case anything goes wrong The reboot is necessary so that saveenv is called at least once. Now, the idea is to use fw_setenv to modify the u-boot environment variables. For this one needs to create the file /etc/fw_env.config with the following content:
# Block device Device offset Env. size
/dev/mmcblk0boot0 0x3fe000 0x2000
To check that this works, one can call fw_printenv, which should show a line alt_boot=0. Now one can run the following to reboot with a new kernel cmdline:
echo 0 > /sys/block/mmcblk0boot0/force_ro
fw_setenv alt_boot 1
fw_setenv alt_kernel vmlinuz
fw_setenv alt_initrd initrd.img
fw_setenv alt_fdt dtb
fw_setenv alt_cmdline "console=ttymxc0,115200 console=tty1 plymouth.enable=0 fsck.repair=yes security=apparmor root=/dev/mmcblk0p2"
sync
echo 1 > /sys/block/mmcblk0boot0/force_ro
reboot
This should reboot PureOS but showing the kernel messages etc instead of the splash screen. The path of alt_kernel etc is relative to /boot/. The next boot should be “normal” again, so the change is not permanent, like a kexec. One needs to call fw_setenv alt_boot 1 again in order to enable the alternative boot settings for the next reboot.
I just booted linux from SD by modifying root in the alt_cmdline For me this workaround is fine for experiments for now. I guess one could use something like this to get Petitboot to work. Still, it would be cool (and cleaner) to use kexec instead of the workaround above.