Proposal/idea for a "new" bootmenu
Challenge: bootmenu.conf can be difficult for new users to deal with, initfs flashing and such. There is no way for installers for Debian, Android or whatever to easily add boot menu items without having to reflash. Diablo introduces rw initfs which is easier than reflashing, but this leaves people not using Diablo or N770 in the cold.
Proposal: Bootmenu that loads bootmenu.conf from a boot partition (this may be the internal flash (as in mtdblock4), or in Diablo, initfs itself. If bootmenu.conf loading fails, it may be able to select USB network recovery and such or use a default setting The idea is to mount the boot partition read only, read the file, and unmount it (if not on initfs) Bootmenu that has interface like: # bootmenu add <uuid> <title> <image?> <partition> <file system type> <fs options> <extra boot options> Adds a boot menu item with those settings, with a UUID so we can easily remove it later. The image would maybe have ability to do something like http://www.slashgear.com/gallery/dat...mp-photo10.png . This will set it properly up in the bootmenu.conf, and after this command is done, the user can select the item in bootmenu when rebooting # bootmenu remove <uuid> # bootmenu list lists items in bootmenu currently and their UUIDs Example use: # bootmenu add DEBlet1234 "Deblet" deblet.png /dev/mmcblk1p2 ext3 ro,noatime --no-var-run-fiddling Abilities like this would make it possible to have a more user friendly way to do SD cloning, alternative OS'es and such. |
Re: Proposal/idea for a "new" bootmenu
|
Re: Proposal/idea for a "new" bootmenu
The problem with those is that well, the initfs boot menu is actually a 3rd stage bootloader - the kernel is loaded already and it's actually "just" a /sbin/init placeholder :) What i'm proposing is "low hanging fruit" - as in, things that could be implemented easily, if designed properly, and yet have quite a lot of gain towards booting other linux-based OS'es on the tablets, both in terms of usability and in terms of providing service for boot menu addition for those OS'es
|
Re: Proposal/idea for a "new" bootmenu
Yes, bootmenu/initfs_flasher is currently not very usable for running from automatic installer scripts. To make bootmenu more friendly for installers it would be nice to
1. allow silent installation i.e. default install with no questions or take answers from parameters or file. I guess penguinbait did some work on this already (?) 2. provide commands to add/remove boot items 3. package it into .deb Quote:
It does not look very deterministic and robust to me. I'd like to keep bootmenu independent on any root filesystem. Is location of bootmenu.conf really a problem if other issues mentioned here are solved? If yes than I would prefer putting it to end of kernel partition possibly gzipped to save space and to have some sort of container. In fact config partition /dev/mtd1 is designed for this but I currently don't know how to write some configuration item there. Quote:
Quote:
I'm happy to accept patches. There is also bootmenu garage project so if more people start to produce some code we can work there. |
My idea was not to scan for bootmenu, but have a precoded partiton, fs type and path to get it from:) i investigated cal-tool -set-root-device for this but it can at most contain about 100 byte. Dunno if thats enough.
|
Re: Proposal/idea for a "new" bootmenu
I've implemented a patch for fanoush's bootmenu, which does the following:
* Adds ability for $MENU_${MENU_IDX}_LINUXRC that at the end of boot menu selection mounts selected rootdev and exec's /linuxrc on the partition - leaving the boot process entirely to linuxrc instead of going through initfs's linuxrc which does funky things to the /var/run, /tmp etc. This makes it a lot easier to port Linux based systems to the tablet as we don't have to deal with the oddities of the boot process. * Adds a "standard" bootmenu.conf, which loads boot menu items from /etc/bootmenu.d/*.item on rootfs (mounting ro, and unmounting afterwards) and inserts them into boot menu on boot time. This adds 1-2 seconds of boot time, but it has the advantage of allowing Clone-to-SD, Deblet, etc to insert boot menus easily when installing - and hoping to make something like this standard in some way to allow for easy boot menu stuff / multiboot. Example item: /etc/bootmenu.d/deblet.item: ITEM_NAME="Deblet" ITEM_ID="deblet" ITEM_DEVICE="mmcblk1p2" ITEM_MODULES="mbcache jbd ext3" ITEM_FSTYPE="ext3" ITEM_FSOPTIONS="noatime" ITEM_LINUXRC="yes" Patch can be found on http://bsd.tspre.org/~stskeeps/bootm...uxrc.patch.txt I'd like some comments from any others doing bootmenu modification and hear if this could be a good way to have a shared boot menu system that allows for easy multibooting and not messing up eachothers boot menu settings - that you would use ;) Thanks to: lbt (bootmenu.d, linuxrc idea), fanoush (for his bootmenu) |
Re: Proposal/idea for a "new" bootmenu
I don't get it where $root_dev in the script is and which (hardcoded?) rootfs it used for the dynamic menu. Isn't it chicken and egg problem? People can have random rootfs in internal flash (Poky, Android, Mamona, whatever) so there is no 'standard' place to install such menu in rootfs. Also with reflashing rootfs in internal flash you'd loose such menu even if the rest of the systems on mmc is fine.
As for /linuxrc in rootfs, is this really used instead of /sbin/init in some systems? Maybe the code should fallback to run /sbin/init if /linuxrc is not found instead of plain reboot? Having some workaround for the funky stuff you mention done by nokia /linuxrc in initfs should be useful though. But still, I'd like the bootmenu code to fallback to nokia /linuxrc in intfs so the system is properly initialized (see the boot() function in linuxrc, loading wi-fi module and telling dsme that the rootfs is mounted can prevent some surprises even in your random rootfs) |
Re: Proposal/idea for a "new" bootmenu
Quote:
Quote:
Quote:
I've seen the use of /linuxrc as a pre-pivot script on another embedded system to allow for multiboot as well - it gives some flexibility for system developers to do things "right" Quote:
Thanks for the constructive comments - I'll see what I can do to make the patch a little more sane. |
Re: Proposal/idea for a "new" bootmenu
Quote:
Quote:
So basically I'd concentrate on efforts to put it to initfs or maybe end of kernel partition (and change kernel flasher to not to wipe whole partition). Diablo uses own kernel flasher (not sure if it wipes whole partition or not) but with Diablo writing to initfs is easier. But still I see reflashing modified initfs with new menu addition as the easiest method if initfs cannot be modified directly. Quote:
|
Re: Proposal/idea for a "new" bootmenu
I've taken some of fanoush's advice and implemented this in a new patch, where the changes are:
* When bootmenu is flashed, /etc/bootmenu.d/*.item is copied onto the flash image. * bootmenu.conf now loads from /etc/bootmenu.d on initfs instead of mounting rootfs * Added new tool, refresh_bootmenu which refreshes /etc/bootmenu.d on initfs without modifying anything else * Fallback to /sbin/init on initfs if linuxrc cannot be exec'ed * Fixed minor bug with not clearing out ITEM_LINUXRC This fixes two scenarios: SSU breaking multiboot (most likely, since it's WONTFIX..), https://bugs.maemo.org/show_bug.cgi?id=3589 by the fact you can reflash and still have same boot menu. Rootfs reflash - /etc/bootmenu.d is still in initfs. Patch is at http://bsd.tspre.org/~stskeeps/bootm...xrc-patch2.txt My personal goal for this is along the lines of: Bootmenu deb that installs boot menu files and such on system, but doesn't flash until user clicks the icon in Utilities "Install Boot Menu" (runs it in x-terminal on device). This one would prolly help a lot if SSU's keep on breaking boot menu.. /usr/sbin/flash_bootmenu (initfs_flasher) /usr/sbin/refresh_bootmenu (for Deblet installer and other installers, put in item in /etc/bootmenu.d/ and run refresh_bootmenu in a xterm or whatever) |
All times are GMT. The time now is 03:19. |
vBulletin® Version 3.8.8