Why fsck would have run after the reboot? Compare your /etc/fstab entries against fstab - ArchWiki… only a zero in the fsck position disables it, and typically a zero is only used when what’s being mounted is a network drive (not internal).
Why it would have found garbage? Failing drive, improper shutdown, etc…
If you have the fsck hook in mkinitcpio.conf then it doesn’t need to be set to anything other than “0” in /etc/fstab, because then fsck will always be executed from within the initramfs anyway.
Also, if you are using btrfs, then it should always be set to “0”, and then the fsck hook should be removed, because btrfs has its own integrity checking routine, which it will always execute at mount time.
After update sddm was unable to load theme (breeze).
I had installed various *kde-AUR packages some time ago, so I had to uninstall them manually using pacman and install the corresponding official packages.
Now everything is working again.
:: Different overlay package(s) in repository extra x86_64
-----------------------------------------------------------------
PACKAGE 2024-07-01 2024-07-16
-----------------------------------------------------------------
nano-syntax-highlighting 2020.10.10+10+g1aa64a8-2 -
...
:: Different sync package(s) in repository extra x86_64
-----------------------------------------------------------------
PACKAGE 2024-07-01 2024-07-16
-----------------------------------------------------------------
nano-syntax-highlighting 2020.10.10-1 2020.10.10-2
I believe your package is from the Manjaro repository. But it looks like a case where pacman parses the newer version’s number as being older. Reinstalling or “downgrading” to the newer version should be fine.
Sorry folks, the confusion with the nano-syntax-highlighting versioning is my fault. I removed our overlay package (2020.10.10+10+g1aa64a8-2) that was versioned differently than Arch’s package (2020.10.10-2).
It was my understanding that Arch was going to drop it from the repos as upstream is unmaintained.
❯ vercmp 2020.10.10-2 2020.10.10+10+g1aa64a8-2
-1
❯ vercmp --help
vercmp (pacman) v6.1.0
Compare package version numbers using pacman's version comparison logic.
Usage: vercmp <ver1> <ver2>
Output values:
< 0 : if ver1 < ver2
0 : if ver1 == ver2
> 0 : if ver1 > ver2
Hi @Aragorn ,
I have the same issue as @905 and others. I do want to know whether it could be a problem with this output.
core/nano 8.1-1 [installed]
Pico editor clone with enhancements
extra/haskell-nanospec 0.2.2-359
A lightweight implementation of a subset of Hspec's API
extra/nano-syntax-highlighting 2020.10.10-2 [installed: 2020.10.10+10+g1aa64a8-2]
Nano editor syntax highlighting enhancements
extra/nanobind 1.9.2-3
tiny and efficient C++/Python bindings
extra/nanomsg 1.2-2
Simple high-performance implementation of several "scalability protocols"
extra/nanosvg 0.1.0.git1.9da543e-4
Simple stupid SVG parser
extra/orbiton-nano 2.65.12-1
Fast and configuration-free text editor and IDE limited by VT100 (Nano/Pico Mode)
extra/ruby-nanotest 0.9.4.1-1
Extremely mynymal test framework
I solve the problem running with a tip given by @cscs : sudo pacman -Syuu
I know, but I was loath to mention that, given that people will see it and then start using -Syuu as a rule rather than as an exception, just as they have already been doing with -Syyu.
As you know, most of our members are allergic to man pages.
So the suggestion was remove and then install again?
If for some reason we want to avoid giving people ideas about using something other than Syu
(I must confess I find it a silly concept - there are different flags/functions for a reason. If people cant understand that doing X when Y occurs is different than the default Z then they should probably be far away from any sort of information parsing … let alone computer administration)
then I suppose you could suggest pointing at the offender instead
(I didnt suggest this simply due to it being more characters)
sudo pacman -Syu nano-syntax-highlighting
I guess that has the added benefit of covering the cases of someone using the git version as well.
Yes, I always do a hard shutdown after the PC freezes. The question is why doesn’t fsck run automatically after the hard shutdown so that you wouldn’t have to face the problem when you are upgrading. The other thing that strikes me as bit strange is that I installed Manjaro Gnome two years ago but I have never faced this problem before.
