Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always set bootdev during install #545

Open
macmpi opened this issue Dec 6, 2018 · 5 comments
Open

Always set bootdev during install #545

macmpi opened this issue Dec 6, 2018 · 5 comments

Comments

@macmpi
Copy link
Contributor

macmpi commented Dec 6, 2018

Capturing within a specific issue a setup problem that has popped up in several issues.

Currently bootdev parameter in cmdline.txt is only set by install routine when setting-up USB boot option.
The problem arises as current USB-boot option setup may not cover all possible cases, and therefore there can be hit/miss situations as explained in that earlier thread.

While overall partition detection may need to be more robust (using UUIDs or else. LibreELEC has some inspiring init code doing that), setting bootdev in all cases would not break existing setups, and would help in USB-boot setup that are not fully handled currently (like MSD requiring bootcode.bin on SD).

Thanks for consideration.

@maxnet
Copy link
Owner

maxnet commented Dec 9, 2018

I am not sure if MSD booting is something worth spending much time on.
It doesn't work reliable enough in my opinion, and using SD card remains the better option in all use-cases.

@macmpi
Copy link
Contributor Author

macmpi commented Dec 9, 2018

Well, I have it running 100% fine on my RPI0s, but initial setup is complex due to non-supporting install procedure and manual bootdev setting.
(BTW if on Pi3B+ you may make it more reliable with the bootcode.bin-only SD ;) ).

SD operation is an issue (for update / maintenance, etc) if SD is not much physically accessible: it is often the case if you embed your PI within an enclosure / bigger device.
SD may have more limited lifespan too...
A typical usecase, is putting a RPi inside a HiFi Amp to upgrade existing Hifi setup.

Pi Foundation invested time in MSD booting (and gradually made it a default feature for new models) because their customers asked for it: demand & usecases are indeed increasing.

Thanks!

@maxnet
Copy link
Owner

maxnet commented Dec 9, 2018

If rpi.org would do some more effort and:

  • alter bootcode so usb power is not cut between bootcode and starting of Linux, causing usb hard drives to spin down and up again. (which does not happen when a normal computer boots from usb storage)
  • would make information about which boot device bootcode decided to actually boot from (usb port number, mbr id, whatever) available through device tree. So we would not have to mess with bootdev and similar parameters.
  • would make sure they test each firmware release on usb storage. Right now there are quite a few complaints on forum that booting from MSD stopped/started working depending on firmware release and phase of the moon.

Then I might think about it.
But right now putting the Berryboot files on SD card is much more reliable.
The chances your SD card breaks while only those files are on there is not so high.

@macmpi
Copy link
Contributor Author

macmpi commented Dec 9, 2018

I'm sure @pelwell, @ghollingworth & crew would value your feedback on improving things, particularly about bootloader's feedback on selected boot partition, and USB power cycling (note some improvements were built-in since Oct 29th).

Anyhow, as a simple berryboot user, getting feature support parity across devices, and consistent use of current bootdev statement would definitely be a net benefit, event if the rest is not perfect...

Cheers.

@macmpi
Copy link
Contributor Author

macmpi commented Sep 8, 2019

Referencing this thread on USB power-cycling raspberrypi/linux#3058 (comment) and eventual improvements?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants