Re: [opensuse-factory] mkinitrd or dracut ?
Le jeudi 01 novembre 2012 à 20:23 +0100, Andreas Jaeger a écrit :
On 11/01/2012 12:03 PM, Raymond Wooninck wrote:
[...] Again based on the current status of mkinitrd (and the fact that the above bug somehow seems to take quite some time to be resolved) I really wonder if we have to keep the old mkinitrd functionality or that we should go with a newer technology which is used by more distributions. Especially as that we are already providing working packages for dracut.
Currently mkinitrd has support for some hardware/boot scenario that dracut has not, so before we make dracut the default (or drop mkinitrd) we need to get everything running. Hannes, Frederic, what's exactly is missing?
* dsdt support (skeleton in place) * blogd (not sure it is still needed with systemd) * rtc / zoneinfo (might not be relevant anymore, might be worth asking Werner) * EC2 (but it is just a workaround) * kdump * mtab "migration" * "supported" option for kernel module * netconsole -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 05 November 2012 08:50:18 Frederic Crozat wrote:
Currently mkinitrd has support for some hardware/boot scenario that dracut has not, so before we make dracut the default (or drop mkinitrd) we need to get everything running. Hannes, Frederic, what's exactly is missing?
* dsdt support (skeleton in place) * blogd (not sure it is still needed with systemd) * rtc / zoneinfo (might not be relevant anymore, might be worth asking Werner) * EC2 (but it is just a workaround) * kdump * mtab "migration" * "supported" option for kernel module * netconsole
Hi Frederic, During the Saturday we have been playing with dracut and we added some additional fixes with regards to utilizing the right paths, keymaps, etc. It would be great if we somehow can join efforts in getting a working dracut for openSUSE. I have just submitted my patches to Base:System with SR#140167. With these changes a working initrd file can be generated that is able to boot most systems. (Including those with mdraid stuff). Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 05, 2012 at 08:50:18AM +0000, Frederic Crozat wrote:
Le jeudi 01 novembre 2012 à 20:23 +0100, Andreas Jaeger a écrit :
On 11/01/2012 12:03 PM, Raymond Wooninck wrote:
[...] Again based on the current status of mkinitrd (and the fact that the above bug somehow seems to take quite some time to be resolved) I really wonder if we have to keep the old mkinitrd functionality or that we should go with a newer technology which is used by more distributions. Especially as that we are already providing working packages for dracut.
Currently mkinitrd has support for some hardware/boot scenario that dracut has not, so before we make dracut the default (or drop mkinitrd) we need to get everything running. Hannes, Frederic, what's exactly is missing?
* dsdt support (skeleton in place) * blogd (not sure it is still needed with systemd)
If do not want to have the logs of the boot scripts and file system check of the root file system doen *within* initrd you might drop it. Otherwise it would better not todo.
* rtc / zoneinfo (might not be relevant anymore, might be worth asking Werner)
It is relevant otherwise the timestamps of the root file system are wrong that is you may check and mount it in the `future'. Even with (U)EFI it is required as in UEFI the local time is the default for the CMOS clock but the kernels system clock has to be in UTC as otherwise the user space clock determined by /etc/localtime goes wrong.
* EC2 (but it is just a workaround)
All the points
* kdump * mtab "migration" * "supported" option for kernel module * netconsole
are required for paying customers. Btw: What are the advantages of dracut over mkinitrd? Please do not tell its colored and animated as this is *not* a advantage. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
are required for paying customers. Btw: What are the advantages of dracut over mkinitrd? Please do not tell its colored and animated as this is *not* a advantage. for example at the moment generates a working initrd.... it is somehow maintained upstream...
as of in paying customers... I am pretty sure other distro's that use dracut have them too... and solutions must exist... A -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 05 novembre 2012 à 10:13 +0100, Dr. Werner Fink a écrit :
On Mon, Nov 05, 2012 at 08:50:18AM +0000, Frederic Crozat wrote:
Le jeudi 01 novembre 2012 à 20:23 +0100, Andreas Jaeger a écrit :
On 11/01/2012 12:03 PM, Raymond Wooninck wrote:
[...] Again based on the current status of mkinitrd (and the fact that the above bug somehow seems to take quite some time to be resolved) I really wonder if we have to keep the old mkinitrd functionality or that we should go with a newer technology which is used by more distributions. Especially as that we are already providing working packages for dracut.
Currently mkinitrd has support for some hardware/boot scenario that dracut has not, so before we make dracut the default (or drop mkinitrd) we need to get everything running. Hannes, Frederic, what's exactly is missing?
* dsdt support (skeleton in place) * blogd (not sure it is still needed with systemd)
If do not want to have the logs of the boot scripts and file system check of the root file system doen *within* initrd you might drop it. Otherwise it would better not todo.
* rtc / zoneinfo (might not be relevant anymore, might be worth asking Werner)
It is relevant otherwise the timestamps of the root file system are wrong that is you may check and mount it in the `future'. Even with (U)EFI it is required as in UEFI the local time is the default for the CMOS clock but the kernels system clock has to be in UTC as otherwise the user space clock determined by /etc/localtime goes wrong.
* EC2 (but it is just a workaround)
All the points
* kdump * mtab "migration" * "supported" option for kernel module * netconsole
are required for paying customers. Btw: What are the advantages of dracut over mkinitrd? Please do not tell its colored and animated as this is *not* a advantage.
Well, we are speaking about Factory, not about SLE ;) But I'd say sharing maintenance load across vendors, easier switch from customers coming from another distribution, for a component which is not really a core differentiation with competition. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 05, 2012 at 12:57:48PM +0100, Frederic Crozat wrote:
Le lundi 05 novembre 2012 à 10:13 +0100, Dr. Werner Fink a écrit :
All the points
* kdump * mtab "migration" * "supported" option for kernel module * netconsole
are required for paying customers. Btw: What are the advantages of dracut over mkinitrd? Please do not tell its colored and animated as this is *not* a advantage.
Well, we are speaking about Factory, not about SLE ;)
But I'd say sharing maintenance load across vendors, easier switch from customers coming from another distribution, for a component which is not really a core differentiation with competition.
I'm thinking about regressions as the Factory is also for the next SLES. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 05 novembre 2012 à 13:39 +0100, Dr. Werner Fink a écrit :
On Mon, Nov 05, 2012 at 12:57:48PM +0100, Frederic Crozat wrote:
Le lundi 05 novembre 2012 à 10:13 +0100, Dr. Werner Fink a écrit :
All the points
* kdump * mtab "migration" * "supported" option for kernel module * netconsole
are required for paying customers. Btw: What are the advantages of dracut over mkinitrd? Please do not tell its colored and animated as this is *not* a advantage.
Well, we are speaking about Factory, not about SLE ;)
But I'd say sharing maintenance load across vendors, easier switch from customers coming from another distribution, for a component which is not really a core differentiation with competition.
I'm thinking about regressions as the Factory is also for the next SLES.
Understood, otherwise I wouldn't have done the list in the first place ;) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2012-11-05 13:39, Dr. Werner Fink wrote:
Well, we are speaking about Factory, not about SLE ;)
But I'd say sharing maintenance load across vendors, easier switch from customers coming from another distribution, for a component which is not really a core differentiation with competition.
I'm thinking about regressions as the Factory is also for the next SLES.
The regression in o:F and SLES will be: semitranslucent background picture on tty1 when text is shown is gone. I have not told your product managers yet, but bootsplash (the .rpm and the implementation) is important for branding. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Thu, 29 Nov 2012 23:44:24 +0100 (CET), Jan Engelhardt wrote:
On Monday 2012-11-05 13:39, Dr. Werner Fink wrote:
Well, we are speaking about Factory, not about SLE ;)
But I'd say sharing maintenance load across vendors, easier switch from customers coming from another distribution, for a component which is not really a core differentiation with competition.
I'm thinking about regressions as the Factory is also for the next SLES.
The regression in o:F and SLES will be: semitranslucent background picture on tty1 when text is shown is gone. I have not told your product managers yet, but bootsplash (the .rpm and the implementation) is important for branding.
Technically seen, keeping the background picture on tty1 while showing bootsplash with plymouth shouldn't be too hard. But they are exclusive currently in the package level, unfortunately. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 30 November 2012 10:46:08 Takashi Iwai wrote:
The regression in o:F and SLES will be: semitranslucent background picture on tty1 when text is shown is gone. I have not told your product managers yet, but bootsplash (the .rpm and the implementation) is important for branding.
Technically seen, keeping the background picture on tty1 while showing bootsplash with plymouth shouldn't be too hard. But they are exclusive currently in the package level, unfortunately.
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit :
On Friday 30 November 2012 10:46:08 Takashi Iwai wrote:
The regression in o:F and SLES will be: semitranslucent background picture on tty1 when text is shown is gone. I have not told your product managers yet, but bootsplash (the .rpm and the implementation) is important for branding.
Technically seen, keeping the background picture on tty1 while showing bootsplash with plymouth shouldn't be too hard. But they are exclusive currently in the package level, unfortunately.
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth.
From what I understand of the way KMS is handled, it would require plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
I'm also not strongly convinced branding tty is THAT important. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I'm also not strongly convinced branding tty is THAT important.
if it is to orient ourselves on the last branding attempts one may say was not very successful either... Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 30 Nov 2012 11:08:55 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit :
On Friday 30 November 2012 10:46:08 Takashi Iwai wrote:
The regression in o:F and SLES will be: semitranslucent background picture on tty1 when text is shown is gone. I have not told your product managers yet, but bootsplash (the .rpm and the implementation) is important for branding.
Technically seen, keeping the background picture on tty1 while showing bootsplash with plymouth shouldn't be too hard. But they are exclusive currently in the package level, unfortunately.
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth.
From what I understand of the way KMS is handled, it would require plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
I'm also not strongly convinced branding tty is THAT important.
Why plymouth is convincing, then? :) We use plymouth (or bootsplash) just because it looks prettier, despite it slowing down the boot. That said, the eye-candy is the only factor. The same logic can be applied to the tty background picture, too. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le vendredi 30 novembre 2012 à 11:22 +0100, Takashi Iwai a écrit :
At Fri, 30 Nov 2012 11:08:55 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit :
On Friday 30 November 2012 10:46:08 Takashi Iwai wrote:
The regression in o:F and SLES will be: semitranslucent background picture on tty1 when text is shown is gone. I have not told your product managers yet, but bootsplash (the .rpm and the implementation) is important for branding.
Technically seen, keeping the background picture on tty1 while showing bootsplash with plymouth shouldn't be too hard. But they are exclusive currently in the package level, unfortunately.
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth.
From what I understand of the way KMS is handled, it would require plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
I'm also not strongly convinced branding tty is THAT important.
Why plymouth is convincing, then? :)
because it is maintained, cross-distro and allow flicker-free transition to X. When I was speaking of branding tty, I was of course speaking of the virtual console, once the boot is finished. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 30 Nov 2012 11:28:10 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 11:22 +0100, Takashi Iwai a écrit :
At Fri, 30 Nov 2012 11:08:55 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit :
On Friday 30 November 2012 10:46:08 Takashi Iwai wrote:
The regression in o:F and SLES will be: semitranslucent background picture on tty1 when text is shown is gone. I have not told your product managers yet, but bootsplash (the .rpm and the implementation) is important for branding.
Technically seen, keeping the background picture on tty1 while showing bootsplash with plymouth shouldn't be too hard. But they are exclusive currently in the package level, unfortunately.
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth.
From what I understand of the way KMS is handled, it would require plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
I'm also not strongly convinced branding tty is THAT important.
Why plymouth is convincing, then? :)
because it is maintained, cross-distro and allow flicker-free transition to X.
It is maintained, but its implementation is... Well let's stop ranting. FWIW, the bootsplash kernel patch has been maintained over 13 years until now. "cross-distro" could be a gain, but only if it reduces the actual maintenance load. The flicker-free transition to X is nothing new, it was already preset at the time of Meego. Basically it's no feature of plymouth but rather a new feature to X. The feature we added was dropped meanwhile since the patch wasn't accepted to X at that time. Now, by some reason, a similar patch was merged, so we are here. One good step forward.
When I was speaking of branding tty, I was of course speaking of the virtual console, once the boot is finished.
Yes, and my point is we can manage the tty background picture easily together with plymouth (suppose plymough doesn't do anything stupid). But in the package level, it's handled as conflicted because the tty background picture handling is currently always tied with kernel bootsplash, and plymouth doesn't cope with others (even X). So, as Raymond suggested, a part of the current bootsplash package can be split or merge into another for keeping only the tty background part, I suppose. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
So, as Raymond suggested, a part of the current bootsplash package can be split or merge into another for keeping only the tty background part, I suppose. Why not work with upstream plymouth to get that feature into plymouth?
2012/11/30 Takashi Iwai <tiwai@suse.de>:
At Fri, 30 Nov 2012 11:28:10 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 11:22 +0100, Takashi Iwai a écrit :
At Fri, 30 Nov 2012 11:08:55 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit :
On Friday 30 November 2012 10:46:08 Takashi Iwai wrote:
> The regression in o:F and SLES will be: semitranslucent > background picture on tty1 when text is shown is gone. > I have not told your product managers yet, but bootsplash > (the .rpm and the implementation) is important for branding.
Technically seen, keeping the background picture on tty1 while showing bootsplash with plymouth shouldn't be too hard. But they are exclusive currently in the package level, unfortunately.
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth.
From what I understand of the way KMS is handled, it would require plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
I'm also not strongly convinced branding tty is THAT important.
Why plymouth is convincing, then? :)
because it is maintained, cross-distro and allow flicker-free transition to X.
It is maintained, but its implementation is... Well let's stop ranting. FWIW, the bootsplash kernel patch has been maintained over 13 years until now.
"cross-distro" could be a gain, but only if it reduces the actual maintenance load.
The flicker-free transition to X is nothing new, it was already preset at the time of Meego. Basically it's no feature of plymouth but rather a new feature to X. The feature we added was dropped meanwhile since the patch wasn't accepted to X at that time. Now, by some reason, a similar patch was merged, so we are here. One good step forward.
When I was speaking of branding tty, I was of course speaking of the virtual console, once the boot is finished.
Yes, and my point is we can manage the tty background picture easily together with plymouth (suppose plymough doesn't do anything stupid). But in the package level, it's handled as conflicted because the tty background picture handling is currently always tied with kernel bootsplash, and plymouth doesn't cope with others (even X).
So, as Raymond suggested, a part of the current bootsplash package can be split or merge into another for keeping only the tty background part, I suppose.
Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 30 Nov 2012 12:30:13 +0100, Damian Ivanov wrote:
So, as Raymond suggested, a part of the current bootsplash package can be split or merge into another for keeping only the tty background part, I suppose. Why not work with upstream plymouth to get that feature into plymouth?
Because the implementation has basically nothing to do with plymouth. The picture on tty is handled in the kernel bootsplash patch. Takashi
2012/11/30 Takashi Iwai <tiwai@suse.de>:
At Fri, 30 Nov 2012 11:28:10 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 11:22 +0100, Takashi Iwai a écrit :
At Fri, 30 Nov 2012 11:08:55 +0100, Frederic Crozat wrote:
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit :
On Friday 30 November 2012 10:46:08 Takashi Iwai wrote: > > The regression in o:F and SLES will be: semitranslucent > > background picture on tty1 when text is shown is gone. > > I have not told your product managers yet, but bootsplash > > (the .rpm and the implementation) is important for branding. > > Technically seen, keeping the background picture on tty1 while showing > bootsplash with plymouth shouldn't be too hard. But they are > exclusive currently in the package level, unfortunately.
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth.
From what I understand of the way KMS is handled, it would require plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
I'm also not strongly convinced branding tty is THAT important.
Why plymouth is convincing, then? :)
because it is maintained, cross-distro and allow flicker-free transition to X.
It is maintained, but its implementation is... Well let's stop ranting. FWIW, the bootsplash kernel patch has been maintained over 13 years until now.
"cross-distro" could be a gain, but only if it reduces the actual maintenance load.
The flicker-free transition to X is nothing new, it was already preset at the time of Meego. Basically it's no feature of plymouth but rather a new feature to X. The feature we added was dropped meanwhile since the patch wasn't accepted to X at that time. Now, by some reason, a similar patch was merged, so we are here. One good step forward.
When I was speaking of branding tty, I was of course speaking of the virtual console, once the boot is finished.
Yes, and my point is we can manage the tty background picture easily together with plymouth (suppose plymough doesn't do anything stupid). But in the package level, it's handled as conflicted because the tty background picture handling is currently always tied with kernel bootsplash, and plymouth doesn't cope with others (even X).
So, as Raymond suggested, a part of the current bootsplash package can be split or merge into another for keeping only the tty background part, I suppose.
Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2012-11-30 12:17, Takashi Iwai wrote:
So, as Raymond suggested, a part of the current bootsplash package can be split or merge into another for keeping only the tty background part, I suppose.
If I get background picture while there's the boot text scrolling through, I'll take that anytime over plymouth :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 30 November 2012 11:08:55 Frederic Crozat wrote:
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth. From what I understand of the way KMS is handled, it would require
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit : plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
Hi Frederic, I just tried a couple of things and it seems quite easy to get the required background picture on tty1. However I hope that one of the bootsplash maintainers can help me out to complete it. If I run splash -s -u 0 <config-file>, then I get the picture on tty1, however this is in silent-mode. I need to press Esc, to get the login-prompt. I am however not sure how to configure it to directly have the login-prompt there. So if this is an important branding, then it seems we could get this done. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 30 Nov 2012 12:05:53 +0100, Raymond Wooninck wrote:
On Friday 30 November 2012 11:08:55 Frederic Crozat wrote:
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth. From what I understand of the way KMS is handled, it would require
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit : plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
Hi Frederic,
I just tried a couple of things and it seems quite easy to get the required background picture on tty1. However I hope that one of the bootsplash maintainers can help me out to complete it.
If I run splash -s -u 0 <config-file>, then I get the picture on tty1, however this is in silent-mode. I need to press Esc, to get the login-prompt. I am however not sure how to configure it to directly have the login-prompt there.
Doesn't it work without -s? Takashi
So if this is an important branding, then it seems we could get this done.
Regards
Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 30 November 2012 12:37:53 Takashi Iwai wrote:
At Fri, 30 Nov 2012 12:05:53 +0100,
Raymond Wooninck wrote:
If I run splash -s -u 0 <config-file>, then I get the picture on tty1, however this is in silent-mode. I need to press Esc, to get the login-prompt. I am however not sure how to configure it to directly have the login-prompt there. Doesn't it work without -s?
Nope. Checking the splash source, it is clearly reading the kernel boot options and determines the initial state from there. Have to see what is exactly required by plymouth, but otherwise we could easily adjust the source. I will test a little more and then I could integrate it into the plymouth package. I have to see however how I can determine the right config file (screen size) to take. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 30 Nov 2012 12:58:43 +0100, Raymond Wooninck wrote:
On Friday 30 November 2012 12:37:53 Takashi Iwai wrote:
At Fri, 30 Nov 2012 12:05:53 +0100,
Raymond Wooninck wrote:
If I run splash -s -u 0 <config-file>, then I get the picture on tty1, however this is in silent-mode. I need to press Esc, to get the login-prompt. I am however not sure how to configure it to directly have the login-prompt there. Doesn't it work without -s?
Nope. Checking the splash source, it is clearly reading the kernel boot options and determines the initial state from there. Have to see what is exactly required by plymouth, but otherwise we could easily adjust the source.
I will test a little more and then I could integrate it into the plymouth package. I have to see however how I can determine the right config file (screen size) to take.
Check the size via fbresolution? It's nothing but a single ioctl(FBIOGET_VSCREENINFO) to /dev/fb0, so not necessarily to be in that binary form, though. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 30 Nov 2012 12:37:53 +0100, Takashi Iwai wrote:
At Fri, 30 Nov 2012 12:05:53 +0100, Raymond Wooninck wrote:
On Friday 30 November 2012 11:08:55 Frederic Crozat wrote:
I guess the better approach would be to split off from bootsplash the functionality that creates this background picture on tty1 and then package it within the branding packages ? Or we can make it even part of plymouth. From what I understand of the way KMS is handled, it would require
Le vendredi 30 novembre 2012 à 10:50 +0100, Raymond Wooninck a écrit : plymouth (or something) to keep running or at least, keep a FD open (and I'm not sure how the tty would react).
Hi Frederic,
I just tried a couple of things and it seems quite easy to get the required background picture on tty1. However I hope that one of the bootsplash maintainers can help me out to complete it.
If I run splash -s -u 0 <config-file>, then I get the picture on tty1, however this is in silent-mode. I need to press Esc, to get the login-prompt. I am however not sure how to configure it to directly have the login-prompt there.
Doesn't it work without -s?
And, in case it doesn't work, try below echo verbose > /proc/splash If you want to change the state of the VT2, echo "@1 verbose" > /proc/splash and to show the silent picture echo "@1 silent" > /proc/splash Takashi
Takashi
So if this is an important branding, then it seems we could get this done.
Regards
Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.11.2012 13:03, schrieb Takashi Iwai:
And, in case it doesn't work, try below echo verbose > /proc/splash
If you want to change the state of the VT2, echo "@1 verbose" > /proc/splash and to show the silent picture echo "@1 silent" > /proc/splash
If we only use it for TTY1 background, we probably could do away with the silent picture -- it surely wastes some bytes of nonswappable kernel memory ;-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 30 November 2012 13:18:55 Stefan Seyfried wrote:
If we only use it for TTY1 background, we probably could do away with the silent picture -- it surely wastes some bytes of nonswappable kernel memory ;-)
Don't worry. I will strip it to its bare bones before packaging it :-) Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Nov 30, 2012 at 4:19 PM, Raymond Wooninck <tittiatcoke@gmail.com> wrote:
Don't worry. I will strip it to its bare bones before packaging it :-)
Will it be optional? Can it be implemented as kernel module so those who do not need it do not use it? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 30 November 2012 16:47:45 Andrey Borzenkov wrote:
On Fri, Nov 30, 2012 at 4:19 PM, Raymond Wooninck <tittiatcoke@gmail.com> wrote:
Don't worry. I will strip it to its bare bones before packaging it :-)
Will it be optional? Can it be implemented as kernel module so those who do not need it do not use it?
Hi Andrey, :-) This will be definitely optional and it depends on the user whether or not to install it. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 30 Nov 2012 13:18:55 +0100, Stefan Seyfried wrote:
Am 30.11.2012 13:03, schrieb Takashi Iwai:
And, in case it doesn't work, try below echo verbose > /proc/splash
If you want to change the state of the VT2, echo "@1 verbose" > /proc/splash and to show the silent picture echo "@1 silent" > /proc/splash
If we only use it for TTY1 background, we probably could do away with the silent picture -- it surely wastes some bytes of nonswappable kernel memory ;-)
Just call: echo freesilent > /proc/splash Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Alin M Elena -
Andrey Borzenkov -
Damian Ivanov -
Dr. Werner Fink -
Frederic Crozat -
Jan Engelhardt -
Raymond Wooninck -
Stefan Seyfried -
Takashi Iwai