[opensuse-factory] Next snapshot with updated systemd and plymouth
Hi all, openqa seems to be quite satisfied with the new snapshot. On a local test, however, I still get no password prompt in my setup. So will live with plymouth.enable=0 as boot parameter. Cheers, Robby. --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/29/17 00:23, Robby Engelmann wrote:
openqa seems to be quite satisfied with the new snapshot. On a local test, however, I still get no password prompt in my setup. So will live with plymouth.enable=0 as boot parameter.
I assume that is about 20170128. And, yes, no prompt for encryption key here. Booting the previous kernel did not help. So I changed "splash=silent" to "nosplash" in "grub.cfg". That worked. So I later made the same change in "/etc/default/grub". I'm not sure if this is a plymouth bug or a systemd bug, since both appear to have been updated for this snapshot. Is there an open bug report on this? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJYjm8wAAoJEGSXLIzRJwiFN2gH/2wVzMuDu0nn9uSZvdlfjgrO F4kpMvpHknTS9Z9XG7pA/Bl8kEzuyfflBaLrIXhyyTEUwpsWbtQE2WyWoO1PRF3d tMh5BC2S0BGQ04hvTPboHa6WOgMOUo4xP6+/bLaNJAHe7R/4AVlu+zgY1Gbw3Tat pX5bs9NqaqIFbxxTRvLmEvACLr1sIRG9+26uagMX314KvFyxSWyJOUB1B4pGy4/Y 4TeboSMB97cXxwr3I9gCP16Kppaoga8vFnAr7sIrDtU/S2at3kiiX7zfTXwMvRPs J33qPDw3YE3fVuouhJ4UpHRA/VhVdp9clXiPVoLH6unvZn/SSpg20xQ3gaZiMHk= =9B4j -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Interestingly enough, I tested with snapshot 20170129, and now it works again.... Cheers, Robby. -- On Sonntag, 29. Januar 2017 16:39:44 CET Neil Rickert wrote:
On 01/29/17 00:23, Robby Engelmann wrote:
openqa seems to be quite satisfied with the new snapshot. On a local test, however, I still get no password prompt in my setup. So will live with plymouth.enable=0 as boot parameter.
I assume that is about 20170128.
And, yes, no prompt for encryption key here. Booting the previous kernel did not help.
So I changed "splash=silent" to "nosplash" in "grub.cfg". That worked. So I later made the same change in "/etc/default/grub".
I'm not sure if this is a plymouth bug or a systemd bug, since both appear to have been updated for this snapshot. Is there an open bug report on this?
It only seems to work sporadically. I again started without plymouth.enable=0 which worked two times and then four times I only got the blackscreen with blinking cursor. Cheers, Robby. -- On Montag, 30. Januar 2017 06:36:19 CET Robby Engelmann wrote:
Interestingly enough, I tested with snapshot 20170129, and now it works again....
Cheers, Robby.
On 01/29/17 00:23, Robby Engelmann wrote:
openqa seems to be quite satisfied with the new snapshot. On a local test, however, I still get no password prompt in my setup. So will live with plymouth.enable=0 as boot parameter.
I assume that is about 20170128.
And, yes, no prompt for encryption key here. Booting the previous kernel did not help.
So I changed "splash=silent" to "nosplash" in "grub.cfg". That worked. So I later made the same change in "/etc/default/grub".
I'm not sure if this is a plymouth bug or a systemd bug, since both appear to have been updated for this snapshot. Is there an open bug report on this?
On Mon, 2017-01-30 at 07:02 +0100, Robby Engelmann wrote:
It only seems to work sporadically. I again started without plymouth.enable=0 which worked two times and then four times I only got the blackscreen with blinking cursor.
Is there a bugzilla for this yet? I've been bitten by the same thing.
Tried to reproduce it on a VM, but unfortunately all is working nicely
there, so it seems to be a more subtle problem. Current workaround is
"plymouth.enable=0".
Martin
--
Dr. Martin Wilck
You may want to have a look here: https://bugzilla.novell.com/show_bug.cgi?id=1020283 -- On Dienstag, 31. Januar 2017 14:13:15 CET Martin Wilck wrote:
On Mon, 2017-01-30 at 07:02 +0100, Robby Engelmann wrote:
It only seems to work sporadically. I again started without plymouth.enable=0 which worked two times and then four times I only got the blackscreen with blinking cursor.
Is there a bugzilla for this yet? I've been bitten by the same thing. Tried to reproduce it on a VM, but unfortunately all is working nicely there, so it seems to be a more subtle problem. Current workaround is "plymouth.enable=0".
Martin
On 01/29/17 23:36, Robby Engelmann wrote:
Interestingly enough, I tested with snapshot 20170129, and now it works again....
Thanks. (And, yes, I saw your other message). I think I'll just keep "nosplash" anyway. Plymouth hasn't been working well (I get the text most splash screen around 60% of the time). It looks as if plymouth is still handling the crypto, even with "nosplash". Or, at least, I am only prompted once even though I have two LUKS partitions with the same key.
Neil Rickert composed on 2017-01-30 10:16 (UTC-0600):
I think I'll just keep "nosplash" anyway.
"nosplash"=""="splash=0" IOW, default splash is null. Splash is an optional addon. You need splash to get splash. You need nothing to not get splash. All that said, Plymouth is a relatively youthful alternative to a very ancient Linux boot splash, and I don't know that nosplash or splash=0 do not or cannot function as a Plymouth disabler if Plymouth is installed. My installations exclude Plymouth. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/30/17 17:13, Felix Miata wrote:
Neil Rickert composed on 2017-01-30 10:16 (UTC-0600):
All that said, Plymouth is a relatively youthful alternative to a very ancient Linux boot splash, and I don't know that nosplash or splash=0 do not or cannot function as a Plymouth disabler if Plymouth is installed. My installations exclude Plymouth.
Yes, "nosplash" does disable showing the plymouth splash. But perhaps plymouth still runs without showing any splash. In any case, I have no uninstalled plymouth, and tabooed it so that it won't reinstall. The "initrd" is rebuilt. Everything is still working well. I have two LUKS partitions with the same key. I am still only prompted once for that key. So possibly "systemd" is now handling the reuse of the provided key. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Neil Rickert composed on 2017-01-30 23:25 (UTC-0600):
Yes, "nosplash" does disable showing the plymouth splash. But perhaps plymouth still runs without showing any splash.
In any case, I have no uninstalled plymouth, and tabooed it so that it won't reinstall. The "initrd" is rebuilt.
To see for yourself whether the nosplash parameter actually does anything when Plymouth is not installed, boot once with everything stripped from the kernel cmdline. I expect you'll end up with "white" text characters on black background on your vtty1 init screen in your display's native resolution, 240 columns by 67 rows if on a 1920x1080 screen. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jan 31, 2017 at 8:25 AM, Neil Rickert
Yes, "nosplash" does disable showing the plymouth splash. But perhaps plymouth still runs without showing any splash.
Correct. To completely prevent plymouth from loading use plymouth.enable=0. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday, January 29, 2017 4:39:44 PM CST Neil Rickert wrote:
I assume that is about 20170128.
And, yes, no prompt for encryption key here. Booting the previous kernel did not help.
So I changed "splash=silent" to "nosplash" in "grub.cfg". That worked. So I later made the same change in "/etc/default/grub".
I'm not sure if this is a plymouth bug or a systemd bug, since both appear to have been updated for this snapshot. Is there an open bug report on this?
I filed a report on this on my desktop installation last November. Then uninstalled plymouth as a dirty workaround. The new update seems to have installed plymouth on my desktop, which works as expected, and yet the plymouth instance on my laptop which has been working flawlessly for some time is now the one experiencing this issue. Anyway, bug report for you all to add your experiences to: https://bugzilla.opensuse.org/show_bug.cgi?id=997200
On Sunday, January 29, 2017 7:23:00 AM CET Robby Engelmann wrote:
plymouth.enable=0 Hey Everyone,
I on my Asus X750JA box am also suffering from this problem. And it indeed seems like Robby's solution seems to fix this problem. I did manage to extract te follownig messages from my journalctl: ``` an 30 21:16:06 linux-ihhb systemd[1]: Starting Show Plymouth Boot Screen... Jan 30 21:16:06 linux-ihhb plymouth[371]: error: unexpectedly disconnected from boot status daemon Jan 30 21:16:06 linux-ihhb systemd[1]: plymouth-start.service: Main process exited, code=killed, status=11/SEGV Jan 30 21:16:06 linux-ihhb systemd[1]: Failed to start Show Plymouth Boot Screen. Jan 30 21:16:06 linux-ihhb systemd[1]: plymouth-start.service: Unit entered failed state. Jan 30 21:16:06 linux-ihhb systemd[1]: plymouth-start.service: Failed with result 'signal'. Jan 30 21:16:18 linux-ihhb systemd[1]: Starting Show Plymouth Boot Screen... Jan 30 21:16:28 linux-ihhb systemd[1]: Starting Show Plymouth Boot Screen... Jan 30 21:16:29 linux-ihhb plymouth[1015]: error: unexpectedly disconnected from boot status daemon Jan 30 21:16:29 linux-ihhb systemd[1]: plymouth-start.service: Main process exited, code=dumped, status=11/SEGV Jan 30 21:16:29 linux-ihhb systemd[1]: Failed to start Show Plymouth Boot Screen. Jan 30 21:16:29 linux-ihhb systemd[1]: plymouth-start.service: Unit entered failed state. Jan 30 21:16:29 linux-ihhb systemd[1]: plymouth-start.service: Failed with result 'core-dump'. ~ ``` Hope fully this will clear something up. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello all, I've been using Tumbleweed since it was announced, and I think this is the first time I was left with an un-bootable system. I was getting a blinking cursor and no way to go further. Disabling plymouth didn't work, uninstalling it (via a rescue system) didn't work. In fact when I tried the latest Tumbleweed rescue system, even that refused to boot, it was showing the same issue, where I would end up with a blinking cursor and nothing else. Finally what seems to have worked for me is this advice: https://bbs.archlinux.org/viewtopic.php?pid=1669249#p1669249 The partition names (not labels) on my disk were garbage characters. After fixing that using the 'name' command in 'parted' everything seems to be working. On 01/31/2017 01:56 AM, jeroenmathonmac@gmail.com wrote:
On Sunday, January 29, 2017 7:23:00 AM CET Robby Engelmann wrote:
plymouth.enable=0 Hey Everyone,
I on my Asus X750JA box am also suffering from this problem. And it indeed seems like Robby's solution seems to fix this problem.
I did manage to extract te follownig messages from my journalctl: ``` an 30 21:16:06 linux-ihhb systemd[1]: Starting Show Plymouth Boot Screen... Jan 30 21:16:06 linux-ihhb plymouth[371]: error: unexpectedly disconnected from boot status daemon Jan 30 21:16:06 linux-ihhb systemd[1]: plymouth-start.service: Main process exited, code=killed, status=11/SEGV Jan 30 21:16:06 linux-ihhb systemd[1]: Failed to start Show Plymouth Boot Screen. Jan 30 21:16:06 linux-ihhb systemd[1]: plymouth-start.service: Unit entered failed state. Jan 30 21:16:06 linux-ihhb systemd[1]: plymouth-start.service: Failed with result 'signal'. Jan 30 21:16:18 linux-ihhb systemd[1]: Starting Show Plymouth Boot Screen... Jan 30 21:16:28 linux-ihhb systemd[1]: Starting Show Plymouth Boot Screen... Jan 30 21:16:29 linux-ihhb plymouth[1015]: error: unexpectedly disconnected from boot status daemon Jan 30 21:16:29 linux-ihhb systemd[1]: plymouth-start.service: Main process exited, code=dumped, status=11/SEGV Jan 30 21:16:29 linux-ihhb systemd[1]: Failed to start Show Plymouth Boot Screen. Jan 30 21:16:29 linux-ihhb systemd[1]: plymouth-start.service: Unit entered failed state. Jan 30 21:16:29 linux-ihhb systemd[1]: plymouth-start.service: Failed with result 'core-dump'. ~ ```
Hope fully this will clear something up.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On 01/31/2017 04:46 PM, Kshitij Sobti wrote:
Finally what seems to have worked for me is this advice: https://bbs.archlinux.org/viewtopic.php?pid=1669249#p1669249
The partition names (not labels) on my disk were garbage characters.
Any idea on how this could have happened ? Thanks. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02/01/2017 09:58 AM, Franck Bui wrote:
The partition names (not labels) on my disk were garbage characters.
Any idea on how this could have happened ?
Ok I think you've been hit by: https://github.com/systemd/systemd/issues/4747 I don't think that the problem was about "garbage" characters but rather than the resulting device name was exceeding the limit for unit name length. I'll include the fix for the next update. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On 02/01/2017 05:46 PM, Franck Bui wrote:
On 02/01/2017 09:58 AM, Franck Bui wrote:
The partition names (not labels) on my disk were garbage characters.
Any idea on how this could have happened ?
I can't be entirely certain, but I strongly believe that it was because I used a tool called gptgen (I think) to convert my old MBR disk to GPT without data loss. I think this is the case because only older partitions from before the conversion seem to have this issue.
Ok I think you've been hit by: https://github.com/systemd/systemd/issues/4747
I don't think that the problem was about "garbage" characters but rather than the resulting device name was exceeding the limit for unit name length.
I'll include the fix for the next update.
The bug does seem to describe the issue I faced. In my case though, all the disk labels were fine, it's the partition names that were invalid. Thanks for including the fix! And generally thanks to everyone who works on this project, it doesn't get said enough. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello! Can someone check, please, if [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1012142 is reproduced on new version? Thanks! 29.01.2017 08:23, Robby Engelmann пишет:
Hi all,
openqa seems to be quite satisfied with the new snapshot. On a local test, however, I still get no password prompt in my setup. So will live with plymouth.enable=0 as boot parameter.
Cheers, Robby.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
Andrei Borzenkov -
Chan Ju Ping -
Felix Miata -
Franck Bui -
jeroenmathonmac＠gmail.com -
Kshitij Sobti -
Martin Wilck -
Mikhail Kasimov -
Neil Rickert -
Robby Engelmann