Re: [systemd-devel] Unable to boot Linux distribution ISO files that have systemd services
On Mi, 01.09.21 11:39, EpicLemon99 (epiclemo...@protonmail.com) wrote: > I am unable to boot up ISO files of Linux distributions that use systemd. My > computer is a HP Pavilion TG01-2856no, it is recent hardware. The boot gets > stuck when it tries to start systemd services, such as Network Time > Synchronization. > > For example, there are the messages I get when trying to boot up the Arch > Linux ISO: https://imgur.com/a/oKGjZk7 > > Booting it with the kernel argument init=/bin/bash however works. The second screenshot shows that you have some kernel issue, i.e. the upper part of the screen shows kernel debug output that happens on kernel oops. i.e. it's a driver issue, and systemd hangs simply because the kernel hangs/crashed. Please work with your distro, they might be able to help. Kernel/driver issues like this are out of scope for systemd though. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Unable to boot Linux distribution ISO files that have systemd services
I am unable to boot up ISO files of Linux distributions that use systemd. My computer is a HP Pavilion TG01-2856no, it is recent hardware. The boot gets stuck when it tries to start systemd services, such as Network Time Synchronization. For example, there are the messages I get when trying to boot up the Arch Linux ISO: https://imgur.com/a/oKGjZk7 Booting it with the kernel argument init=/bin/bash however works.
Re: [systemd-devel] Unable to boot Linux distribution ISO files that have systemd services
On Wed, Sep 1, 2021 at 2:40 PM EpicLemon99 wrote: > I am unable to boot up ISO files of Linux distributions that use systemd. > My computer is a HP Pavilion TG01-2856no, it is recent hardware. The boot > gets stuck when it tries to start systemd services, such as Network Time > Synchronization. > > For example, there are the messages I get when trying to boot up the Arch > Linux ISO: https://imgur.com/a/oKGjZk7 > > Booting it with the kernel argument init=/bin/bash however works. Boot it with the 'systemd.debug-shell' option and take a look (via tty9) at what systemd-udevd is doing. I'm guessing that one of its worker processes tried to interact with a device (e.g. read information from /sys or do some active probing), but due to either hardware issue or driver bug, the syscall got stuck in the kernel and never returned. So check /proc/PID/stack of the udev worker processes, I guess? (The same issue might be occurring even on installed systems, only they don't *wait* for udev to finish handling every single device (systemd-udev-settle), so the process might just remain hung in background.) -- Mantas Mikulėnas
