Proposal/idea for a "new" bootmenu - maemo.org

Active Topics

Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 17 hrs, 43 mins ago
more...

Page 1 of 2

Next >

Thread Tools

	Stskeeps	2008-08-10 , 10:16
	Posts: 1,671 \| Thanked: 11,478 times \| Joined on Jun 2008 @ Warsaw, Poland	#1

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.

Quote & Reply |

The Following 5 Users Say Thank You to Stskeeps For This Useful Post:
b-man, hns, josiahg777, qwerty12, timsamoff

josiahg777	2008-08-10 , 19:25
Posts: 425 \| Thanked: 132 times \| Joined on Mar 2008 @ California	#2

Could something like XOSL be tweaked to fit these needs?

or GAG perhaps?

I don't know much about either of these projects, but they're open source and platform independent.

Perhaps one of them can be modified enough to suit?

__________________
Promises are like babies. Fun to make, but hard to deliver.

Warning: dates on calendar are closer than they appear.

Quote & Reply |

	Stskeeps	2008-08-10 , 20:06
	Posts: 1,671 \| Thanked: 11,478 times \| Joined on Jun 2008 @ Warsaw, Poland	#3

Originally Posted by josiahg777

Could something like XOSL be tweaked to fit these needs?

or GAG perhaps?

I don't know much about either of these projects, but they're open source and platform independent.

Perhaps one of them can be modified enough to suit?

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

Quote & Reply |

fanoush	2008-08-11 , 07:13
Posts: 2,152 \| Thanked: 1,490 times \| Joined on Jan 2006 @ Czech Republic	#4

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

Originally Posted by Stskeeps

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)

Scanning random partitions at boot time can be slow. Mounting jffs2 in particular is not exactly fast. You also need to insert extra modules in case of ext2/3. Also what to do if more bootmenu.conf files are found?

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.

Originally Posted by Stskeeps

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.

Good idea in general. I'd prefer to pass to such bootmenu command some file with menu item template similar to current bootmenu.conf syntax. It would just merge the item into existing one and reflash initfs if it is not directly writable.

Originally Posted by Stskeeps

The image would maybe have ability to do something like http://www.slashgear.com/gallery/dat...mp-photo10.png .

Wow, images :-) That's a lot of work.

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.

__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Quote & Reply |

The Following 5 Users Say Thank You to fanoush For This Useful Post:
b-man, Bundyo, Naranek, qwerty12, timsamoff

	Stskeeps	2008-08-11 , 10:25
	Posts: 1,671 \| Thanked: 11,478 times \| Joined on Jun 2008 @ Warsaw, Poland	#5

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.

Quote & Reply |

	Stskeeps	2008-08-18 , 07:16
	Posts: 1,671 \| Thanked: 11,478 times \| Joined on Jun 2008 @ Warsaw, Poland	#6

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)

Quote & Reply |

fanoush	2008-08-18 , 07:53
Posts: 2,152 \| Thanked: 1,490 times \| Joined on Jan 2006 @ Czech Republic	#7

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)

Quote & Reply |

	Stskeeps	2008-08-18 , 08:22
	Posts: 1,671 \| Thanked: 11,478 times \| Joined on Jun 2008 @ Warsaw, Poland	#8

Originally Posted by fanoush

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.

It's set in set_default_root_params in linuxrc - Basically the use of rootfs as the place for boot menu is "best effort" -it's either that or store it in initfs and flash every time on <Diablo systems. It's true that there's some issues if some other rootfs is in internal flash - but these can just as well contain a /etc/bootmenu.d that supporting tools may put stuff into. I would -much rather- prefer to store in initfs (without reflashing) or CAL (too little space), but this doesn't seem easily achievable on non-Diablo systems.

Also with reflashing rootfs in internal flash you'd loose such menu even if the rest of the systems on mmc is fine.

Well, there's always the possibility to have a mmc partition with boot information and such but that just complicates matters..

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?

Well, the idea of linuxrc is that it's a script that runs inside the initfs, that performs the pivot_root and all the other needed stuff - whereas /sbin/init is run inside the pivot root / on the rootfs. Though - I can't imagine why people would have _LINUXRC=yes for systems that doesn't have linuxrc. I'd much rather want it to fall back to menu than try to start up /sbin/init on it's own if linuxrc fails

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"

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)

In my "first attempt" at a linuxrc for Deblet, I do many of the things needed to boot a proper system atleast - I don't really want it to load wifi module for instance as we just remove it later. I do however tell dsme that rootfs is mounted and such though.

Thanks for the constructive comments - I'll see what I can do to make the patch a little more sane.

Quote & Reply |

fanoush	2008-08-18 , 09:05
Posts: 2,152 \| Thanked: 1,490 times \| Joined on Jan 2006 @ Czech Republic	#9

Originally Posted by Stskeeps

It's set in set_default_root_params in linuxrc - Basically the use of rootfs as the place for boot menu is "best effort" -it's either that or store it in initfs and flash every time on <Diablo systems. It's true that there's some issues if some other rootfs is in internal flash - but these can just as well contain a /etc/bootmenu.d that supporting tools may put stuff into. I would -much rather- prefer to store in initfs (without reflashing) or CAL (too little space), but this doesn't seem easily achievable on non-Diablo systems.

I am worried that such "best effort" is not good enough. It adds complexity and fragility without solving the problem completely. Merging multiple items is great idea but we should keep it in initfs or elsewhere except any random (where random is /dev/mtdblock4 for you) rootfs. Well at least this should be configurable so people can set it to first FAT partition on internal card or something like that. But this adds problems with unknown filesystem, additional complexity of configuring this (by users) etc.

Originally Posted by Stskeeps

Well, there's always the possibility to have a mmc partition with boot information and such but that just complicates matters..

exactly :-)

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.

Originally Posted by Stskeeps

Well, the idea of linuxrc is that it's a script that runs inside the initfs, that performs the pivot_root and all the other needed stuff - whereas /sbin/init is run inside the pivot root / on the rootfs.

Oh, I see the difference now. So basically you finetune that linuxrc yourself for specific system and its purpose is to replace nokia /linuxrc and do the pivot_root and tablet specific magic yourself. Got it. That sounds useful and solves the issue of what exactly should be initialized for specific system by not trying to solve it at all :-)

Quote & Reply |

	Stskeeps	2008-08-18 , 12:05
	Posts: 1,671 \| Thanked: 11,478 times \| Joined on Jun 2008 @ Warsaw, Poland	#10

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)

Quote & Reply |

Page 1 of 2

Next >

Active Topics

Firefox with Leste (6)