1:25 p.m.
I've been reading about how nice the new graphical boot up looks, so I just installed
the latest (to my knowledge) rhgb (rhgb-0.10.2-1) via yum, and changed my runlevel in
/etc/inittab to 5. (I usually just ssh in to the box on runlevel 3) The boot process looks
very clean and professional. I really like the way it is shaping up. Many newbies will
feel comfortable with the look and feel of the graphical boot, rather that the "cold
white on black" console mode.
I have a few suggestions and questions, in order of the boot process (excuse me if some or
all of these have been addressed before):
1. Is it possible to suppress the initial "console-ish" dmesg, before the
graphical interface kicks in?
2. Why is there a pause between the bootup, and the graphical login screen? It seems like
X kicks out, and then restarts. It seems a little "un-refined", for lack of
better words.
3. Now that there is a nice looking boot up process, what about a nice shutdown process?
Are there any plans to make the shutdown/reboot look as nice as the graphical boot up?
Would anybody else be interested in something like this?
Thanks in advance...
-Kev
---
Kevin Worthington - <kworthington (at) linuxmail {dot} org>
Faithful Red Hat Linux user since April 1998
Registered Linux User #218689 - http://counter.li.org
--
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
1:58 p.m.
On Fri, 2003-10-10 at 19:25, Kevin Worthington wrote:
I've been reading about how nice the new graphical boot up looks,
so I
just installed the latest (to my knowledge) rhgb (rhgb-0.10.2-1) via
yum, and changed my runlevel in /etc/inittab to 5. (I usually just ssh
in to the box on runlevel 3) The boot process looks very clean and
professional. I really like the way it is shaping up. Many newbies
will feel comfortable with the look and feel of the graphical boot,
rather that the "cold white on black" console mode.
I have a few suggestions and questions, in order of the boot process
(excuse me if some or all of these have been addressed before):
1. Is it possible to suppress the initial "console-ish" dmesg, before
the graphical interface kicks in?
MacOS X seems to have a fixed size logo in there, and a plain backdrop.
If somebody were to write the code to have something like this in the
kernel, would it be accepted? (at least on the RH/Fedora side)
2. Why is there a pause between the bootup, and the graphical login
screen? It seems like X kicks out, and then restarts. It seems a
little "un-refined", for lack of better words.
gdm/kdm handle starting the X server themselves, maybe they shouldn't in
that particular case?
3. Now that there is a nice looking boot up process, what about a
nice
shutdown process? Are there any plans to make the shutdown/reboot look
as nice as the graphical boot up? Would anybody else be interested in
something like this?
I don't want a pretty shutdown, I want a (very) fast one :)
(something like "umount -a" followed by poweroff -f, under 2 seconds
flat from when I click "shutdown" in GNOME)
---
Bastien Nocera <hadess(a)hadess.net>
The red brick wall was the colour of a brick-red crayon.
2:04 p.m.
Kevin Worthington (kworthington(a)linuxmail.org) said:
1. Is it possible to suppress the initial "console-ish"
dmesg, before the graphical interface kicks in?
Boot with 'quiet'.
2. Why is there a pause between the bootup, and the graphical login
screen? It seems like X kicks out, and then restarts. It seems a little
"un-refined", for lack of better words.
gdm/xdm/kdm use a different X server instance.
3. Now that there is a nice looking boot up process, what about a
nice shutdown process? Are there any plans to make the shutdown/reboot look as nice as the
graphical boot up? Would anybody else be interested in something like this?
It's probably better to just speed up shutdown; there's some
obvious things to do here that we'll probably do for the next
cycle. (Top of the list is just not shutting down most services;
let init sort them out.)
Bill
8:58 p.m.
On Fri, 10 Oct 2003, Bill Nottingham wrote:
Kevin Worthington (kworthington(a)linuxmail.org) said:
> 1. Is it possible to suppress the initial "console-ish"
> dmesg, before the graphical interface kicks in?
Boot with 'quiet'.
I know this is too windowsish, but it would be nice if the kernel
would boot quietly if there have been a clean shutdown. I don't
know how to implement this cleanly yet, as if we get a panic, no
one has removed the flag and it would boot quiet again...
A related question: Can't one ask kudzu to scan just a few
buses? Say, USB and firewire only?
Another one (unrelated this time): Times to times applications
crash and leave sockets in /tmp that prevents them from starting
next time (I had the problem with xmms-1.2.7 atleast), is there
any problem with cleaning /tmp completely during boot time?
Bill
behdad
3:42 a.m.
On Sat, 2003-10-11 at 02:58, Behdad Esfahbod wrote:
On Fri, 10 Oct 2003, Bill Nottingham wrote:
> Kevin Worthington (kworthington(a)linuxmail.org) said:
> > 1. Is it possible to suppress the initial "console-ish"
> > dmesg, before the graphical interface kicks in?
>
> Boot with 'quiet'.
I know this is too windowsish, but it would be nice if the kernel
would boot quietly if there have been a clean shutdown. I don't
know how to implement this cleanly yet, as if we get a panic, no
one has removed the flag and it would boot quiet again...
Hmmm... I think the best way to handle that would be to put a flag when
the computer has started cleanly and remove it when it has be shut down
cleanly. This, way, if it kernel-panics or crashes, the flag is still
there.
3:38 p.m.
On Sat, 11 Oct 2003, Julien Olivier wrote:
On Sat, 2003-10-11 at 02:58, Behdad Esfahbod wrote:
> On Fri, 10 Oct 2003, Bill Nottingham wrote:
>
> > Kevin Worthington (kworthington(a)linuxmail.org) said:
> > > 1. Is it possible to suppress the initial "console-ish"
> > > dmesg, before the graphical interface kicks in?
> >
> > Boot with 'quiet'.
>
> I know this is too windowsish, but it would be nice if the kernel
> would boot quietly if there have been a clean shutdown. I don't
> know how to implement this cleanly yet, as if we get a panic, no
> one has removed the flag and it would boot quiet again...
>
Hmmm... I think the best way to handle that would be to put a flag when
the computer has started cleanly and remove it when it has be shut down
cleanly. This, way, if it kernel-panics or crashes, the flag is still
there.
I guess you misunderstood what I meant. I cannot see how you can
handle the panics when you have no write access anywhere. The
clean way to handle this is to have a bios register for that,
which OS and BIOS can interact and they both would skip most
diagnostics if everything is find. MS has published such a spec,
called Simple Boot Flag Spec v2., it's one of those patented ones
I guess. Man in a few years they would patent the concept of a
"variable"...
Lets wait for bios designers to implement that...
behdad,
1:22 p.m.
Behdad Esfahbod wrote:
On Sat, 11 Oct 2003, Julien Olivier wrote:
>Hmmm... I think the best way to handle that would be to put a flag when
>the computer has started cleanly and remove it when it has be shut down
>cleanly. This, way, if it kernel-panics or crashes, the flag is still
>there.
I guess you misunderstood what I meant. I cannot see how you can
handle the panics when you have no write access anywhere. The
Looks like you missed it. This flag is set on boot, and cleared on
shutdown. If a panic happens, it's not cleared, and stiull set next
boot. During boot if the flag is set, you know you had a problem in the
shudown.
Don't we already have similar flags in / now?
Like .autofsck, which is cleared on shutdown/unmount.
Other flags I see in a quick glance at rc.sysinit include
forcefsck, fsckoptions, fastboot.
-Thomas
8:38 p.m.
On Mon, 13 Oct 2003, Thomas Dodd wrote:
Behdad Esfahbod wrote:
> On Sat, 11 Oct 2003, Julien Olivier wrote:
>>Hmmm... I think the best way to handle that would be to put a flag when
>>the computer has started cleanly and remove it when it has be shut down
>>cleanly. This, way, if it kernel-panics or crashes, the flag is still
>>there.
>
>
> I guess you misunderstood what I meant. I cannot see how you can
> handle the panics when you have no write access anywhere. The
Looks like you missed it. This flag is set on boot, and cleared on
shutdown. If a panic happens, it's not cleared, and stiull set next
boot. During boot if the flag is set, you know you had a problem in the
shudown.
I'm talking about when the kernel is still loading, and you have
no writeable mounted filesystem to set the flag.
Don't we already have similar flags in / now?
Like .autofsck, which is cleared on shutdown/unmount.
Other flags I see in a quick glance at rc.sysinit include
forcefsck, fsckoptions, fastboot.
-Thomas
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
behdad,
who is going to study after finishing this mail.
3:07 p.m.
Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
A related question: Can't one ask kudzu to scan just a few
buses? Say, USB and firewire only?
Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and
serial probes, which are the big time sinks.
Another one (unrelated this time): Times to times applications
crash and leave sockets in /tmp that prevents them from starting
next time (I had the problem with xmms-1.2.7 atleast), is there
any problem with cleaning /tmp completely during boot time?
Not at a system level, I believe, just at level of annoying people who put
stuff there. :)
Bill
5:41 p.m.
On Mon, 2003-10-13 at 13:07, Bill Nottingham wrote:
> Another one (unrelated this time): Times to times applications
> crash and leave sockets in /tmp that prevents them from starting
> next time (I had the problem with xmms-1.2.7 atleast), is there
> any problem with cleaning /tmp completely during boot time?
Not at a system level, I believe, just at level of annoying people who put
stuff there. :)
I like to mount /tmp using tmpfs because I'm a BOFH :)
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
2:15 a.m.
Le mar 14/10/2003 à 00:41, Wil Cooley a écrit :
On Mon, 2003-10-13 at 13:07, Bill Nottingham wrote:
> > Another one (unrelated this time): Times to times applications
> > crash and leave sockets in /tmp that prevents them from starting
> > next time (I had the problem with xmms-1.2.7 atleast), is there
> > any problem with cleaning /tmp completely during boot time?
>
> Not at a system level, I believe, just at level of annoying people who put
> stuff there. :)
I like to mount /tmp using tmpfs because I'm a BOFH :)
And people usually like it better than being reminded to clean up their
stuff
--
Nicolas Mailhot
Zealot
2:12 a.m.
Le lun 13/10/2003 à 22:07, Bill Nottingham a écrit :
Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
> A related question: Can't one ask kudzu to scan just a few
> buses? Say, USB and firewire only?
Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and
serial probes, which are the big time sinks.
And USB has no business being in a startup probe system like kudzu - usb
belongs in hotplug scripts
Cheers,
--
Nicolas Mailhot
2:38 a.m.
On Tue, 14 Oct 2003, Nicolas Mailhot wrote:
Le lun 13/10/2003 � 22:07, Bill Nottingham a �crit :
> Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
> > A related question: Can't one ask kudzu to scan just a few
> > buses? Say, USB and firewire only?
>
> Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and
> serial probes, which are the big time sinks.
And USB has no business being in a startup probe system like kudzu - usb
belongs in hotplug scripts
Last time I remember needed to run kudzu to install a USB
printer. Same for the scanner...
Cheers,
behdad,
2:58 a.m.
Le mar 14/10/2003 à 09:38, Behdad Esfahbod a écrit :
On Tue, 14 Oct 2003, Nicolas Mailhot wrote:
> Le lun 13/10/2003 22:07, Bill Nottingham a crit :
> > Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
> > > A related question: Can't one ask kudzu to scan just a few
> > > buses? Say, USB and firewire only?
> >
> > Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and
> > serial probes, which are the big time sinks.
>
> And USB has no business being in a startup probe system like kudzu - usb
> belongs in hotplug scripts
Last time I remember needed to run kudzu to install a USB
printer. Same for the scanner...
Sure - right now you need kudzu for this.
But this does not mean you should do it here - kudzu for usb devices is
an horror. They are typically never always-on (or always plugged in)
which means if the user doesn't learn to plug and power-on everything
before the boot sequence he'll be deluged with helpful kudzu messages
asking him to remove printer, scanner... configuration.
Kudzu is only good for build-in devices. And even for them the kernel
people are moving to an hotplug-only setup.
Regards,
--
Nicolas Mailhot
3:02 a.m.
On Tue, 14 Oct 2003, Nicolas Mailhot wrote:
Le mar 14/10/2003 � 09:38, Behdad Esfahbod a �crit :
> On Tue, 14 Oct 2003, Nicolas Mailhot wrote:
>
> > Le lun 13/10/2003 22:07, Bill Nottingham a crit :
> > > Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
> > > > A related question: Can't one ask kudzu to scan just a few
> > > > buses? Say, USB and firewire only?
> > >
> > > Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and
> > > serial probes, which are the big time sinks.
> >
> > And USB has no business being in a startup probe system like kudzu - usb
> > belongs in hotplug scripts
>
> Last time I remember needed to run kudzu to install a USB
> printer. Same for the scanner...
Sure - right now you need kudzu for this.
But this does not mean you should do it here - kudzu for usb devices is
an horror. They are typically never always-on (or always plugged in)
which means if the user doesn't learn to plug and power-on everything
before the boot sequence he'll be deluged with helpful kudzu messages
asking him to remove printer, scanner... configuration.
This is another reason that one should
chkconfig --level 2345 kudzu off
;)
Kudzu is only good for build-in devices. And even for them the
kernel
people are moving to an hotplug-only setup.
Regards,
behdad
8:57 a.m.
Nicolas Mailhot wrote:
Sure - right now you need kudzu for this.
But this does not mean you should do it here - kudzu for usb devices is
an horror. They are typically never always-on (or always plugged in)
which means if the user doesn't learn to plug and power-on everything
before the boot sequence he'll be deluged with helpful kudzu messages
asking him to remove printer, scanner... configuration.
Only once. You tell kudzu not to ask about it again.
Still not sure i want the hot plug scripts handling more than they do
now. They do bad enough there.
-Thomas
9:18 a.m.
Le mar 14/10/2003 à 15:57, Thomas Dodd a écrit :
Nicolas Mailhot wrote:
> Sure - right now you need kudzu for this.
> But this does not mean you should do it here - kudzu for usb devices is
> an horror. They are typically never always-on (or always plugged in)
> which means if the user doesn't learn to plug and power-on everything
> before the boot sequence he'll be deluged with helpful kudzu messages
> asking him to remove printer, scanner... configuration.
Only once. You tell kudzu not to ask about it again.
Still not sure i want the hot plug scripts handling more than they do
now. They do bad enough there.
I will readily admit it was a /sbin/chkconfig --level 0123456 kudzu off
for me. And I'm sure I'm far from the only one.
As for the hotplug scripts - they are perhaps as bad as kudzu right now
but they have a chance to improve, while kudzu's on-boot scanning is
conceptually flawed as soon as you get hotplug devices into the picture.
Regards,
--
Nicolas Mailhot
2:14 p.m.
On Fri, 2003-10-10 at 14:25, Kevin Worthington wrote:
2. Why is there a pause between the bootup, and the graphical login
screen?
It seems like X kicks out, and then restarts. It seems a little "un-refined",
for lack of better words.
See an earlier discussion about SystemServices on this list. One
proposal is to have a '--hide-login-screen' (or whatever) option to gdm
so that gdm can start X, but not start the greeter. Then, rhgb could
use that instance of X and when completed, a signal (via the gdm
socket?) could be sent to gdm to tell it to go ahead and start the
greeter. One possibility, anyhow. The short of it is that there is no
easy answer to this with the current initscripts model (as well as other
factors, I'm sure).
PS: Friendly etiquette request: please make sure you're mailer wraps
long lines. It makes messages hard to pare down in order to reply to
them (going back and forth in addition to highlighting and deleting).
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
2:33 p.m.
Paul Iadonisi wrote:
On Fri, 2003-10-10 at 14:25, Kevin Worthington wrote:
>2. Why is there a pause between the bootup, and the graphical login screen?
>It seems like X kicks out, and then restarts. It seems a little
"un-refined",
>for lack of better words.
proposal is to have a '--hide-login-screen' (or whatever) option to gdm
so that gdm can start X, but not start the greeter. Then, rhgb could
<...>
easy answer to this with the current initscripts model (as well as
other
factors, I'm sure).
What about starting X for rhgb on a different vt, say vt8, as server :1?
Then *DM start X on vt7, server :) as normal. Once rhgb sees gdm up it
shuts down.
How many people use multiple servers? How many of them would use rhgb?
My guess is most people who use multiple Xservers wouldn't care to use
rhgb, not that there are many that use multiple servers anyway.
Perhaps a config setting for rhgb in that case, to use a different
vt/server? Parsing the correct *DM config files seams overkill. If
you're ready to configure multiople servers in *DM, you should know
enought to configure rhgb too.
-Thomas (who doesn't expect to ever use rhgb anyway)
2:41 p.m.
Thomas Dodd (ted(a)cypress.com) said:
What about starting X for rhgb on a different vt, say vt8, as server
:1?
Then *DM start X on vt7, server :) as normal. Once rhgb sees gdm up it
shuts down.
How many people use multiple servers? How many of them would use rhgb?
My guess is most people who use multiple Xservers wouldn't care to use
rhgb, not that there are many that use multiple servers anyway.
Perhaps a config setting for rhgb in that case, to use a different
vt/server? Parsing the correct *DM config files seams overkill. If
you're ready to configure multiople servers in *DM, you should know
enought to configure rhgb too.
Running two X servers simultaneously on the same hardware is a
great way to turn up obscure X driver bugs. :)
Bill
3:07 p.m.
Bill Nottingham wrote:
Running two X servers simultaneously on the same hardware is a
great way to turn up obscure X driver bugs. :)
And this would get them too:)
Don't you think Mike would love to find out about them early in testing,
due to rhgb, instead of 3 month form now when someone decideds to use
multiple servers for real?
-Thomas
3:19 p.m.
On Oct 10, 2003, Thomas Dodd <ted(a)cypress.com> wrote:
What about starting X for rhgb on a different vt, say vt8, as server
:1?
That's what it does.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
3:43 p.m.
Thomas Dodd wrote:
Paul Iadonisi wrote:
> On Fri, 2003-10-10 at 14:25, Kevin Worthington wrote:
>
>> 2. Why is there a pause between the bootup, and the graphical login
>> screen?
>> It seems like X kicks out, and then restarts. It seems a little
>> "un-refined",
>> for lack of better words.
>
> proposal is to have a '--hide-login-screen' (or whatever) option to gdm
> so that gdm can start X, but not start the greeter. Then, rhgb could
<...>
> easy answer to this with the current initscripts model (as well as other
> factors, I'm sure).
All of this avoids the real issue: rhgb is incredibly slow. It takes
this thing 6 seconds to appear and put up the panel that says what's
starting up in initscripts. And while it's thrashing, coming up, it's
impeding the startup of other services. It's ill-advised; you can go to
SVGA or the framebuffer faster and with less footprint to put up a blue
background and a newt panel...
Add to that the complaint that rhgb starts and X server, stops it, and
allows gdm to start another. If things remain as they are, rhgb should
start up X, do it's thing, then hand over responsibility of that X
server to gdm.
--
____ .:. ____
Bryan W. Headley - bwheadley(a)earthlink.net
4:45 p.m.
On Oct 10, 2003, "Bryan W. Headley" <bwheadley(a)earthlink.net> wrote:
All of this avoids the real issue: rhgb is incredibly slow. It takes
this thing 6 seconds to appear and put up the panel that says what's
starting up in initscripts. And while it's thrashing, coming up, it's
impeding the startup of other services.
But then, gdm start-up becomes incredibly faster, because all of the
XFree86 code is already in memory!
I'm told one of the greatest start-up time hogs in rhgb has to do with
the font cache, that gets trashed. A fix for this is already in the
works, maybe even already in rawhide.
That said, it would be very nice if the time rhgb takes to start up
didn't prevent other init services from getting started.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
6 p.m.
Alexandre Oliva wrote:
On Oct 10, 2003, "Bryan W. Headley"
<bwheadley(a)earthlink.net> wrote:
>All of this avoids the real issue: rhgb is incredibly slow. It takes
>this thing 6 seconds to appear and put up the panel that says what's
>starting up in initscripts. And while it's thrashing, coming up, it's
>impeding the startup of other services.
But then, gdm start-up becomes incredibly faster, because all of the
XFree86 code is already in memory!
I agree, but... If you are dealing with corporate standards where they
like seeing a graphical image of something (like their logo) other than
driver versions/initscript startups, then you'll want to get that blue
screen up as fast as possible. It's nice that it's helping gdm's startup
time, but that's several seconds in the future :-)
That said, it would be very nice if the time rhgb takes to start up
didn't prevent other init services from getting started.
Put it in the background, immediately. But the other services still deal
with the thrashing...
--
____ .:. ____
Bryan W. Headley - bwheadley(a)earthlink.net
3:48 p.m.
Kevin Worthington wrote:
I've been reading about how nice the new graphical boot up looks,
so I just installed the latest (to my knowledge) rhgb (rhgb-0.10.2-1) via yum, and changed
my runlevel in /etc/inittab to 5. (I usually just ssh in to the box on runlevel 3) The
boot process looks very clean and professional. I really like the way it is shaping up.
Many newbies will feel comfortable with the look and feel of the graphical boot, rather
that the "cold white on black" console mode.
I have a few suggestions and questions, in order of the boot process (excuse me if some or
all of these have been addressed before):
1. Is it possible to suppress the initial "console-ish" dmesg, before the
graphical interface kicks in?
2. Why is there a pause between the bootup, and the graphical login screen? It seems like
X kicks out, and then restarts. It seems a little "un-refined", for lack of
better words.
3. Now that there is a nice looking boot up process, what about a nice shutdown process?
Are there any plans to make the shutdown/reboot look as nice as the graphical boot up?
Would anybody else be interested in something like this?
Thanks in advance...
-Kev
---
Kevin Worthington - <kworthington (at) linuxmail {dot} org>
Faithful Red Hat Linux user since April 1998
Registered Linux User #218689 - http://counter.li.org
There's a kernel patch for a bootsplash screen available on the
internet. (bootsplash.org) I sent a modification of it for
kernel-2.4.22 to the kernel people at Red Hat, but they seem divided
about whether or not to put it in. This patch would put a full-screen
JPG on the screen instead of the normal b/w console input, starting
before the kernel puts a word on the screen. There's also a command
line utility which could easily be used to put in a shutdown screen.
And also it can bypassed with F2 key. I've got it working on my box,
but the graphics I have are nothing more than the generic Linux
penguin. If anyone wants help about how to get it to work, just email
jason at geshp.com.
Jason Luka
5:53 p.m.
Jason Luka wrote:
There's a kernel patch for a bootsplash screen available on the
internet. (bootsplash.org) I sent a modification of it for
kernel-2.4.22 to the kernel people at Red Hat, but they seem divided
about whether or not to put it in.
I'm looking at this debian package, boot-icons, which pops up images
using the framebuffer, at the bequest of SysVinit scripts invoked during
the bootup procedure. No kernel patches.
--
____ .:. ____
Bryan W. Headley - bwheadley(a)earthlink.net
6:36 p.m.
Bryan W. Headley wrote:
Jason Luka wrote:
> There's a kernel patch for a bootsplash screen available on the
> internet. (bootsplash.org) I sent a modification of it for
> kernel-2.4.22 to the kernel people at Red Hat, but they seem divided
> about whether or not to put it in.
I'm looking at this debian package, boot-icons, which pops up images
using the framebuffer, at the bequest of SysVinit scripts invoked
during the bootup procedure. No kernel patches.
The kernel patch in question, though, pops up the image using the
framebuffer before it gets to SysVinit scripts, namely when the kernel
initializes the video.
9:17 a.m.
Jason Luka wrote:
Bryan W. Headley wrote:
> Jason Luka wrote:
>
>> There's a kernel patch for a bootsplash screen available on the
>> internet. (bootsplash.org) I sent a modification of it for
>> kernel-2.4.22 to the kernel people at Red Hat, but they seem divided
>> about whether or not to put it in.
>
>
>
> I'm looking at this debian package, boot-icons, which pops up images
> using the framebuffer, at the bequest of SysVinit scripts invoked
> during the bootup procedure. No kernel patches.
>
>
The kernel patch in question, though, pops up the image using the
framebuffer before it gets to SysVinit scripts, namely when the kernel
initializes the video.
Yes, whereas boot-icons seems to be 100% userland, although it also uses
the fb. Might help placate those who are disturbed by the kernel patch,
although bootsplash IS used by SuSE (supposively) with no ill effects.
--
____ .:. ____
Bryan W. Headley - bwheadley(a)earthlink.net
7525
days inactive
7529
days old
29 comments
12 participants
participants (12)
-
Alexandre Oliva -
Bastien Nocera -
Behdad Esfahbod -
Bill Nottingham -
Bryan W. Headley -
Jason Luka -
Julien Olivier -
Kevin Worthington -
Nicolas Mailhot -
Paul Iadonisi -
Thomas Dodd -
Wil Cooley