new boot sequence

[macmpi]

Hi,

I've noticed the recent change in boot sequence as per fd96787
I'm curious to understand how this may impact MSD boot process, including cases where either no SD is available at all or, with bootcode.bin-only SD (problematic Pi3s and other devices like Pi0).
What if bootdev= is customized (i.e. not set on mmcblk0) in such setup?

Thanks for any hint.
PS: UUID support is nice addition, thank!

[maxnet]

• I don't see any good use-case for bootcode.bin-only SD cards.
  Just put the rest of the Berryboot files on SD as well in that case.

• bootdev is set to UUID in cmdline.txt now: fb7d525#diff-41eb682e7574f3424f4a99a6b45c9beaL184
  Busybox-static has been compiled with right options to mount by UUID (CONFIG_FEATURE_MOUNT_LABEL=y)

[macmpi]

What is the purpose of this new tiny boot phase that mandates use of SD?

I don't see any good use-case for bootcode.bin-only SD cards.

Mentioned this before for instance.
Pi may be embedded in a casing which make upgrading software on SD extremely unpractical (no physical access to SD). So having all software on accessible USB is highly desirable sometimes.
Unfortunately some device (faulty, older) still require bootcode.bin SD at least: this is an option we can live with, as that piece alone does not need much updating (or is very easy to update in SSH).
Please consider some users may have valid usecases, and raw performance is not always the most important feature: compromise may be acceptable.

[maxnet]

What is the purpose of this new tiny boot phase that mandates use of SD?

Speed.
Have the impression that the firmware is a lot slower in reading from SD card then Linux.

[macmpi]

I understand speed impression.
I guess you can understand the "good" use -case too.

Can we think about a solution that allows SD-free usecase (like before), even if in such case, boot speed may be a bit less optimal?

[maxnet]

Well, just put "initramfs berryboot.img" in config.txt if the new mechanism does not meet your needs.

[macmpi]

Thanks will try! (did not realize I can fall-back to this).

I guess busybox inside berryboot.img now also supports mount by UUID (along by dev name), right?
EDIT: CONFIG_FEATURE_MOUNT_LABEL does not seem to be set in that one.

Would it be possible to migrate that busybox to stable 1.30.1 at least (that Buster & Alpine use), so that we can benefit from much more compatible TLS support in wget (along many other fixes)?

[macmpi]

BTW, there is a bit of hiccups with previous conventions where in older cmdline.txt scheme we'd use mmcblk0p1, but now bbloader.img seems to require the full /dev path (/dev/mmcblk0p1) alternatively to UUID.

Can you please confirm the consistent syntax standardized upon for use in cmdline.txt?
Can we assume either full path (like /dev/mmcblk0p1) or UUID moving forward?
(datatev may just have iscsi exception, that is fine).

I need to update my berryboot-scripts accordingly to avoid situations that arose like below:

1. After setting bootdev=/dev/mmcblk0p1 is it normal that on the next restart, berryboot is unable to mount the system partitian? (...). If I don't include /dev/ in front of mmcblk0p1 then berryboot wont boot at all.

Appreciate your feedback !

[maxnet]

If it is mmcblk0p1 bootdev should not be specified.
It should already accept sd*

[macmpi]

why should not be specified if mmcblk0p1: would it cause a problem if it happens to be?
Do you mean need not?

My original point is: previously /dev/ prefix was not desired. Now it seems required, if anything is set.
Shall we rely on this new practice for good?

[maxnet]

Because we only have special handling that prepends /dev for sd* right now.

berryboot/external/package/busybox-static/init

Line 41 in e80cf35

if [ $BOOTDEV == sd* ]; then

It defaults to mmcbl0p1/mmcblk if no bootdev is specified.

[macmpi]

Then, what are the acceptable values on can find for cmdline's bootdev parameter, depending of cases?

• NO bootdev specified (would then assume mmcbl0p1/mmcblk)
• sdX (if entered manually?)
• UUID (as set by newer initialization routine)
• mmcbl0pX (if entered manually?)
• any fully qualified path (/dev/mmcbl0pX or /dev/sdX) if entered manually?

It would really help if parameter syntax and handling was same and consistent across any kind of devices (sdX, mmc) and across boot images bbloader.img & berryboot.img.
It's very difficult to track-down currently (and changing) if one needs to reliably mount boot partition within berryboot-init... Many cases to handle and figure-out.

OR...

If that "magic" is not to be standardized/documented for some reason (legacy compatibility, etc...), then, would you accept just making available a mountable reference string in a BOOTPART variable here, so that one can simply & safely mount $BOOTPART /some/where within berryboot-init if need be?

Is one of these 2 approaches something you could consider please?

[macmpi]

* bootdev is set to UUID in cmdline.txt now

I just tried that, but no-luck actually: I may be missing sth.
Took a brand-new SD and did berryboot install from scratch.
Resulting cmdline.txt did not have bootdev defined as with previous versions (in particular no UUID reference).
I then added bootdev=03F3-8CD6 (UUID determined with sudo blkid) and rebooted: bbloader failed finding the partition to mount...
(note: ignoring bbloader in config.txt and jumping direct to initramfs berryboot.img I could manually mount /dev/disk/by-uuid/03F3-8CD6 under console fine: seems like a UUID mount issue inside bbloader)

In which condition is UUID now set by setup?
How should be set UUID reference in cmdline.txt if we want to ensure a specific partition is used?

[macmpi]

Ok, got it, cmdline.txt statement must be in the form bootdev=UUID=03F3-8CD6 when referencing UUIDs.
Some documented section on partition access conventions would really help :)