[gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

Hi,

I'm not sure i'm using the right list to expose that kind of problem.
Sorry for the inconvenient. Anyway, here i'm.

I'm using gensplash during the earlier boot process (initramfs) and
before switching to the real root partition (switch_root).
It behaves normally in silent mode, i mean i have the gentoo logo, the
alt+F1 message and the vertical purple bar on the screen, right after
the framebuffer (radeonfb) and vtcon are both activated.
But issuing alt+F1 and switching to the verbose mode doesn't give me the
vertical purple bar and therefore i'm not able to switch back in silent
mode again. Alt+F1 key seems to become inactive. Also, both files
/etc/splash/livecd-2006.1/images/{verbose,background}-1280x1024.png are
present in the cpio archive file and like genkernel, i'm using
splash_helper and the initrd.splash script (splash_utils.static is
really to huge to be used).

My questions are: are there any other useful "hidden" options available
with splash_helper like "repaint" to help gentoo to switch in silent
mode by pressing alt+F1 again ?
How should i call the verbose-xx.png image or any scripts in order to
see the right vertical bar on the screen knowing i have only busybox,
splash_helper, /dev, /sys and /proc available at that stage?

Thank you for your suggestions

Jj

-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Daniel Drake]

Jimmy Jazz wrote:
> I'm using gensplash during the earlier boot process (initramfs) and
> before switching to the real root partition (switch_root).
> It behaves normally in silent mode, i mean i have the gentoo logo, the
> alt+F1 message and the vertical purple bar on the screen, right after
> the framebuffer (radeonfb) and vtcon are both activated.
> But issuing alt+F1 and switching to the verbose mode doesn't give me the
> vertical purple bar and therefore i'm not able to switch back in silent
> mode again. Alt+F1 key seems to become inactive.

I think F2 is the keypress you are looking for.

Daniel
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

Daniel Drake a écrit :
> Jimmy Jazz wrote:
>> I'm using gensplash during the earlier boot process (initramfs) and
>> before switching to the real root partition (switch_root).
>> It behaves normally in silent mode, i mean i have the gentoo logo, the
>> alt+F1 message and the vertical purple bar on the screen, right after
>> the framebuffer (radeonfb) and vtcon are both activated.
>> But issuing alt+F1 and switching to the verbose mode doesn't give me the
>> vertical purple bar and therefore i'm not able to switch back in silent
>> mode again. Alt+F1 key seems to become inactive.
> 
> I think F2 is the keypress you are looking for.
> 
> Daniel

Thank you for your reply.

If i understood well F2 is managed from splash_util not splash_helper.
Also, my config isn't really gentoo compliant (i don't use genkernel)
and i would avoid the need of splash_util.static. I'm loading
splash_helper from bzImage via initramfs archive to do the job. At this
stage the alt+F1 key gives me the ability to switch to the verbose mode,
have a look at the display to see what is going on (i'm kind of curious
:) and switch back to the silent mode like i'm able with splash_util.
The problem is, i cannot switch back to the silent mode until
splash_util is loaded. I could say, the key Alt+F1 is not
"bidirectional", in other words the display cannot go back to the
precedent mode.

Why should i need that ? In fact, i'm loading all the drivers as module
and the process takes more time to be performed as it is if the drivers
were compiled directly in the kernel or called from /sbin/rc script.

The second issue is, i'm no more able to see the purple vertical bar at
the right of the screen during the verbose mode. The screen only looks
like as an usual tty. I'm quite sure, it was possible in the past.

PS: I have tried splashutils 1.4 but it doesn't work for me. The screen
stays black... until i press alt+f1 or F2. At first, i thought that
could be the radeonfb driver, but it seems not. I didn't take too much
time to look after it and i switched back to splashutils 1.3.1 for the
moment.

Jj
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Daniel Drake]

Jimmy Jazz wrote:
> If i understood well F2 is managed from splash_util not splash_helper.

Indeed. splash_util listens for input events, but splash_helper does 
not. The only reason that splash_helper appears to respond to Alt+F1 is 
that that particular keypress is handled by the kernel as "change to 
terminal 1". If you could find a way to change back to terminal 16 
(which is where splash_helper draws its pretty graphics), you'd be away. 
Maybe it's possible to use (e.g.) terminal 8 instead, in which case you 
could use Alt+F8.

> The second issue is, i'm no more able to see the purple vertical bar at
> the right of the screen during the verbose mode. The screen only looks
> like as an usual tty. I'm quite sure, it was possible in the past.

I may be wrong, but I think splash_util is required for drawing the 
progress bar -- I don't think splash_helper can do that.

> PS: I have tried splashutils 1.4 but it doesn't work for me. The screen
> stays black... until i press alt+f1 or F2. At first, i thought that
> could be the radeonfb driver, but it seems not. I didn't take too much
> time to look after it and i switched back to splashutils 1.3.1 for the
> moment.

Probably needs some extra testing with baselayout-1.x. This release was 
primarily for the baselayout-2 splash plugin, which does work fine on 
baselayout-2 (entering portage soon).

Daniel

-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

Daniel Drake a écrit :
> Jimmy Jazz wrote:
>> If i understood well F2 is managed from splash_util not splash_helper.
>
> Indeed. splash_util listens for input events, but splash_helper does
> not. The only reason that splash_helper appears to respond to Alt+F1
> is that that particular keypress is handled by the kernel as "change
> to terminal 1". If you could find a way to change back to terminal 16
> (which is where splash_helper draws its pretty graphics), you'd be
> away. Maybe it's possible to use (e.g.) terminal 8 instead, in which
> case you could use Alt+F8.
>
Stupid me ! I didn't thought about that :). Perhaps chvt will do it
quite easily.

>> The second issue is, i'm no more able to see the purple vertical bar at
>> the right of the screen during the verbose mode. The screen only looks
>> like as an usual tty. I'm quite sure, it was possible in the past.
>
> I may be wrong, but I think splash_util is required for drawing the
> progress bar -- I don't think splash_helper can do that.

I will try splash_util and look if it doesn't overvalue my needs.
Indeed, bzImage doesn't become too huge.
>
>> PS: I have tried splashutils 1.4 but it doesn't work for me. The screen
>> stays black... until i press alt+f1 or F2. At first, i thought that
>> could be the radeonfb driver, but it seems not. I didn't take too much
>> time to look after it and i switched back to splashutils 1.3.1 for the
>> moment.
>
> Probably needs some extra testing with baselayout-1.x. This release
> was primarily for the baselayout-2 splash plugin, which does work fine
> on baselayout-2 (entering portage soon).
>
> Daniel
>
I'm eager to see the new features of baselayout-2 :)

Thanks for your explanations. 

Jj


-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Michal Januszewski]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

> If i understood well F2 is managed from splash_util not splash_helper.
> Also, my config isn't really gentoo compliant (i don't use genkernel)
> and i would avoid the need of splash_util.static. I'm loading
> splash_helper from bzImage via initramfs archive to do the job. At this
> stage the alt+F1 key gives me the ability to switch to the verbose mode,
> have a look at the display to see what is going on (i'm kind of curious
> :) and switch back to the silent mode like i'm able with splash_util.
> The problem is, i cannot switch back to the silent mode until
> splash_util is loaded. I could say, the key Alt+F1 is not
> "bidirectional", in other words the display cannot go back to the
> precedent mode.

Alt+F1 was never meant to be bidirectional -- it's the usual key
combination to switch to tty1 (Alt+F2 to tty2, Alt+F3 to tty3 etc).
Switching back to verbose during early userspace is currently
unsupported. If you need it really badly, let me know and I'll see
whether I can hack a simple solution for it.
 
> The second issue is, i'm no more able to see the purple vertical bar at
> the right of the screen during the verbose mode. The screen only looks
> like as an usual tty. I'm quite sure, it was possible in the past.

Is the verbose mode activated at a later time? Are you sure you have
compiled splashutils with fbsplash-support enabled?
 
> PS: I have tried splashutils 1.4 but it doesn't work for me. The screen
> stays black... until i press alt+f1 or F2. At first, i thought that
> could be the radeonfb driver, but it seems not. I didn't take too much
> time to look after it and i switched back to splashutils 1.3.1 for the
> moment.

That could be either a bug in splashutils or a problem with how you're
building your initramfs image. Could you provide some more details about
how it is created?

Best regards.
-- 
Michal Januszewski                              JID: spock@im.gentoo.org
Gentoo Linux Developer                    http://people.gentoo.org/spock


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Michal Januszewski]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Tue, Apr 10, 2007 at 06:53:45PM +0200, Jimmy Jazz wrote:
 
> I will try splash_util and look if it doesn't overvalue my needs.
> Indeed, bzImage doesn't become too huge.

splash_util, being dynamically linked, won't work from an initramfs unless
you're willing to include glibc, libpng, freetype2 etc with it. And that 
_will_ make the image huge :)

Best regards.
-- 
Michal Januszewski                              JID: spock@im.gentoo.org
Gentoo Linux Developer                    http://people.gentoo.org/spock


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

Hi,

Michal Januszewski a écrit :
>
> Alt+F1 was never meant to be bidirectional -- it's the usual key
> combination to switch to tty1 (Alt+F2 to tty2, Alt+F3 to tty3 etc).
> Switching back to verbose during early userspace is currently
> unsupported. If you need it really badly, let me know and I'll see
> whether I can hack a simple solution for it.
I'm really sorry for my late reply. Your mail get lost in my spam filter :(
Really your soft is great and doesn't need an hack for me :)

> Is the verbose mode activated at a later time? 
I'm not sure i understand well , but yes it is activated when i press
the F2 key.  I have just added the following,

root=/dev/md/d0p2 splash=silent,theme:livecd-2007.0 quiet CONSOLE=/dev/tty1

at the command line.

F2 is of course bidirectional.
> Are you sure you have compiled splashutils with fbsplash-support enabled?
>   
No alas, since my kernel is now "full modular" (even vtcon and fb). It works well. As soon as readeonfb and vtcon are loaded, the splash screen appears on the display (the one with the alt-F1 comment of course). I get even more "visible" memory for free than before. Also, i tried to activate fbsplash support in the kernel as well with a little hack in Kconfig (depends on FRAMEBUFFER_CONSOLE && !FB_TILEBLITTING). With or without modules i couldn't compile the kernel. That's why i'm still using media-gfx/splashutils-1.3.1. For example, con2fb_map is not found by the "linker".

Just a comment about how you built fbsplash. 
Why not include splash_helper code directly in a kernel module, instead to call /sbin/splash_helper ?


> That could be either a bug in splashutils or a problem with how you're
> building your initramfs image. Could you provide some more details about
> how it is created?
>   
I'm using initramfs but without the initrd /initramfs-xx line. That
means i need a simple file
CONFIG_INITRAMFS_SOURCE="/usr/src/initramfs-2.6.22-rc3.lst" to configure
the initramfs filesystem and the init file calls switch_root from
busybox to switch to the real root filesystem. The initramfs is directly
in the "kernel" file.

I didn't use /sbin/splash_util.static at all during the boot process. I
wasn't able to implement it very well and got many freezes. I didn't
find out what was going on :( Perhaps some problems with the pipe file
!? If i get more time i will investigate it.

Also, i just declared the following lines:

[..]
# init script
file /init /usr/src/initramfs-2.6.22-rc3.skel/init 0755 0 0
file /etc/color-settings
/usr/src/initramfs-2.6.22-rc3.skel/etc/color-settings 0755 0 0
file /etc/initrd.splash
/usr/src/initramfs-2.6.22-rc3.skel/etc/initrd.splash 755 0 0

# splash screen
dir /etc/splash 0755 0 0
dir /etc/splash/livecd-2007.0 0755 0 0
dir /etc/splash/livecd-2007.0/images 0755 0 0
file /sbin/splash_helper /sbin/splash_helper 755 0 0
#file /sbin/splash_util.static /sbin/splash_util.static 755 0 0
file /etc/splash/livecd-2007.0/Vera.ttf
/etc/splash/livecd-2007.0/Vera.ttf 644 0 0
file /etc/splash/livecd-2007.0/1280x1024.cfg
/etc/splash/livecd-2007.0/1280x1024.cfg 644 0 0
file /etc/splash/livecd-2007.0/images/background-1280x1024.png
/etc/splash/livecd-2007.0/images/background-1280x1024.png 644 0 0
file /etc/splash/livecd-2007.0/images/overlay-1024.png
/etc/splash/livecd-2007.0/images/overlay-1024.png 644 0 0
file /etc/splash/livecd-2007.0/images/verbose-1280x1024.png
/etc/splash/livecd-2007.0/images/verbose-1280x1024.png 644 0 0
[..]

initrd.splash is the file you find in splashutils

With splashutils 1.3.1 everything is working well except the icons.
Indeed, xdm icon appears every now and then and hides the other icons.
Certainly, due to the fact 1.3.1 splashutils release doesn't support
livecd-2007.0 .

If you accept suggestions, i emit this one : It would be great if
fbsplash could be loaded as a module and would accept vtcon and fb as
modules too :)

If you need more information about the messages returned by the kernel
during compilation time, just let me know.


Thank you for your help,

Jj



-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

Michal Januszewski a écrit :
> On Tue, Apr 10, 2007 at 06:53:45PM +0200, Jimmy Jazz wrote:
>  
>   
>> I will try splash_util and look if it doesn't overvalue my needs.
>> Indeed, bzImage doesn't become too huge.
>>     
>
> splash_util, being dynamically linked, won't work from an initramfs unless
> you're willing to include glibc, libpng, freetype2 etc with it. And that 
> _will_ make the image huge :)
>
> Best regards.
>   
hello,

You are right, but that doesn't matter  if you are using initramfs into
the kernel file instead initrd (My kernel is just 5Mo huge). With the
switch_root command you will have the full memory back again :). In
fact, i didn't implement splash_util into the cpio file because of some
freezes and lack of time :)

Anyway, i tried to compile splashutils-1.4.2 without success. It seems
we are now unable to use it without the kernel patch which also i cannot
install :(

[code]
You can run `make` now.
  CC      objs/solibsplash.o
  LD      objs/libsplash.so
  CONF    libjpeg
  MAKE    libjpeg
  CONF    freetype2
  MAKE    freetype2
  CONF    zlib
  MAKE    zlib
  CONF    libpng
  MAKE    libpng
  CC      objs/kernel/kernel.o
kernel.c: In function ‘handle_init’:
kernel.c:96: erreur: ‘FB_SPLASH_IO_ORIG_USER’ undeclared (first use in
this function)
kernel.c:96: erreur: (Each undeclared identifier is reported only once
kernel.c:96: erreur: for each function it appears in.)
kernel.c: In function ‘main’:
kernel.c:262: erreur: ‘FB_SPLASH_IO_ORIG_KERNEL’ undeclared (first use
in this function)
make: *** [objs/kernel/kernel.o] Erreur 1
[/code]


Have you dropped the 100% gensplash userspace solution ? why ? :cry:

Jj



[-- Attachment #2: Type: text/html, Size: 2338 bytes --]

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Michal Januszewski]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

> Anyway, i tried to compile splashutils-1.4.2 without success. It seems
> we are now unable to use it without the kernel patch which also i cannot
> install :(
> 
> [code]
>   CC      objs/kernel/kernel.o
> kernel.c: In function ‘handle_init’:
> kernel.c:96: erreur: ‘FB_SPLASH_IO_ORIG_USER’ undeclared (first use in
> this function)
> kernel.c:96: erreur: (Each undeclared identifier is reported only once
> kernel.c:96: erreur: for each function it appears in.)
> kernel.c: In function ‘main’:
> kernel.c:262: erreur: ‘FB_SPLASH_IO_ORIG_KERNEL’ undeclared (first use
> in this function)
> make: *** [objs/kernel/kernel.o] Erreur 1
> [/code]

> Have you dropped the 100% gensplash userspace solution ? why ? :cry:

No, I haven't. Are you sure your klibc is built against a clean tree
that hasn't been patched with splash? 

You might want to check for the presence of the following file:

/usr/lib/klibc/include/linux/console_splash.h

If it's not there, you should get a warning about missing fbsplash
when merging splashutils. If you get the warning and it still fails to
compile, then I have a bug to fix :)

Best regards.
-- 
Michal Januszewski                              JID: spock@im.gentoo.org
Gentoo Linux Developer                    http://people.gentoo.org/spock


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Michal Januszewski]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

On Thu, May 31, 2007 at 05:23:56PM +0200, Jimmy Jazz wrote:

Hi,

> > Are you sure you have compiled splashutils with fbsplash-support enabled?
> >   
> No alas, since my kernel is now "full modular" (even vtcon and fb). It works well. 
> As soon as readeonfb and vtcon are loaded, the splash screen appears on the 
> display (the one with the alt-F1 comment of course). I get even more 
> "visible" memory for free than before. Also, i tried to activate fbsplash
>  support in the kernel as well with a little hack in Kconfig (depends on 
> FRAMEBUFFER_CONSOLE && !FB_TILEBLITTING). With or without modules i 
> couldn't compile the kernel. That's why i'm still using 
> media-gfx/splashutils-1.3.1. For example, con2fb_map is not found by 
> the "linker".

Fbsplash doesn't work as a module, it can only be used when fbcon is
compiled into the kernel. 
 
> Just a comment about how you built fbsplash. 
> Why not include splash_helper code directly in a kernel module, instead to 
> call /sbin/splash_helper ?

If you want to have splash_helper's functionality _inside_ the kernel,
just use bootsplash. Putting userspace stuff, like JPEG and PNG
decoders, where it belongs (i.e. userspace) was the most fundamental 
design idea behind splashutils :)
 
> I didn't use /sbin/splash_util.static at all during the boot process. I
> wasn't able to implement it very well and got many freezes. I didn't
> find out what was going on :( Perhaps some problems with the pipe file
> !? If i get more time i will investigate it.

Perhaps, but putting it inside an initramfs isn't a very good idea. It
would be better to aim for a very fast boot during the early-userspace
stage and to let the splash daemon be started the normal way (i.e. by
the Gentoo baselayout scripts).
 
> With splashutils 1.3.1 everything is working well except the icons.
> Indeed, xdm icon appears every now and then and hides the other icons.
> Certainly, due to the fact 1.3.1 splashutils release doesn't support
> livecd-2007.0 .

Right, that's a problem with how anims are handled in 1.3.1 and it's
indeed fixed in 1.4.2.
 
> If you accept suggestions, i emit this one : It would be great if
> fbsplash could be loaded as a module and would accept vtcon and fb as
> modules too :)

I'll keep that in mind and maybe implement it when I have some more free
time.

Have you had a chance to try splashutils 1.4.2 with baselayout-2*? If
so, did it fix the missing-splash-screen problem?

Best regards.
-- 
Michal Januszewski                              JID: spock@im.gentoo.org
Gentoo Linux Developer                    http://people.gentoo.org/spock


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

 
Hello Spock,

Sorry for the late reply. It becomes an habit :) Anyway, i was busy to
get the early boot script work with splashutils daemon last week end. I
didn't even have too much time to decipher all the possibilities your
program offers. I certainly missed some features it would offer. Also, i
still encountered many difficulties with the daemon and i would like to
discuss about it with you and perhaps even convince you to bring some
modifications to it.


The idea is: - to get a usable environment, even with music (debugging
could be quite long ;), when you are not able to boot the system anymore
(vi, gpm, alias, lvm, mdsetup, vgscan, fsck etc),- to stay full modular
and also - to support any filesystem you want (reiserfs, etc.) before
you even know anything about your drives. Most everything, i still want
to get the system as simple as possible.

In fact, after customising a configuration file that handles icon and
animation pictures, i begin to get in trouble :)

I need the helper after the daemon has stopped (it has displayed a lot
of nice icons before) and when the script switched to the real root file
system. It hides the console when the script will proceed.

As the helper didn't understand services, all the icons are displayed on
the screen and are scrambled with vertical stripes. To get rid of that,
i need to delete all the icon/anim lines in the configuration file. That
is a pity. Indeed, it would certainly be good to add some more options
to the helper to avoid the script to have to modify the configuration
file every time it calls the helper. Indeed, the file cannot contain
pre-declaration of icon/anim directives. Busybox doesn't understand "sed
-i", so you need a temporary file and your script becomes... more
complicated.

About animations, they are looping quite strangely when any other icons
are declared in the configuration file. They are displayed too, whatever
the services they belong to are.

Anyway, i'm quite satisfied with the result. Ash is strong enough to
handle the job well. The script stays readable :)

I tried to intercept the keyboard keys directly from the script as
gentoo baselayout v1 does (interactive mode) but without much success.
When the silent mode is called from the helper or the daemon, the script
doesn't react to the key i pressed, except the Alt-F1 key managed by the
kernel or the F2 key when called from the daemon.  I tried stty in raw
mode too. I will confess, i didn't remember how ttys are handled by the
kernel and who cares ... until you really need them, especially when you
try to call extra keys like F3 or something similar :)

IMHO, letting the script directly handle the keyboard would help to
simplify all the thing, but how ?

Also, you asked me if i have tried baselayout version 2 with splashutils.

In fact, i will certainly never be able to switch to version 2. It is
written mostly in C (and that is a bad idea ;). It isn't flexible enough
whereas a rc bash will always be. In my case, it won't call the critical
services the kernel will need early enough or even in the right order to
help a mdp/lvm boot disk to mount :(.

Believe me, only scripts are able to save the world !

Jj
-- 

            |\      _,,,---,,_
      ZZZzz /,`.-'`'    -.  ;-;;,_
           |,4-  ) )-,_. ,\ (  `'-'
          '---''(_/--'  `-'\_)


*My Two Cents Comment** *
Large increases in cost with questionable increases in performance can
be tolerated only in race horses and women. -- Lord Kelvin
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Daniel Drake]

Jimmy Jazz wrote:
> In fact, i will certainly never be able to switch to version 2. It is
> written mostly in C (and that is a bad idea ;). It isn't flexible enough
> whereas a rc bash will always be. In my case, it won't call the critical
> services the kernel will need early enough or even in the right order to
> help a mdp/lvm boot disk to mount :(.

I'm not sure what you mean here, can you elaborate?

Are you worried that your kernel might be broken so much that it won't 
be able to execute ELF executables? If so, you'd also be screwed on the 
script approach, because busybox/ash is also written in C.

Daniel
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

Daniel Drake a écrit :

> Are you worried that your kernel might be broken so much that it won't
> be able to execute ELF executables? If so, you'd also be screwed on the
> script approach, because busybox/ash is also written in C.
> 

Sorry if i didn't make myself clear. The fact the kernel runs or not elf
binaries wasn't the idea. You remember me the time i was used to program
in C, i always compiled a simple a.out and tried to debug it with adb
because i misused pointers of pointer and casting in order to optimize
the code because i had less than 64/512ko of ram to reinvent the world
(No, i didn't made all that codes in a garage in my backyard, but they
were lost in a faulty 10Mo MFM harddisk for sure. So ended my brillant
career :). Anyway, a.out format is mostly replaced with elf format nowadays.

Actually, i have spoken about the fact that a program written in a
compiled language will not be as flexible as an interpreted one. In
other word, /sbin/rc should stay a shell script. I'm pretty sure that
will not please to some of you gentoo developers ;)

Jj

-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Daniel Drake]

Jimmy Jazz wrote:
> Actually, i have spoken about the fact that a program written in a
> compiled language will not be as flexible as an interpreted one. In
> other word, /sbin/rc should stay a shell script. I'm pretty sure that
> will not please to some of you gentoo developers ;)

I guess that depends on your ability as a C programmer and your 
definition of 'flexible'. As shell interpreters are typically written in 
C I don't think you can fairly say that you can do things in shell 
script which can't be done in C.

baselayout-2 doesn't drop any features that I know about, actually it 
adds several, and it is much much more reliable than its predecessors. 
It solves all the highly reproducible and extremely difficult to fix 
problems that I had with baselayout-1.

And believe me, I tried to fix them, focusing specifically on the 
concurrency issues. I now believe it is *impossible* to write an 
unbreakable and race-free locking mechanism in shell script, which is 
the only realistic way to avoid some of these bugs.

Daniel

-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Daniel Drake]

Jimmy Jazz wrote:
> Actually, i have spoken about the fact that a program written in a
> compiled language will not be as flexible as an interpreted one. In
> other word, /sbin/rc should stay a shell script. I'm pretty sure that
> will not please to some of you gentoo developers ;)

And unless you are missing some kind of feature from baselayout-2, or 
there is otherwise something that could be done with previous versions 
that is no longer possible, then I don't think you have any real reasons 
(other than political ones) to push off the upgrade...
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

Hello Daniel,

Daniel Drake a écrit :
> I guess that depends on your ability as a C programmer and your 
> definition of 'flexible'. As shell interpreters are typically written 
> in C I don't think you can fairly say that you can do things in shell 
> script which can't be done in C.
>
First, i didn't want to hurt and i'm happy to see you like C but it 
seems you misunderstood me :). C is just more powerful when you talk 
about speed, pointers, functions and procedures. Anyway, C comes from C 
and ... assembler. Assembler is also powerful but not flexible, mostly 
because it depends on the hardware you use. It is difficult to read and 
does not fit for large programs (what about Doom 1 the game ? ;).
Also we could talk about another "command interpreter" like irb. It 
doesn't depend on any platforms or hardwares, it is object-oriented and 
you can program while using it. That's what i call flexible. Of course 
{ba,a,k,c,etc}sh are certainly just enough flexible but obviously not 
powerful. You want more power, you can also write a program in C or in 
whatever language you like and call it from the shell interpreter. As a 
result, you will increase the abilities of your shell.
 
Imagine you lack some functionalities in your script. You just need to 
add them and also rerun the script. Such flexibility is not possible 
with C or Pascal especially if you don't have either libraries or 
compilers.  It is like in the past with a C64 where you could peek and 
poke in basic in a program to  cheat ! with C you have only {a,s}db like 
debugger (it is a little bit more difficult then...) But indeed, a 
script doesn't protect you from syntax errors. In that case you can even 
not call a shell. You need the rescue cdrom  as usual :)
> baselayout-2 doesn't drop any features that I know about, actually it 
> adds several, and it is much much more reliable than its predecessors. 
> It solves all the highly reproducible and extremely difficult to fix 
> problems that I had with baselayout-1.
Sorry, i didn't go into baselayout-2 too deep but you write rc in C and 
that is what i have considered a bad idea. You make approximately 11 
calls to exec(). If something has changed like the name of a program it 
calls, you won't be able to remedy it with ease (and don't tell me: just 
create a link to it ;).

Yes, it is difficult to fix problems with a shell script but sometimes 
that means the script has become too big and it is time to think it 
differently.
I like the ideas in baselayout-1 but unfortunately i didn't have really 
any use of it except the fact i can control the order the daemons are 
loaded. Instead /sbin/functions.sh has helped me a lot to write a script 
that does approximately the same but in ash and with candies too :). I 
actually use it during the earlier boot stage process when disks are 
still not recognized. Also i have integrated a modified 
splash-functions.sh too. It is certainly not universal but it works. I 
hope i will be able to support crypted raid1 boot disk as well in the 
future. Also, it isn't fast nor it doesn't innovate, but above all it is 
aesthetic (in my point of view anyway).
>
> And believe me, I tried to fix them, focusing specifically on the 
> concurrency issues. I now believe it is *impossible* to write an 
> unbreakable and race-free locking mechanism in shell script, which is 
> the only realistic way to avoid some of these bugs.
>
> Daniel

Right, a shell is not what handles the best concurrency issues but 
"wait" and "jobs" have been quite improved. If you have an example i 
could try. Also, that makes life exciting and i cheer you up. I'm sure 
you will succeed and improve gentoo even better :)


| And unless you are missing some kind of feature from baselayout-2, or 
there is otherwise something that could be done with previous
| versions that is no longer possible, then I don't think you have any 
real reasons (other than political ones) to push off the upgrade...

I'm not quite good in politics but i will follow your advice :). I just 
have feared you will definitely drop baselayout-1. (anyway, maintaining 
two different kinds of software that do approximately the same thing is 
a pain). I will need to reconvert sooner or later. Also, we leave in 
really hard time,  everything is moving too fast ;)


Jj
-- 

            |\      _,,,---,,_
      ZZZzz /,`.-'`'    -.  ;-;;,_
           |,4-  ) )-,_. ,\ (  `'-'
          '---''(_/--'  `-'\_)



*My Two Cents Comment** *
"Don't fear the pen. When in doubt, draw a pretty picture." --Baker's 
Third Law of Design.


-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Daniel Drake]

Jimmy Jazz wrote:
> Instead /sbin/functions.sh has helped me a lot to write a script 
> that does approximately the same but in ash and with candies too :)

Now you're making more sense -- you prefer baselayout written in bash 
because you are copying and mangling its code in ways that the 
developers didn't intend. I see.

FYI, baselayout-2 no longer requires bash.

> Right, a shell is not what handles the best concurrency issues but 
> "wait" and "jobs" have been quite improved. If you have an example i 
> could try. Also, that makes life exciting and i cheer you up. I'm sure 
> you will succeed and improve gentoo even better :)

The problem is that a few baselayout operations can be running 
concurrently, and these processes will share the same resources (e.g. 
service state files). baselayout-1 makes very little effort to serialize 
access to any of these resources, resulting in several highly repeatable 
failure conditions due to races.

The original bug report:
https://bugs.gentoo.org/show_bug.cgi?id=154670

My attempt to fix it:
https://bugs.gentoo.org/show_bug.cgi?id=166545

However, it turns out my locking implementation can be easily broken and 
is not race free.

> I'm not quite good in politics but i will follow your advice :). I just 
> have feared you will definitely drop baselayout-1. (anyway, maintaining 
> two different kinds of software that do approximately the same thing is 
> a pain). I will need to reconvert sooner or later.

I'm not involved in baselayout development, but yes, I am fairly sure 
that baselayout-1 will be completely dropped in the near future. It's 
partially unmaintained at the moment -- there are known bugs which will 
not be fixed in the 1.x branches.

Daniel
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage

[Jimmy Jazz]

[-- Attachment #1: Type: text/plain, Size: 5624 bytes --]

Daniel Drake a écrit :
> Jimmy Jazz wrote:
>> Instead /sbin/functions.sh has helped me a lot to write a script that
>> does approximately the same but in ash and with candies too :)
> 
> Now you're making more sense -- you prefer baselayout written in bash
> because you are copying and mangling its code in ways that the
> developers didn't intend. I see.
> 
> FYI, baselayout-2 no longer requires bash.
> 
>> Right, a shell is not what handles the best concurrency issues but
>> "wait" and "jobs" have been quite improved. If you have an example i
>> could try. Also, that makes life exciting and i cheer you up. I'm sure
>> you will succeed and improve gentoo even better :)
> 
> The problem is that a few baselayout operations can be running
> concurrently, and these processes will share the same resources (e.g.
> service state files). baselayout-1 makes very little effort to serialize
> access to any of these resources, resulting in several highly repeatable
> failure conditions due to races.
> 
> The original bug report:
> https://bugs.gentoo.org/show_bug.cgi?id=154670
> 
> My attempt to fix it:
> https://bugs.gentoo.org/show_bug.cgi?id=166545
> 
> However, it turns out my locking implementation can be easily broken and
> is not race free.
> 
>> I'm not quite good in politics but i will follow your advice :). I
>> just have feared you will definitely drop baselayout-1. (anyway,
>> maintaining two different kinds of software that do approximately the
>> same thing is a pain). I will need to reconvert sooner or later.
> 
> I'm not involved in baselayout development, but yes, I am fairly sure
> that baselayout-1 will be completely dropped in the near future. It's
> partially unmaintained at the moment -- there are known bugs which will
> not be fixed in the 1.x branches.
> 
> Daniel


Hello Daniel,

I'm made a little draft to illustrate the possibilities of bash to
manage threads and lock files even if it doesn't call external scripts
from bash. That's a bit more tricky but that works well too ;)

The script runs concurrent projects. Every projects has an ordered team
affected to it and developers can be shared to more than one team. Every
time a manager tries to hire a developer for its project, he
will give more money for it ;).

To increase the nomber of teams, you need just to uncomment the
group[xx] lines or add new one. Take in mind, that is only a shell script.

Until you get "XX says: task Y for project n°Z done." the dev XX cannot
be affected to an other project. Otherwise you have found a bug :(

I voluntarily left a stderr error on line 44 to be displayed to ease the
comprehension of the process.

Also $$ is useless in a subshell. It will always
return the pid of the shell itself and not its own pid :(

$PPID shouldn't be interpreted by the current shell or else you won't
get the right pid (see the function getpid() in the script). Also, you
can call a C program that returns for you the pid of the shell on where
it was running.

Something like,

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>

int main()
{
	printf("%d\n", getppid());
}

will work.

Anyway, it is possible to use bash and lock files even if you are not
able to determine the pid of the process and use the kill -s 0 ${pid}
command. If "set -C" is not supported by the shell, you can still use
any "atomic" calls like hard links but you will need to use an
intermediate file to do so. (See for examples on the web)

islocked() {
	ln $1 $2  #<------------------ is atomic
	rm -f ${1:-undefined}
}

flock() {
	local keylock="$(basename $1)"
	local pid="$$" #<-- doesn't work if called from the same script
	local locked="/var/tmp/lock/${keylock}.lck"
	local locker="/var/tmp/lock/${keylock}.${pid}"

	echo ${pid} > ${locker} || return 1

	if islocked ${locker} ${locked}; then
		return 0
	fi

...

        return 1
}

Actually, to save the pid in the locker is a good idea and will help to
find out any staled scripts still running, but that is not always
necessary and required :)

It should be executed like a user and needs no extra rights except to be
able to write in /var/tmp (as usual it is safer). Because you are not
allowed to write in /var/lock, create a new directory /var/tmp/lock
and copy the script in /var/tmp. Rename it with whatever name you want
and run it there. Moreover to save the believer, pass an option to that
script.

For the usage, the script is provided as-is ;)


If you like the demo, just let me know, i will feel even less lonely on
that mailing list ;)
If you are convinced, it is even better... If not, life will still go on :)

Jj

Ps: i hope there is no bug in it. I really didn't have to much time to
test it and ... that gives me a lot of headaches as well (i'm not used
to it) lol.


@Spock

also i finally get splashutils to work with ash and without fbsplash.
Most of the problems happened by the way how
/etc/spash/default/1680x1050.cfg for example refreshs some portions of
the screen and makes the lot flicker.

Meantimes, i take many times to understand how to "call" icons with the
daemon. If you send a svc_start you need to end with a svc_stop too
otherwise the icon continues to be displayed again and again :)

I still have one weird problem. It happens only on a x86_64 system. The
daemon core dumps when called from /sbin/rc but works during the
shutdown ?! I do not call expressly splash daemon from init.d as i
didn't use the verbose mode for ttys.

Thx anyway,

Jj





[-- Attachment #2: NameYourCompanyHere.sh --]
[-- Type: application/x-shellscript, Size: 5318 bytes --]