Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 7 hrs, 8 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 11 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 23 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 23 hrs ago - more...
| The Following 5 Users Say Thank You to Stskeeps For This Useful Post: | ||
|
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?
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.
Promises are like babies. Fun to make, but hard to deliver.
Warning: dates on calendar are closer than they appear.
 |
|
2008-08-10
, 20:06
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#3
|
Originally Posted by josiahg777
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
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?
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
|
|
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
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.
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.
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
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?
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)
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
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.
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.
Originally Posted by Stskeeps
Wow, images :-) That's a lot of work.
The image would maybe have ability to do something like http://www.slashgear.com/gallery/dat...mp-photo10.png .
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.
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.
|
|
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.
i investigated cal-tool -set-root-device for this but it can at most contain about 100 byte. Dunno if thats enough.
|
|
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)
* 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)
|
|
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)
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)
__________________
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.
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.
|
|
2008-08-18
, 08:22
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#8
|
Originally Posted by fanoush
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 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?
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)
Thanks for the constructive comments - I'll see what I can do to make the patch a little more sane.
|
|
2008-08-18
, 09:05
|
|
Posts: 2,152 |
Thanked: 1,490 times |
Joined on Jan 2006
@ Czech Republic
|
#9
|
Originally Posted by Stskeeps
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.
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.
Originally Posted by Stskeeps
exactly :-)
Well, there's always the possibility to have a mmc partition with boot information and such but that just complicates matters..
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
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 :-)
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.
__________________
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.
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.
|
|
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)
* 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)
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.