Boot manager for Pi - anybody using one?

I've become used to using grub as a boot manager on x86 systems over the years, for boot time selection of multiple OS, so thought I'd try the same for the Pi.

However Google doesn't seem to throw up a lot of options.

Is anyone using a boot manager?

If so, does it work headless?

I know the standard answer is "just swap the card over" but it would be nice to be able to swap functionality remotely if you are running the Pi elsewhere in the house (or even in the shed).

Also, with grub for example, when you upgrade to a new kernel you have the option to revert to the previous build.

You can also fire up memtest (well, memtest86 of course) which brings us to the question of stand alone diagnostic tools........

Anyway, anyone doing it?

Cheers

Dave R

Reply to
David.WE.Roberts
Loading thread data ...

you could do this by renaming files on the boot partition

not me, but rasbpian includes grub.

--
?? 100% natural
Reply to
Jasen Betts

actually, it includes fragments of grub, not enough for it to be usable.

--
?? 100% natural
Reply to
Jasen Betts

GRUB (or Lilo) simply won't work on the Pi.

The ROM in the GPU loads its bootcode from SD card - that's written in GPU code. This then initialises the system and looks for a few more files on the SD card and ends up loading kernel.img into RAM and taking the ARM out of reset which then boots Linux (or whatever you put in kernel.img)

Berryboot might be an answer though:

formatting link

Or just swap the SD card.

Gordon

Reply to
Gordon Henderson

Thanks - starting to gather information :-)

I'm still trying to get out of the mind set of using a BIOS as the first point in the boot cycle, which I think you are saying is not the way the Pi works.

From the little I have read about Berryboot I think that this starts, then choses which kernel.img to load.

I tangled myself in grub, bios, boot sectors, boot loaders and chain loaders a little while back (and ended up with a raging headache) but what you describe above sounds broadly similar - load a simple environment capable of making choices, then pass control (perhaps in several more complex stages) to the kernel (or other bootable code) of the chosen OS so it can drag itself up by its' own bootstraps.

I may just donate the fast 32GB SDHC card to the cameras and reclaim some medium speed SDHC cards of smaller size, of course, but it would be nice to be able to flip between different versions on the same card.

Um..........distant hazy memory........

At one time didn't you used to do something like

"ln -s unix.1324.12 unix"

to pick which version of unix booted?

Presumably an extension of this could link the root filestore to various different filestores?

Ah, well, time to go out and do some reading.

Cheers

Dave R

Reply to
David.WE.Roberts

Yes. There is no "BIOS" as such. The GPU is "king" and it has enough of a ROM on-board to read a single file off a FAT formatted SD card.

The Pi has (broadly speaking) 2 processors here - the GPU and the ARM. The GPU is the real heart of the system although 95% of the stuff we're doing is on the ARM.

If only the FAT filesystem understood links...

I'm using 4GB SD cards in my Pi's. Not found the need for anything more. Raspbian installs on a 2GB card, but 4GB gives you a bit of space for some projects - not enough to store big movies, pictures, though, but I have a LAN for that..

Gordon

Reply to
Gordon Henderson

It's reassuring to know that the GPU on a headless Pi is not totally wasted.

--
Graham. 

%Profound_observation%
Reply to
Graham.

FWIW I once ran Linux on a 486-66 where the BIOS couldn't handle the hard drive. To boot Linux, it booted DOS from a floppy and then ran an application that brought the Linux image in after DOS had loaded drivers. Maybe the same kind of tactics could load an alternate OS into the Pi.

Mel.

Reply to
Mel Wilson

Well, the firmware just loads the file called "kernel.img" at 8000h (or

0000h if you set kernel_old=1. That file doesn't have to be a Linux kernel, it can be any arm code.

For a simple bootloader, it would need to relocate itself out of the way, be able to read the SD card to load in the true kernel image (not too hard), setup ATAGs so the true kernel can get its command line data and a few other bits, write stuff to the frame buffer (none of this is particularly hard) and read a USB keyboard (not so easy, but people have written some basic drivers for this). Then jump to the kernel entry point at 8000h.

I suspect this is what Berryboot does, but I haven't looked at that.

I just swap cards. Much easier :)

Reply to
Dom

You don't need symlinks, you can just edit config.txt to point to the name of whatever kernel you want to boot.

There's also U-Boot for the Pi, though I thought it was more polished than this:

formatting link

Theo

Reply to
Theo Markettos

In those days I booted Linux from a floppy to overcome that problem. At first, one floppy, but later it needed 2 floppies. That made it inconvenient but it still worked... (installation was even harder)

I envision a problem would be to write enough code to present a menu and ask for a selection. In the old days I did that in the MBR sector, but then we had a BIOS. How much of the hardware of the Pi is already initialized "automagically" when the bootcode is loaded? Can it display anything or does the whole GPU need to be initialized? Can it display characters or only graphics?

May be better to just boot to a default Linux and then use the "kexec" feature to switch to another one if required.

Reply to
Rob

Am 12.06.13 10:32, schrieb David.WE.Roberts:

May be of topic:

I just bought my second one. The first one is raspbmc and heavily used. The second will offer the web-server including owncloud. I first had the same thoughts as David. But that nice little piece is worth it's price. And frankly, how can I access on a dual boot system my webserver or my raspbmc? Buy a second (or third and fourth, as a friend of mine did) and get lucky:)) Regards JJenssen

Reply to
JJenssen

Almost none of the hardware is initialised. There is no "VGA" type display or BIOS type IO calls.

There are ways of accessing the frame buffer, but you will have to draw the text yourself.

There are no calls to access the SD card, although the interface is accessible so you have to initialise that yourself and implement read/write calls.

The same goes for USB. The port is accessible, but there is no stack or functions, just a set of memory mapped registers.

Reply to
Dom
[some snippage has occurred]

I tried a 2G card, then (naively reading a blog) I did "apt-get update" and "apt-get upgrade" - I think it filled the card, as it wouldn't boot afterward; I reimaged and I'm back up now, but I suspect the default free space isn't enough.

--
It's a money /life balance.
Reply to
Stanley Daniel de Liver

yerrs. the packages themselves remain on system un-installed I think.

there is a command to get rid of all 'packages I've got installed already' from the archive

|apt-get clean

will clear packages show contents are already installed, I think. This can gain you a LOT of space back.

If you are really short of space, do that beire rebooting, and preferably upgrade in parts.

And clean between each part.

this is a handy idiot cheat sheet

formatting link

|
--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
Reply to
The Natural Philosopher

Yes, take a 4G instead if you need the upgraded versions.

- Martin

Reply to
Martin Τrautmann

te"

oot

=

Thanks, that was what I was concerned about in Gordon Henderson's post.

-- =

It's a money /life balance.

Reply to
Stanley Daniel de Liver

Another way of freeing disk space is to install and configure the localepurge package. This deletes locale files and man pages for languages you have no use for.

--
Dave
Reply to
dave

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.