On Sat, 30 Oct 2004 19:22:32 +0200, website <[EMAIL PROTECTED]> wrote: > On Saturday 30 October 2004 17:47, Luis M wrote: <snip> > > * Go into "super silent" mode where fbsplash/debsplash would NEVER <snip> > Please contact the developers before send a message like this to the ml. > How you must know, this "super-silent-mode" exists. It is done by a line in > the config file.
Uh? Who? I'm sorry. Don't see why. We need people to help; and the only way we can do this is by creating some interest. Letting others know what we are doing makes this possible. I didn't know super-silent is there. I have yet to find this. I read the whole kernel patch and didn't see it. In line 46 of the patch: (fbsplash-0.9-r6-2.6.8.1.diff) +Kernel command line parameters +------------------------------ + +Framebuffer splash can be configured from the kernel command line by passing +options in the following way: "splash=option1,option2". + +The following options are recognized: + +off - do not enable fbsplash after fbcon initialization; this is + default behaviour +verbose - switch fbsplash to verbose mode after fbcon is initialized +silent - switch fbsplash to silent mode after fbcon is initialized + +theme:<name> - use theme 'name' on the first console, default theme name + is 'default' (who'd have guessed?) + +Example - you want to get verbose splash with the theme 'tux' right after +fbcon is up: + splash=verbose,theme:tux + +The userspace helper Then in line 1220-1: + (fbsplash_mode == FB_SPLASH_MODE_SILENT) ? "s" : "v", + vc_cons[vc].d->vc_splash.theme, Essentially only two args: verbose and silent. Silent does not work for all systems. It always goes into verbose mode for me and for others. We need to make this "supersilent" for these systems. And that might mean patching the patch :-) <snip> > And not, it is fake. we are in 4! > Me, you, Glyn and Mattew fake == false ? Well, so far Matt and I have been in #debsplash for many days... (and yes you were away in vacation.) I get your point nonetheless. > > The goal is to get this working with progressbar and all the initrc > > stuff needed. Hopefully we won't need to patch any Debian inirc > > scripts (like it used to be the case with buggy bootsplash). > > > Why do this? > fbsplash is designed to work with the newest initramfs images. I mean by initrc: /etc/init.d and /etc/rc*; and not /sbin/init or any other binaries (just to be clear). So, the goal should be to NOT patch or modify any of the existing debian rc's. I know that for bootsplash this was needed, and perhaps it would be easier for us to patch them than to write a patch that handles this better. As an example of what I mean, this is one way that this can definitely work: 1. admin downloads debsplash-utils and kernel-patch-debsplash 2. admin downloads kernel sources from kernel.org or debian's kernel-source-* packages 3. admin re-compiles kernel after patching it with almost the same .config file (copied from /boot/config-* or /proc/config.gz) and a "make oldconfig" that's done by make-kpkg for you (or my own interactive make-kpkg.sh for those who don't know much about how this works; or don't care to know) 4. admin enables bootlogd in /etc/default/bootlog 5. admin generate initramfs with debsplash-utils 6. admin edits grub/lilo configuration files to pass the needed initrd and kernel arguments to the kernel at boot time 7. reboots What should happen then is: 1. system goes into supersilent mode with progressbar 2. debsplash takes over the screen (graphical mode) and it reads /var/log/boot for current state of the boot progress. Then it updates the progressbar accordingly. 3. if fsck is detected in boot log, then it creates another smaller progressbar clearly label (System checking drive N). And it will do this for all other fsck processes recursively 4. If at any point user gets desperate and hits F2, he/she will be drop in the standard "verbose" mode So, as you can see. There are ways to NOT patch the existing initrc scripts from the debian init.d dir. We should do this. If this method doesn't work, for whatever reason, then we must modify the patch so that it reads this /var/log/boot file itself and "prints" something in a file we can read /proc/debsplash /dev/debsplash, or any other special file. You name it. <snip> > It is fake again. To implements it we need to hack the standard init process Not true. Refer to my arguments above. There is NO need to change the initrc scripts. Perhaps only to introduce a new one that will need to go in /etc/rcS.d with a very early number (but not too early). And this will update our progressbar as needed. > > whatever we do to it will be passed on upstream (they are working > > closely with us). gensplash code and build system is UGLY. > > Yes it should be "ugly" but remember that without gensplash, debsplash is > nothing Hey, i'm not being ungrateful here :-) I'm glad spock took time to port bootsplash. We have been talking about this for months, we never got the process started. For one, I'm not a "kernel hacker" and I'm mostly a GUI/C++ guy who happens to like simplicity (yes, I'm a Mac user too; in case somebody says: get a mac). However, if I need to learn about how the kernel works, then I will. And using gensplash as a starting point is not bad. However, after being coding in C for some time (in many other projects that I'm currently involve). I see the ugliness of the current fbsplash kernel patch. I'll do my best to make it clean, simple and feature rich. > > I'm doing > > my best to use -dev packages from Debian and clean up the code as much > > as possible. -- ----)(----- Luis M System Administrator LatinoMixed.com "We think basically you watch television to turn your brain off, and you work on your computer when you want to turn your brain on" -- Steve Jobs in an interview for MacWorld Magazine 2004-Feb No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html
