maemo.org - Talk - Announce: Open /sbin/preinit (deb package getbootstate)

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - Announce: Open /sbin/preinit (deb package getbootstate) (https://talk.maemo.org/showthread.php?t=80298)

Announce: Open /sbin/preinit (deb package getbootstate)

Hello,

finaly we (Maemo Community) got permission from Quim Gil to modify and redistribute shell script /sbin/preinit for open source projects. See Quim Gil post on https://bugs.maemo.org/show_bug.cgi?id=12228#c9

So it is time to clean and fix bugs in this script...

Now I started creating open replecament for fremantle deb package getbootstate (it contains script /sbin/preinit). Getbootstate binary is already working (see thread: http://talk.maemo.org/showthread.php?t=73792).

I created bzr repository for this package on https://code.launchpad.net/~pali/+ju...o_getbootstate

My primary goal is to add better support for multiboot and customise booting (other) systems.

Anybody is welcome to fixing/developing any parts of getbootstate deb package...

Re: Announce: Open /sbin/preinit (deb package getbootstate)

Quote:

Originally Posted by pali (Post 1127793)

finaly we (Maemo Community) got permission from Quim Gil to modify and redistribute shell script /sbin/preinit for open source projects. See Quim Gil post on https://bugs.maemo.org/show_bug.cgi?id=12228#c9

I would suggest copying the permission statement verbatim in the code's copyright comments (ie don't rely on bugs.maemo.org to remain up indefinitely).

Re: Announce: Open /sbin/preinit (deb package getbootstate)

Ok, permission text copied.

Re: Announce: Open /sbin/preinit (deb package getbootstate)

Continuing the discussion from the recovery console thread on this subject:

Quote:

Originally Posted by Estel (Post 1127725)

Why should it happen later? Isn't it "the earlier, the better"? any drawbacks of loading it so early?

I think fbcon loading early is completely a non-issue, but some people might not want the shell until later, and would never conceive of using the shell at the earliest moment possible (because at that moment none of the filesystems from the main storage or SD card are really mounted and most of the services aren't running.

I think reinob's solution addresses this just fine, however, in that if we want to implement both an 'early shell' and a 'late shell', early-shell could be by itself, and a late shell with more services launched and processes running can be an option within the menu, and people could enable one or both in the settings.

Quote:

Originally Posted by vi_ (Post 1127745)

Maybe even::

Code:

If camera slide open

          load fbcon

          present menu



else 

          boot normaly

Actually, any hardware 'switch' should work... Keyboard, camera slide, maybe even camera button.

I would think some hardware switch should be programmed in, but the settings paradigm suggested by reinob should be there too.

Reason being, some of us love to see that beautiful scrolling console text at boot (I think you sympathize, vi_) - and I don't want to swipe the camera slide or keyboard open or hold down some button every single boot just to get it.

At the same time, we want people with an almost-not-booting N900 who didn't enable the console/shell/menu in advance to be able to access it - so the logic should probably be:

Code:

if [hardware-switch-of-choice-detected] || [settings file asks for console and shell]

present console and optionally shell/menu

else

boot normally

Re: Announce: Open /sbin/preinit (deb package getbootstate)

Nice ideas - please just remember about multiboots users (I'm looking @ reinob suggestion about using bootmenu). I think we should prepare solution, that works for everyone - depending of options from config - and not depending on certain later-boot setup (bootmenu, multiboot, uboot, whatever).

/Estel

Re: Announce: Open /sbin/preinit (deb package getbootstate)

@Estel,

AFAIK multiboot is "just another preinit", so in a perfect world multiboot would be an add-on to the new and improved preinit.

So, NOLO -> [u-boot] -> kernel -> preinit -> [if configured] multiboot
and then [if maemo] -> maemo-specific preinit, with option for bootmenu

backupmenu-like could be integrated into this new multiboot, or with the maemo-specific bootmenu.

[ADD: everything can be implemented, relatively easily. All I can do now is throw ideas. Someday I might implement them. ]

Re: Announce: Open /sbin/preinit (deb package getbootstate)

Here is a head scratcher for you.

How do you remove fbcon before entering BM? As you know fbcon makes it nearly impossible to use BM due to the text on the screen.

adding 'rmmod fbcon' fails as the module is in use. I suppose you could rmmod -f fbcon (force) however I don't want to try that on my only n900 with the prospect of a reflash if it failz.

Re: Announce: Open /sbin/preinit (deb package getbootstate)

@vi_

Before rmmod'ing fbcon you have to deattach the console. Not sure how (chvt 2?).

But at least in my "plan" any menu (backupmenu, multiboot, bootmenu) and obviously the console will be strictly text-mode (framebuffer).

If you read the backupmenu script you'll see it's a huge mess due to all the text2screen calls and updating the cursor position. That's messy, and hides the actual functionality.

I would do backupmenu (as well as bootmenu) with a compiled C program (using slang or ncurses). Quick, self-contained (even statically compiled if needed) and with that "native" text-mode look we all love :)

Re: Announce: Open /sbin/preinit (deb package getbootstate)

Quote:

Originally Posted by vi_ (Post 1128338)

why not simply stop using the nokia binary text2screen and use prinf to show text on the screen properly when using fbcon ?

of course printf will show nothing for people who don't have fbcon inserted/built in, to overcome this the script can be modified to check whether fbcon is present at start, if it is then use printf to print text to screen, if it isn't then use text2screen.

Re: Announce: Open /sbin/preinit (deb package getbootstate)

Because I did not write BM. I am not going to re-write BM because your principles dictate text2screen sucks balls. I just want to know how to safely remove the module is all.