Bfff.. lots of things going on in this thread (LIKE

First things first: @Estel, Thanks for pointing me to Backupmenu. I saw that it does "hwclock -s" (set system time from hardware clock).

Then I saw vi_'s post mentioning the same. Thanks to you too. Now I'm charging the N900 so I won't touch it, but I'll try later adding "hwclock -s" to the /recovery.sh.

Second: @Pali: YES, please proceed It's a great feeling to see other (more knowledgeable) people wanting to do the same as I want to do.

This way I don't have to rush things, so I'll patiently wait for your combined results and profit from them (of course if there's anything I can patch I will

In short: thanks to everyone involved in this thread. I start feeling like in the early 90s when I installed Slackware 1.0 (or was it 2.0?).

UPDATE!

I booted to the recovery console. 'date' shows incorrect date/time, but 'hwclock -r' shows correct time

Did 'hwclock -s' and then exit (poweroff). Booted to Maemo and voilà! date and time are OK!

[EDIT] I've added 'hwclock -s' in recovery.sh, right after loadkmap.

Next in line: keyboard mapping. But I need to do this at home (loadkeys -b and all).

GJ bro'ski.

Here is /sbin/preinit.

I have put modprobe fbcon after the first function to be called, 'init_system'.

This calls it even earlier for even more rolling text at boot up. I have not got the balls to try it before 'init_system' as if I ballsax my system I could not face re-flashing this beast again.

Another interesting effect is the display of the green R&D mode text. If you look in the link you can call the display text without actually starting R&D mode. KInda cool if you want it but not rolling fbcon text.

I started fixing and cleaning /sbin/preinit. Now I created deb package getbootstate which should be (in future) replecament for original nokia's.

Source code here: https://code.launchpad.net/~pali/+ju...o_getbootstate

Note that: I did not tested it yet

Ugh, I'd still rather recode /sbin/preinit personally (reasons mentioned elsewhere, plus the principle of the thing), but I suppose working with you guys on this one will get me more experienced with its workings to the point where I can validly say I can 'clone' it without directly copying.

ANYWAY - rambling aside... I'm happy to jump on to pali's /sbin/preinit for development purposes, although I would love if it still let users start a root shell at the earliest moment possible, like mine more or less does now. I kinda like the idea of an internalized menu, but I am weary of feature bloat. /sbin/preinit is horribly delicate, so the more complex it gets the more likely it'll be that one missed error will screw up the boot process, etc. So we MAY want, if we're going to add a menu fancier than to add the extra functions in separate scripts, which are only called from within /sbin/prenit, and only AFTER some user-generated action.

(I suspect people won't want to, in the long run, to add the fbcon loading and shell prompt where I have it in my version, within init_system(), so I won't push for that too much myself unless enough other people think having such an extremely-early fallback is a good idea.)

If you look at my code when I first showed how to add fbcon and a press-key-to-get-shell prompt on page two or three of this thread, you can see it's almost at the very beginning of init_system() for me, I have it right afterNot much earlier to go than that. However, if you think none of those directories/filesystems are needed for busybox-power to run a shell properly from framebuffer console, then I'm willing to risk making it the VERY FIRST THING (TM) executed in the script, and see what happens.

Oh, I thought the tech savvy people who would care already knew this, since I always think of myself a newb in these matters. Otherwise I would've reported that months ago.

I do like my code so far though for a simple shell prompt, and if someone just wrote some if/then checks to see if the kernel was a power kernel version with fbcon built-in as a loadable module, and that the required command line tools and files were all available where indicated in the code, then it could be stuck inside the /sbin/preinit on pali's repo.

In the long term, we'd probably want a settings option somewhere (maybe even CAL area if/when that's reverse-engineered properly) since if this is going to be a replacement package for getbootstate we'd probably want there to be some way to enable the shell and/or possibly-built-in-menu as a settings option. That way, the feature can be built-in to /sbin/preinit so that it's there as a safety option, but doesn't have to run by default.

P.S. Pali, I subscribed myself to that launchpad branch of open source getbootstate you have.

@Mentalist Traceur and @Pali and @others,

Perhaps a simple solution would be to store a config file in / or /etc (/preinit.cfg or so) where one could set the option of FBCON (FBCON=early, FBCON=normal, FBCON=no) plus another option for EARLY_CONSOLE=(yes,no,ask) [ "ask" would enable @Mentalist Traceur's timed selection).

Another option would be "BOOTMENU", either empty or pointing to a file (/bootmenu.sh), so that preinit would only check that option and if non-empty and file exists and file is executable (so that it's easily disabled) then it would run it.

This way preinit (stock or Pali's) would only need a few extra lines but the added functionallity would be implemented elsewhere (and easily enabled/disabled).

As long as the new preinit throughly checks things one could almost guarantee that there would be no reboot loops (at least caused by preinit).

For the long term I would go for a full runlevel implementation, so that you can have your single-user, multi-user-no-X, multi-user-networking, etc.

BTW /sbin/init is an ELF binary. Is the source code available?

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

Maybe even::

?