Open chengjianwen opened 7 years ago
It's likely the installer does not properly set bootdev
info in cmdline.txt
in that case.
So according to this, devices tries to boot from SD, which obviously fails.
As a test (and until fixed), you may want to add bootdev=<boot_partition_on_USB>
in cmdline.txt
, and check if it then works.
it failed boot from usb
As in nothing on screen at all, and no blinking leds? Or failed in a different way?
Could replicate the issue. When using new Pi MSD bootmode it seems the installer gets confused.
In my case (PiZero in MSD bootmode, so using a bootcode.bin-only SD; some Pi3 need it too), with a FAT32 USB disk containing initial BB files, the install process kicked-in as usual.
After first screen, it proposed to initialize USB disk ex4 partition as expected, but (in my case with that specific SD at least) a message with failed shared.tgz
decompression then popped-in.
Rest seemed ok, and I followed the classical proposed reboot.
At reboot: just black screen, nothing, no cursor.
Looking at the resulting USB disk, I found its FAT partition was gone (!), the ex4 was fine (with usual berryboot directories). FAT partiton gone probably explained the shared.tgz
issue.
I also found cmdline.txt
and uEnv.txt
on my SD that was meant to stay a bootcode.bin-only SD.
cmdline.txt
showed datadev
partition pointing to sda1
(!), but no bootdev
partition: the expected outcome should respectively be sda2
and sda1
in such case.
So Intaller's partition detection seems consider SD as boot partition all the way through , and does not properly adapt to this new MSD boot mode (partition did exist in my case but did not contain berryboot files!).
In such MSD boot modes, SD slot could either be empty, or be FAT32 bootcode.bin-only, or anything unrelated: installer should find it's boot partiton elsewhere and set it in cmdline.txt
/uEnv.txt
.
I guess, in whatever mode, it's probably desirable Installer always set both partitions explicitly in cmdline.txt
.
Hope this will help fixing the issue.
Note: I cloned my known-good berryboot SD environment to a USB disk, and changed cmdline.txt
to match new partition names, and it works fine with my bootcode.bin-only SD: so routine image launch is fine, once partitions are properly set.
However I did not try to add further OSes nor edit config files from berryboot UI: unsure yet if partition detection routines in other parts of the code than installer are bullet-proof in such MSD boot mode.
About previous Note, I can confirm if bootdev
is not set in cmdline.txt
, although std booting will work (as datatev
is always set), hitting "Edit menu" will likely not mount proper boot partition either in MSD boot mode (it erroneously mounts /dev/mmcblk0p1
instead of sda1
in my case).
So any parameter editing from there will be useless.
So it seems we really need Install code to always set both bootdev
& datatev
in cmdline.txt
, and have the rest of code only look at cmdline
to make any determination.
Ideally, working with UUIDs would be even better to avoid eventual USB disk discovery potential undetermination, as sdX is not something much trustworthy either.
Perhaps delete the block of if statement in function halt() can be solve the problem. https://github.com/maxnet/berryboot/blob/d8a1a988bf2d34dcb3590d112271a85f462de3e6/BerrybootGUI2.0/bootmenudialog.cpp#L809 It seems /sbin/hdparm -Y /dev/sda can't work correctly when using usb-boot mode.
@chengjianwen
After several tests it very much seems the principal issue is that install routine does not set bootdev=
statement in cmdline.txt
when operating in MSD mode (i.e. with no SD or "fake" SD).
In some case it may even wipe original FAT partition of USB disk during such install...
If your USB disk has been installed fine (has 2 partitions FAT & ext4), you just need to set bootdev=
statement in cmdline.txt
from FAT partition: it should the operate fine.
Until install is fixed, the easiest way to install from scratch, is to first create your setup fully on SD (the traditional way), do first initialization & check all is good at first boot.
Then clone that SD to a USB drive (with dd
or similar, including the 2 partitions).
Remove SD from Pi, and BEFORE booting with such cloned USB device, make sure you properly set bootdev=
statement in cmdline.txt
(typically bootdev=sda1
) in FAT partition. Then you are fine.
Hope this helps.
@macmpi I'm sure the bootdev=sda1 was set in cmdline.txt. The situation: 1) power on the MSDed Pi. 2) berryboot begin mount the sda2, and pop up a menu with a installed systems list. 3) select a system to boot ( or a default within a timeout ) 4) boot the system.
The Problem is: When I reboot in a system (step 4), the pi can reboot correctly. When I Click "Exit" button in berryboot (step 2/3), the pi can't reboot. seems it can't find the boot dev.
When I Click "Exit" button in berryboot (step 2/3), the pi can't reboot.
Yes, this exit button (on lower-right part of window, sort of ON/OFF) is actually turning-off the device: it is intended. It's different from the exit button in Add OS menu (higher-right, sort of door), which indeed reboots.
When reboot by Add OS Menu's Exit button, the MSDed Pi can't boot up.
In my case (PiZero in MSD bootmode, so using a bootcode.bin-only SD; some Pi3 need it too), with a FAT32 USB disk containing initial BB files, the install process kicked-in as usual.
That you prepared the USB disk is not really what the code expects.
It expects a Pi 3, an empty USB drive, and that the initial BB files are on the SD card.
If program_usb_mode=1
is in config.txt it will assume you want an USB boot, so will prepare the disk (and set bootdev correctly) and give you a popup that it is now safe to remove the SD card.
That you prepared the USB disk is not really what the code expects.
Yes that's the situation, but it is a legitimate/supported way to get MSD operations:
For the original Raspberry Pi and the Raspberry Pi 2 (based on the BCM2835 and BCM2836 devices), and in situations where the Pi 3 fails to boot, there is a new method of booting from one of the new boot modes (MSD or ethernet).
So would be nice if berryboot installer supports this possible and very usefull scenario (even some Pi3 may require it), where SD may contain bootcode.ini
, but no berryboot file.
Generally user initially puts berryboot files onto the intended FAT partition (SD or USB), and let the installer run. Installer would just leave the berryboot files where they are, and do the rest of setup as currently. But it would not risk wipping original FAT as it may currently.
Would it be a problem installer always explicitly feeds bootdev=
statement in cmdline.txt
(even in case of SD boot)?
Maybe it could determine the genuine boot partition by inspecting where several mandatory berryboot-specific files reside?
I'll rephrase:
It expects a Pi 3, an empty USB drive, and that the initial BB files are on the SD card.
Can you consider equally supporting other Pi devices ( & Pi3 which may have bogus ROM) that also do have MSD boot capability with special bootcode.ini
SD ?
Thanks.
Not sure what the use-case of that would be. If I have a SD card putting the Berryboot system files on it makes sense, since these are read-only, and SD card starts a lot faster than USB HDD spins up...
What about this:
bootcode.ini
file on it, read only, never needs updating of any sort)Makes sense?
This usecase is not as specific as it sounds: It applies to any Pi models for which one might not want to mess with SD (accessibility may not be sole reason), and need to eventually swap boot environment easily (trying different Berryboot setups, ease of maintenance & deployment, etc...).
Can installer allow this please? (seems only an installer issue).
Can installer allow this please? (seems only an installer issue).
The whole current USB boot implementation is kinda fragile. Needs more refactoring, as there can be more than one USB stick, and who gets to be /dev/sda and who is going to be /dev/sdb can differ by boot. So the bootdev parameter currently used isn't that great.
Not much people use the functionality right now, so not a priority right now though.
The whole current USB boot implementation is kinda fragile.
This request is merely about getting feature parity across Pi Devices (including across rogue Pi3b batches) for an existing functionality. Making partition lock-in even more robust (using UUID for instance) would probably be a separate matter.
I get your point about your priorities, though functionality availability vs usage-rate may be a chicken-and-egg paradox: I may just be the only one doing it on non-Pi3 just because it is not possible by default, and requires hacking in install!...
BTW it seems Pi3b+ does support USB-boot off-the-shelf (not need for program_usb_boot_mode=1
).
Therefore current berryboot installer dependency on program_usb_boot_mode=1
to setup USB Boot configuration also needs to be waived for Pi3b+
And as for any other PI device, it also support USB Boot with recently updated bootcode.bin
on SD.
I too would expect using an SSD for USB boot should be similar speed to boot from SD card and have the advantage of swapping an entire boot / OS setup with just the drive, especially practical when SD card access is more difficult (Also not affected by SD card failures, although since BB only reads as @maxnet said this is less of a factor).
@macmpi Do i understand correctly that currently to boot BB from USB is only possible by cloning a BB SD card partitions unto it?
Any plans to support installing BB image unto USB for boot to skip the SD Card?
well, it depends... (unless things changed in the recent build, which I doubt).
If you have a Pi3b, and set program_usb_boot_mode=1
in config.txt
, Berryboot install procedure should do proper USB initialization and partitionning. (you may remove program_usb_boot_mode=1
after).
I guess it's the same with Pi3b+ (it seems berryboot install procedure might still rely on program_usb_boot_mode=1
to setup the USB correctly, whereas those device are already programmed to enable that boot method by default).
If you have a "problematic" Pi3b which has difficulty to boot in USB mode, or some other devices like PiZero or PiZeroW, they technically can work with USB boot provided you insert a dummy SD with only bootcode.bin
file.
The issue I described here, is that such cases are not properly handled by berryboot setup program, and you have then to manually clone a working SD on USB media, and changebootdev=
parameter in cmdline.txt
Hope this helps. Would be nice if berryboot setup routine allows to seamlessly setup USB boot media for more scenario.
@macmpi thanks. I only discovered afterward that I couldn't use the same usb SSD drive to install OS from and to :) that's a pain.
Ideally would be boot BB from one drive (avoiding the need for an micro sd card) which already got the images on it, whether on the same or a separate EXT4 partition. :blush:
impossible to do this on a Raspberry pi 2 upon connecting the hard drive the berryboot crashes i have an official power supply 2,5A is there a usb max current setting for berryboot in config.txt ?
Yes recent Berryboot versions use bbloader.img
as an initial loader (check config.txt
), and this currently breaks the possibility to boot berryboot from USB drives (only OSes can still be on USB drives).
As a workaround, you may want to modify config.txt
and replace initramfs bbloader.img
by initramfs berryboot.img
: with that it should work.
( bbloader.img
is just here to seemingly accelerate startup time, does nothing more)
(note on Pi2 you must use a SD card in anyway: boot from USB is not possible, whatever distribution you use. Now you may have a fake USB boot with a bootcode.bin
-only SD card, but not sure it has any value in your setup. Just makes sense if you have no physical access to SD and you want to swap USB bootable media)
thanks
i installed berryboot on usb but it requires the memory card to boot from usb otherwise is not working,how can i disable the need for the memory card??
Please read the second part on the previous message. On Pi2 SD card is mandatory whatever distribution you use.
i did the test in a Pi 3 i did not try on the Pi2 yet so is it possible to disable the sd card read in the Pi3 complete?
by uncomment the program_usb_boot_mode=1 in config.txt before berryboot installation it does the same it needs the SD card to boot
Try USB booting native Raspbian distribution from Pi Foundation first, and use forums there to search/get eventual support (many folks have done that). Once that works, adapting Berryboot install to such "unsupported" setup can be discussed (there too). Not sure such discussion is appropriate as Github issues.
i couldn`t find anything anyway thanks for the help
will you update berryboot for raspberry pi 4 with newest firmware/kernel/drivers??
and another thing in usb boot do i uncomment the SD card polling line ??
Yes recent Berryboot versions use
bbloader.img
as an initial loader (checkconfig.txt
), and this currently breaks the possibility to boot berryboot from USB drives (only OSes can still be on USB drives).As a workaround, you may want to modify
config.txt
and replaceinitramfs bbloader.img
byinitramfs berryboot.img
: with that it should work. (bbloader.img
is just here to seemingly accelerate startup time, does nothing more)(note on Pi2 you must use a SD card in anyway: boot from USB is not possible, whatever distribution you use. Now you may have a fake USB boot with a
bootcode.bin
-only SD card, but not sure it has any value in your setup. Just makes sense if you have no physical access to SD and you want to swap USB bootable media)
(I'm french)
I have followed your instructions but i have this error : Unable to read partition as FAT. Have you a solution to this problem ?
hi,i managed to get my usb hdd to boot and when i am on berryboot edit menu upon exit/reset the hard disk closes immediately it should not do that since its a reboot/reset and not a shutdown,can this be fixed with a command in config.txt ??
or at least do to a spin down slowly and close somethign like that
How can we prevent the hard disk from spin down and eventually going to sleep mode every 5-10 minutes?? What can i add to config.txt to prevent this ??
How can we prevent the hard disk from spin down and eventually going to sleep mode every 5-10 minutes??
Recall you can disable it for the current session with hdparm Will need to add it to a startup script or udev rule if you want it to persist.
https://wiki.archlinux.org/title/hdparm#Persistent_configuration_using_udev_rule
It seems the latest version berryboot (20170527) support usb-boot when I add program_usb_boot_mode=1 to config.txt file.
It worked normally. But When I exit from berryboot boot menu to reboot the pi, it failed boot from usb.