Timeline for Excessively slow boot after normal shutdown, but not after forced power off
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 11, 2020 at 16:43 | vote | accept | phunsoft | ||
| Dec 11, 2020 at 16:40 | answer | added | phunsoft | timeline score: 1 | |
| Dec 10, 2020 at 15:27 | history | edited | phunsoft | CC BY-SA 4.0 | Adding comment that I consider this question as "closed". |
| Dec 9, 2020 at 12:27 | comment | added | phunsoft | Thanks for the pointers; will update late. However, a boot from power-off after normal shutdown does show the problem, but a boot from power-off after killing the system (forcing power-off) does not show any problem. Would that be explainable with framebuffer or driver problems? I would think the state of the machine with regards to hardware and drivers is the same at boot time in both cases. But, thanks a lot.I'll do some research regarding framebuffer and radeon. | |
| Dec 9, 2020 at 12:09 | comment | added | mchid | This is just a guess but you might want to look into framebuffer issues with radeon and long boot times. I'm sure there's probably a bug and a workaround or fix somewhere. It would probably be a good idea to update (edit) your question to include the processer and GPU specs and also which drivers are in use. | |
| Dec 8, 2020 at 8:36 | comment | added | phunsoft | In the meantime, I have found a circumvention to the problem: Removing the splash parameter from the kernel parameter list in the grub entry. No splash, no delay. However, I do want that splash screen (the machine is not for me), so the problem is not solved: What is different in relation to plymouth between a system cleanly shut down and one that was killed by forcing power-off? | |
| Dec 6, 2020 at 15:44 | comment | added | phunsoft | Thanks for that. Running the blame command showed plymount-read-write.service to be the culprit; it takes 2.5 minutes to be ready. I googled this and found only entries talking about plymouth-quit-wait.service. So, what the heck might plymouth-read-write.service be waiting for? I did the same analysis for the "normal" boot, and that service was ready after 50ms. | |
| Dec 6, 2020 at 14:14 | comment | added | mchid | systemd-analyze blame and systemd-analyze critical-chain or systemd-analyze critical-chain followed by a service name can sometimes give more information than dmesg | |
| Dec 5, 2020 at 10:07 | review | First posts | |||
| Dec 6, 2020 at 8:58 | |||||
| Dec 5, 2020 at 10:04 | history | asked | phunsoft | CC BY-SA 4.0 |