A recent update (Today) breaks my ability to login at SDDM. Immediately prior to update all is OK, after update, logout and login, SDDM tries but returns to the SDDM screen. Snapshots work to revert and all OK again.
There are a couple of errors on update about file permissions for share/polkit-1 Polkit-1 has incidentally moved from etc/pam.d to usr/lib/pam.d. This was a couple of days ago
I’m also getting ‘db’ errors for the ‘Extra’ Repository but i don’t think this connected.
Which of the updates do you think is causing problems so i can ignore it in pacman?
In general, I should say there are a lot of errors about right now.
This could be causing the issue actually if the extra repo is not syncing.
This occurred to many users recently, but I think they were not able to finish the update.
Try anyway an
update remote fix
And post the output in case of errors.
```
Like this
```
Regarding the extra db errors I have recently seen TNE on telegram asking a few people for
head /etc/pacman.d/mirrorlist
it contains a command for rate-mirrors running which fixes the issue for some I believe. Anyway I tried a one liner for this and tested it on my system, can you check if you still get the extra db errors after this,
Thanks for the replies. I tried your one-liner NaN, it ran, came up with a single 404 error for the Chaotic-Aur but wouldn’t login afterwards.
I also tried update remote fix which ran without errors but i couldn’t login afterwards.
Thank God for a manual snapshot.
Can you look into your journal for any errors? Don’t worry journal logs are not affected by snapshots. Do a,
journalctl --list-boots
It will list all the boot ups it remembers with timestamps and their index on left most column should be smth like 0 for current boot, -1 for the one before and so on.
Once you find the bootup which had your black screening issue can you do a
jctl <boot-idx>
Where you replace <boot-idx> with the index we found above.
jctl is an alias in garuda fish config. If it’s not there for you, you can also try
Thanks, All the usual failures which we are advised to ignore but maybe two new ones.
The job identifier is 199 and the job result is failed.
Jan 25 19:32:30 kevin-ms7721 systemd-remount-fs[542]: /usr/bin/mount for / exited with exit status 32.
Jan 25 19:32:30 kevin-ms7721 systemd[1]: Failed to start Remount Root and Kernel File Systems.
░░ Subject: A start job for unit systemd-remount-fs.service has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit systemd-remount-fs.service has finished with a failure.
░░
░░ The job identifier is 405 and the job result is failed.
Jan 25 19:32:43 kevin-ms7721 systemd[6741]: Failed to start Profile-sync-daemon.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit UNIT has finished with a failure.
░░
░░ The job identifier is 29 and the job result is failed.
I don’t remember seeing these before.
Just a little point. It doesn’t black screen, it try’s to login and flashes text up but then returns to the SDDM login screen.
I usually update every day. Maybe i should just wait a few days . These things tend to get fixed buy someone else.
Hmm that’s definately the cause of our issue. But it doesn’t contain why it couldn’t mount root. Can you try,
journalctl -S "2024-01-25 19:32" | tb
this will put all your logs from the given timestamp to now on termbin and give you a link that you can paste here. Maybe the complete log has more to offer about why this failure happened.
╭─kevin@kevin in ~ took 2ms
╰─λ journalctl -S "2024-01-25 19:32" | tb
https://termbin.com/70e0
read(net): Connection reset by peer
╭─kevin@kevin in ~ took 1s
[[⚡]|[🔴]] => 🔴ERROR ×
Dracut and Systemd form part of the updates. Is it possible to list each update with pacman and ‘Enter’ to accept individual updates to single out the problem one?
It did catch everything around the error message you sent before it hit the read/write limit set by server.
Reading from the logs I still couldn’t find anything worthy of making you stop mounting. Then I started searching for your error number and it seems you might have some invalid options in your fstab. Can you share your
cat /etc/fstab
Hopefully this is easy fix other wise the only other option would be booting up to the sddm screen changing TTY and then look at dmesg errors to understand why mount fails.
Sadly no, you can certainly write your own custom script for this but by default pacman doesn’t have any such features that I am aware of. You would have to do it manually.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=390B-FB09 /boot/efi vfat defaults,noatime 0 2
UUID=7b049ab1-cf8c-4eb1-809e-b21343f9b233 / btrfs subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=7b049ab1-cf8c-4eb1-809e-b21343f9b233 /home btrfs subvol=/@home,defaults,noatime,compress=zstd 0 0
UUID=7b049ab1-cf8c-4eb1-809e-b21343f9b233 /root btrfs subvol=/@root,defaults,noatime,compress=zstd 0 0
UUID=7b049ab1-cf8c-4eb1-809e-b21343f9b233 /srv btrfs subvol=/@srv,defaults,noatime,compress=zstd 0 0
UUID=7b049ab1-cf8c-4eb1-809e-b21343f9b233 /var/cache btrfs subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=7b049ab1-cf8c-4eb1-809e-b21343f9b233 /var/log btrfs subvol=/@log,defaults,noatime,compress=zstd 0 0
UUID=7b049ab1-cf8c-4eb1-809e-b21343f9b233 /var/tmp btrfs subvol=/@tmp,defaults,noatime,compress=zstd 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
/dev/sdc2 /mnt/Data ntfs defaults,uid=999,gid=1000 0 0
I inderstand how important fstab is but remember, this only happens after the update and a previoiusly saved manual snapshop reverts it back to normal and I’m using it now.
However from what I see there doesn’t appear to be anything wrong. It seems the only way to solve this is the hard way.
Can you update your system either all at once or one at a time using the package list you originally provided till it reaches your problematic state. Then change TTY
and,
Turn on network manager,
sudo systemctl start NetworkManager.service
remember the name of service file is case sensitive.
connect to the internet
nmtui
this will provide you with a tui interface to connect to wifi then,
upload your dmesg logs
sudo dmesg | tb
dmesg should contain a lot more about mount problems the only issue is it’s not saved anywhere unlike journal logs.
The reason why I asked updating system packages either one at a time or all at once. Both have their upsides and downsides.
On the flip side updating your system all at once and directly jumping to error message would be easier and hopefully dmesg contains something useful for resolving this with ease. On the other hand if you update one at a time you will be able to single out the problematic package as well and if dmesg on the offchance doesn’t contain anything useful you can still look at the package’s bug reports to see if anything has changed.
If you are confused about how to update package one at a time,
sync your repos with remote, this is a dangerous state and its usually advised to immediately update all system packages to prevent getting into a partially updated state.
sudo pacman -Sy
update a package with
sudo pacman -S pkgname
Before doing this though I will suggest create a manual snapshot with a meanigful name and keep track of it since pacman hooks are going to create new snapshots each package update, you don’t wanna lose this working snapshot. I believe the default limit of snapshots is 10 (configurable) before they are deleted starting from the oldest first.
OK, thanks. Might be some time as I got to work today as well. I’ve increased the Snapper save count to 50. Plus I don’t think that Manual Snapshots are deleted in the clean up.
One time it did fault I did manage to get into a tty3 i think, but startx didn’t work. Now we know i could try mounting ./ and see if there are error messages?
dmesg from a working system is not really helpful since it won’t contain the messages that tell us why the kernel couldn’t mount the file system. However your desire to have a working PC is understandable. I understand if you want to stick with wayland since it works for you.
Completely understandable. However if you try to revisit this in future do try to change TTY at that error message see if can even run any commands?
Log out of Wayland, into X11 and it works!!
It survived a reboot as well.
So we might never know the answer
Back to X11 or Wayland, which do you suggest?
that’s definately the cause of our issue. But it doesn’t contain why it couldn’t mount root. Can you try,