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 SUSE -- 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 SUSE -- 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

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 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: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

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

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 :

...

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 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

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: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

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 Friday 30 November 2012 16:47:45 Andrey Borzenkov wrote:

On Fri, Nov 30, 2012 at 4:19 PM, Raymond Wooninck 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