search

blue-systems / neon-pinebook-remix

Todos for Neon Pinebook Remix
3 stars 0 forks source link

boot: 0404-1031 goes to text login, not plasma desktop #72

Closed adriaandegroot closed 6 years ago

adriaandegroot commented 6 years ago

Latest image (0404-1031) went to text login after boot, not to plasma desktop. From text prompt, sudo sddm started the desktop as expected.

Previous image (0404-0549) went to plasma desktop once boot was fixed.

davidedmundson commented 6 years ago

I flashed, got the same behaviour.

Then rebooted and it went straight to plasma Then again and again and it kept working.

bhush9 commented 6 years ago

Can either of you figure out why this happens? :D I can't do much without pinebook here.

davidedmundson commented 6 years ago

I can't do much without pinebook here.

That seems like a valid excuse.

It's going to be hard to figure out given it means flashing from scratch each time, but I'll give it a go

star-buck commented 6 years ago

@Bhushan: any chance to get a pinebook to your place? Ebay? Are you coming to the sprint?

bhush9 commented 6 years ago

Um, it's terribly hard to get pinebook from here, on ebay I had found an listing : http://www.ebay.in/geb/ImportHubViewItem?itemid=263140303914 but it was 5X cost and when I found it it was already sold out. I had also found a listing on .co.uk but it didn't ship to India and had similar price as one shown above..

I am coming to sprint yes.

notmart commented 6 years ago

It's going to be hard to figure out given it means flashing from scratch each time, but I'll give it a go

plasma crashing only during the initial javascript setup?

will download the image and try if just deleting appletsrc repeats the issue

bhush9 commented 6 years ago

plasma crashing only during the initial javascript setup?

No, it doesn't even reach plasma.. somehow just SDDM bails out..

notmart commented 6 years ago

is the home existing and complete at that point?

bhush9 commented 6 years ago

What we know

18:13 <dreisner> bshah: perhaps graphical.target isn't the default for the first boot.
18:14 <bshah> if I check systemctl get-default , it's graphical.target
18:14 <dreisner> bshah: i'm suggesting that maybe something during the boot process changes the default on first boot, but the actual first boot target is NOT graphical.
18:15 <bshah> ah.. that might be quite possible

I am yet to verify if this is case

Doing systemctl enable sddm in image also doesn't have any effect

llelectronics commented 6 years ago

For the sddm issue. Just because I just saw it here and it does not come up on the rock64 aswell without it: https://github.com/netrunner-zeronet/rock64-live-build-zeronet/blob/master/customization/hooks/live/02-add-sddm-to-video.hook.chroot

Make sure the live user is part of the video group.

bhush9 commented 6 years ago

Some more case checking. I tested that there is no /etc/systemd/system/default.target symlink. I've tried adding manual systemctl set-default graphical.target in hook... let's see.

bhush9 commented 6 years ago

So at end of day.. current investigation

ExecStartPre=/bin/sh -c '[ "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/sddm" ]'

from sddm.service ... didn't work

Some response:

2018-05-03 16:13:06     <grawity>       May 03 10:13:22 localhost.localdomain systemd[1]: sddm.service: Fixing conflicting jobs sddm.service/start,sddm.service/stop by deleting job sddm.service/stop
2018-05-03 16:13:15     <grawity>       that was a quick grep.
2018-05-03 16:14:02     <grawity>       you've got a dependency loop, involving sddm + plymouth, and they're resolved by skipping a random job
2018-05-03 16:14:18     <grawity>       May 03 10:15:13 live-pc systemd[1]: sddm.service: Job sddm.service/start finished, result=canceled
2018-05-03 16:14:19     <grawity>       May 03 10:15:13 live-pc systemd[1]: sddm.service: Installed new job sddm.service/stop as 225

After I spent some more time grawity noticed something else...

2018-05-03 18:31:25     <grawity>       bshah: more importantly than the loop, it seems that something in your boot process activates plymouth-quit-wait.service
2018-05-03 18:31:36     <grawity>       bshah: and sddm directly conflicts with that
2018-05-03 18:32:17     <bshah> oh
2018-05-03 18:32:53     <grawity>       actually, I think that's what causes *all* messages, it's not a loop

Later...

2018-05-03 18:43:02     <bshah> oh! ./lib/systemd/system/multi-user.target.wants/plymouth-quit-wait.service (!!!) could it be a thing triggering plymouth-quit-wait.service grawity ?
2018-05-03 18:43:32     <grawity>       bshah: yes
2018-05-03 18:49:01     <bshah> grawity: so the way I see is break sddm depends/conflicts to plymouth-quit-wait.service ? since it depends on multi-user.target and ubuntu/bionic multi-user.target.wants already depends on plymouth-quit-wait.service (symlink provided by plymouth package).
2018-05-03 18:49:46     <grawity>       tbh, I'm not 100% sure
2018-05-03 18:50:16     <grawity>       what I seemed to find in the logs was that the problem kinda happened *twice* during the same boot
2018-05-03 18:50:53     <grawity>       conflict gets resolved somehow, boot continues, and suddenly another conflict causes sddm to be cancelled
2018-05-03 18:52:16     <bshah> another problem might be getty service I think
2018-05-03 18:52:22     <bshah> there is conflict on it too in sddm service
2018-05-03 18:52:58     <grawity>       or it could be that, yeah... but
2018-05-03 18:53:14     <grawity>       well, now that I think of it, somehow it works fine with gdm
2018-05-03 18:53:37     <grawity>       so maybe Conflicts= was designed to be deterministic, I guess?
2018-05-03 18:54:00     <grawity>       if both are queued at the same time, sddm wins
2018-05-03 18:54:15     <bshah> annoying thing is this breaks ONLY on first boot..
2018-05-03 18:54:20     <grawity>       but if sddm is already starting, and something tries to start plymouth (or getty)

So I spent some time trying to disable plymouth dep from the sddm service... which also failed..

meantime i found out that plymouth is not even used in the kernel.. as there is no quiet splash option in kernel command line.

For better debugging i added following to kernel cmdline

console=tty0 systemd.log_level=debug systemd.log_target=kmsg

I am not sure what to do next, but perhaps sleeping over some ideas will give some more thought on what might be wrong.

bhush9 commented 6 years ago

Okay so I tried something and it seems to be "working" , working in double quotes because plasma is super slow at startup for some reason... BUT..

Things now load instead of completely fail to load, and we have idea of what is wrong...

Optional (if you want to watch logs.. as this sometimes get stuck doing live-config job forever.)

bhush9 commented 6 years ago

Edit : new link to 0170-systemd ; https://ptpb.pw/PbAm

bhush9 commented 6 years ago

Try #3 to get rid of long delay : https://ptpb.pw/j2i_

davidedmundson commented 6 years ago

Booted first time \o/

bhush9 commented 6 years ago

https://files.kde.org/neon/images/pinebook-remix-nonfree/bionic/20180504-1120/

This image fixes it..

Appearantly we were shipping some file which was not needed and was conflicting with something else doing exactly same thing.. https://github.com/pangea-project/pangea-tooling/commit/a7735f01c3ae8951a1ed858bdabfeee5f9e1bd6d which had bugs.. my last attempt was to fix bug but realized this code is no longer needed at all..

bhush9 commented 6 years ago

Keep in mind tha plasma startup is super slow for some reason and needs debugging, but it is seperate issue.