You are not logged in.
Hello,
if i install the follow "pacman -Syu" my System will not start again.
pacman -Syu
:: Synchronisiere Paketdatenbanken...
core 196,1 KiB 827K/s 00:00 [################################] 100%
extra 2,5 MiB 733K/s 00:04 [################################] 100%
community 6,1 MiB 748K/s 00:08 [################################] 100%
:: Starte vollständige Systemaktualisierung...
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...
Pakete (44) abiword-3.0.2-9.0 archlinux32-keyring-20190108-1.0 avahi-0.7+18+g1b5f401-1.0
bash-5.0.0-1.4 bc-1.07.1-3.3 curl-7.63.0-4.0 fuse-common-3.4.1-1.0 gawk-4.2.1-2.3
gdbm-1.18.1-2.3 gnupg-2.2.12-2.0 gnutls-3.6.5-4.1 guile-2.2.4-2.0
hunspell-1.7.0-2.0 iana-etc-20181219-1.0 inetutils-1.9.4-7.1
iputils-20180629.f6aac8d-3.1 jack-0.125.0-7.0 js52-52.9.0-2.0 libidn2-2.1.0-1.1
libpsl-0.20.2-3.0 libpulse-12.2-2.4 libsystemd-240.34-3.1 libteam-1.28-2.0
libutil-linux-2.33.1-1.0 libxml2-2.9.8-8.3 libxslt-1.1.33-1.0 lvm2-2.02.183-2.4
networkmanager-1.14.5dev+17+gba83251bb-2.0 pacman-5.1.2-2.0
pacman-mirrorlist-20181003-1.2 pango-1:1.42.4-1.0 parted-3.2-8.0 pcre-8.42-2.0
pcre2-10.32-2.0 python-3.7.2-3.0 readline-8.0.0-1.1 s-nail-14.9.11-2.1
shadow-4.6-2.0 sqlite-3.26.0-2.0 systemd-240.34-3.1 util-linux-2.33.1-2.3
wget-1.20.1-2.0 wpa_supplicant-2:2.6-2.0 xfsprogs-4.19.0-2.3
Gesamtgröße des Downloads: 89,76 MiB
Gesamtgröße der installierten Pakete: 416,49 MiB
Größendifferenz der Aktualisierung: 3,92 MiB
:: Installation fortsetzen? [J/n] Now i go back to systemrelease 2019-01-04.
When i schould try it again to get a working System?
Greetz
arch32yes
Last edited by arch32yes (2019-05-11 20:37:58)
Offline
Can you tell us what happens when you try to boot an updated system? Is there any error message you can relate that would help us to figure out what's wrong?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
The System boot very long, than i get a blackscreen. :-(
Offline
Okay, so I guess it's loaded the initcpio and the kernel, and probably starting services at it brings the system up, only blanking the screen when it tries to start X. Assuming you do boot to graphical, you can disable your display manager by chrooting onto the filesystem using a live cd, then systemctl disable dm.service, replacing dm with the name of your display manager.
When you reboot, that should let you log in to the terminal, and from there you can even startx manually and see if that works. Debugging anything like this, it tends to help if you can boot to something you can use, even if as primitive as a local tty.
My guesses that maybe something boot critical like systemd or python had gone bad seem unfounded.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
What kind of login manager are you using: lightdm and gtk-greeter are currently broken. Use another greeter or sddm or slim..
Does the machine gome up in non-GUI mode (nomodeset in kernel command line)?
Offline
What kind of login manager are you using: lightdm and gtk-greeter are currently broken. Use another greeter or sddm or slim..
Does the machine gome up in non-GUI mode (nomodeset in kernel command line)?
Hi.
Been tracking this for a few hours now after wasting a day or so reinstalling a system. Seems it is systemd 240 that is the problem. I've read downgrading it to 239 "fixes" the lightdm/gtk-greeter issue. Haven't tried, though, as I disabled the lightdm service and launched a simple startx session to get to desktop.
Offline
Hello, i use the lightdm login manager, my dekstop is LXQt.
Question: Does the machine gome up in non-GUI mode (nomodeset in kernel command line)?
I didn`t what you mean.
Now i will wait for the next big upgrade.
Greetz
arch32yes
Last edited by arch32yes (2019-01-18 20:08:04)
Offline
As the user above states, apparently you can work around the break between lightdm and the updated systemd by downgrading systemd (and related packages, I assume). Nomodeset (applied in your bootloader menu normally) delays switching the graphics card high resolution modes, and instead boots entirely in the bios graphics modes, and only actually switches to high graphics when X graphics start. Without nomodeset, you see the switch half way through it bringing up services after loading the kernel, and starts printing the boot messages in high resolution mode (it starts off in the old VGA 640x256 mode, I think).
I assume Andreas was asking whether you were forgoing that kernel mode setting and instead relying on the older teqhnique of using X to change to a graphics card mode. That used to be more common when the kernel didn't always get it right, I assume, but these days is more uncommon, and relying on X to handle it might be less well tested.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Another option is to use sddm or slim as login manager or any other login manager
having less dependencies than half of Gnome or half of Webkit.
nomodeset was just an idea to get around kernel mode switching (KMS), to see, if the kernel
or systemd gets stuck. For startx to work you have to be in KMS-mode, nomodeset will
not allow the X server to start.
As soon as I get an idea what's wrong with the GTK greeter in lightdm, I can make a fix.
Offline
I don't see any webkit dependency on lightdm, but yeah it's fairly gtk heavy. But then my whole x session is gtk based, so if that's broken, I'm likely to have more problems than just lightdm.
Not that I actually use a display manager at present. The last time I brought this system up, I got to the point where I could start x after logging in to a text mode terminal, and I just haven't taken it any further yet.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
There is a lightdm-webkit2-greeter, just in case lightdm-gtk-greeter feels too stable. :->
Offline
There's been reports as far as december about systemd 240 causing issues with some applications, including lightdm. In my netbook, lightdm with the gtk greeter results in a coredump, and the webkit2 greeter simply doesn't work for some reason.
lightdm with the webkit2 greeter is 20 packages and 228MB that I consider just way too much resources just for the DM. Regardless after installing and starting it, journalctl simply says " Failed to start Light Display Manager" so i assume it's still a bug on lightdm no matter the greeter, and systemd changing how things work and introducing new bugs.
I tried slim and also didn't work. Haven't tried sddm. xdm works but at that point i just prefer no display manager and use xinit to get to desktop.
For people struggling with this, if you can't arch-chroot from a live usb, or don't know and have a black screen with the cursor blinking:
1. crt + alt + f2 to switch to a different tty. (because systemd will try to launch lightdm after every crash, you may need to time it right and repeatedly)
2. log in as root
3. stop lightdm service with "systemctl stop lightdm.service". (you will probably have to constantly switch to this tty with ctr+alt+f2 and enter the letters one by one until lightdm is stopped)
4. once lightdm.service is stopped, disable it with "systemctl disable lightdm.service" so it won't crash loop again next reboot
5. depending on your desktop environment you can get to desktop by manually starting X. In my case I use openbox so the command is "startx /bin/openbox-session". You could use xinit to auto launch X after you log in.
Not the prettiest solution but this could help to someone. When the bugs are hopefully fixed, you need to enable the service with "systemctl enable lightdm.service" and that's it.
Offline
Thanks K8ebBM214bp4UJV for this exhaustive test and report.
So far I could track down the lightdm-gtk-greeter problem to some resource
problem, see https://bugs.archlinux32.org/index.php? … task_id=60
Either systemd plays really bad tricks with rlimit for lightdm or ligthdm-gtk-greeter
violates some resource constraints.
Offline
BTW, K8ebBM214bp4UJV is hopefully not your password.. ;-)
Offline
Yes, I should really post this as a comment on that bug, but I'm logged on here at the moment.
That plymouth warning seems to be noise to me. I used to use lightdm once upon a time and never built plymouth (it's an AUR project in arch), and also in one of these threads reporting this issue, the user had never built plymouth. So unless it's just been added (and as far as I checked in that thread, lightdm has not had an update yet this year), and it looks like a ping test, then I think it's just noise in the logs.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
See https://bugs.archlinux32.org/index.php? … task_id=60
Set LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service
Offline
today's update of lightdm to 1:1.28.0-1.3 fixed the issue with gtk-greeter. thanks everybody.
my username is random because I value privacy. i don't have an online presence, but try to help whenever possible. cheers.
Offline
Hello, thank you, it's working now.
*nice
Offline
udo pacman -Syu
:: Synchronisiere Paketdatenbanken...
core 197,4 KiB 822K/s 00:00 [#########] 100%
extra 2,1 MiB 837K/s 00:03 [#########] 100%
community 6,0 MiB 819K/s 00:07 [#########] 100%
:: Starte vollständige Systemaktualisierung...
:: libmagick durch extra/imagemagick ersetzen? [J/n] j
:: libsystemd durch core/systemd-libs ersetzen? [J/n] j
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...
Warnung: Abhängigkeits-Zyklus entdeckt:
Warnung: x264 wird vor seiner Abhängigkeit ffmpeg installiert werden
Pakete (120) adobe-source-code-pro-fonts-2.030ro+1.050it-5.0
at-spi2-atk-2.32.0-1.0 at-spi2-core-2.32.1-1.0
atk-2.32-1.0 avahi-0.7+18+g1b5f401-1.5
bash-5.0.003-1.1 binutils-2.32-1.9
bluez-libs-5.50-6.0 boost-libs-1.69.0-2.0
chromium-73.0.3683.75-2.0 colord-1.4.4-1.0
cracklib-2.9.7-1.0 cups-2.2.11-2.0
cups-filters-1.22.5-1.0 curl-7.64.1-2.1
dconf-0.32.0-3.0 device-mapper-2.02.184-4.0
double-conversion-3.1.4-1.0 ffmpeg-1:4.1.2-2.1
firefox-i18n-de-65.0.2-1.0 freetype2-2.10.0-2.0
fuse-common-3.5.0-1.0 gcc-8.3.0-1.0
gcc-libs-8.3.0-1.0 gdome2-0.8.1-6.2
glib-networking-2.60.1+2+g1ce6b40-1.0
glib2-2.60.1-1.0 glibc-2.29-1.26
gnustep-base-1.26.0-2.0 gnutls-3.6.7-1.0
groff-1.22.4-1.0
gsettings-desktop-schemas-3.32.0-2.0
gstreamer-1.16.0-1.0 gvfs-1.38.2-1.0 icu-64.2-1.0
imagemagick-7.0.8.42-1.0 inetutils-1.9.4-7.2
iputils-20180629.f6aac8d-4.2 lasem-0.4.3-3.2
libaio-0.3.112-1.0 libbluray-1.1.1-1.0
libcap-2.27-1.0 libcroco-0.6.13-1.0
libcups-2.2.11-2.0 libgudev-232-1.2
libical-3.0.4-3.0 libidn2-2.1.1-2.5
libinput-1.13.1-1.0 libjpeg-turbo-2.0.2-1.1
liblouis-3.9.0-1.0 liblqr-0.4.2-2.2
libmagick-7.0.8.34-1.0 [Entferne]
libnewt-0.52.20-2.5 libnsl-1.2.0-1.4
libplist-2.0.0+11+gec9ba8b-2.6 libpng-1.6.37-1.0
libpsl-0.20.2-5.1 libsecret-0.18.8-2.1
libsystemd-240.93-1.0 [Entferne]
libtool-2.4.6+42+gb88cebd5-3.0 libunwind-1.3.1-1.1
libutil-linux-2.33.2-1.0 libva-2.4.1-1.0
libvpx-1.8.0-1.0 libxkbcommon-0.8.4-1.1
libxkbcommon-x11-0.8.4-1.1 libxklavier-5.4-2.2
libxml2-2.9.9-2.0 linux-api-headers-5.0.7-1.0
llvm-libs-8.0.0-1.0 lz4-1:1.9.1-1.0
man-db-2.8.5-2.0 mdadm-4.1-1.0 nano-4.2-1.0
ncurses-6.1-6.0 ndctl-64.1-2.0 openssh-8.0p1-1.0
openssl-1.1.1.b-1.1 openssl-1.0-1.0.2.r-1.2
opus-1.3.1-1.0 orc-0.4.29-1.0 pacman-5.1.3-1.3
pango-1:1.43.0-2.0 parted-3.2-8.1
pcmciautils-018-8.5 pcre2-10.32-2.1 perl-5.28.2-1.0
pinentry-1.1.0-4.18 pixman-0.38.4-1.0
poppler-0.74.0-1.1 poppler-glib-0.74.0-1.1
pygobject-devel-3.32.0-1.0 python-3.7.3-1.1
python-dbus-1.2.8-2.4 python-dbus-common-1.2.8-2.4
python-gobject-3.32.0-1.0 qt5-base-5.12.3-2.0
qt5-location-5.12.2-1.1 raptor-2.0.15-11.0
s-nail-14.9.13-2.1 shadow-4.6-2.1 sqlite-3.28.0-1.0
systemd-242.19-1.0 systemd-libs-242.19-1.0
systemd-sysvcompat-242.19-1.0
thin-provisioning-tools-0.8.0-1.0 tlp-1.2.1-1.0
unarchiver-1.10.1-7.2 util-linux-2.33.2-1.0
wayland-1.17.0-1.1 wget-1.20.3-1.0
wpa_supplicant-2:2.6-2.1 x264-2:157.r72db4377-1.4
x265-3.0-1.4
xf86-video-intel-1:2.99.917+863+g6afed33b-1.1
xfsprogs-4.20.0-2.0 xorg-server-1.20.4-1.0
xorg-server-common-1.20.4-1.0 zeromq-4.3.1-2.0
zstd-1.4.0-1.0
Gesamtgröße des Downloads: 290,73 MiB
Gesamtgröße der installierten Pakete: 1201,32 MiB
Größendifferenz der Aktualisierung: 6,87 MiB
:: Installation fortsetzen? [J/n] My Release Image 2019-04-16 works without problems.
If i get the newest "pacman -syu" ligdtdm starts, but the deskto don't start.
When i schould try it again to get a working system?
Greetz
arch32yes
Last edited by arch32yes (2019-05-03 21:18:06)
Offline
Lightdm had been reported as being broken currently. As a workaround, is there any way of getting to a terminal from a broken lightdm run (either switching to an alternative gnu screen, or the nomodeset trick above might be neccessary), and running startx after logging in from there?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
https://wiki.archlinux.org/index.php/Linux_console
Can you reach the text terminal with crtl-alt-f1?
Offline
Hello andreas_baumann, yes i can start the text terminal with crtl-alt-f1,
Lightdm can't start my LXQt Desktop,
Greetz
arch32yes
Offline
you can use another display manager or craete an .xinitrc and then log in into the text terminal and use 'startx'.
Offline
Hello anrdreas_baumann,
did you have more input for me to use craete an .xinitrc and then log in into the text terminal and use 'startx'?
How can i check if i can use lightdm again?
Greetz
arch32yes
Offline
https://wiki.archlinux.org/index.php/LXQt#Using_xinit
As for checking to see if lighdm is fixed, you'll have to periodically undo your xinitrc configuration and try it out again. As I recall when I last used lightdm I couldn't be bothered to do that though, and am still logging in to the text console and issuing startx. Perhaps you don't need to completely undo your configuration, and there's a way to test lightdm without reconfiguring it, but I don't actually know what kind of error it's throwing up.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline