That is what checksums are for - corrupted packages … simply won’t install.
The package manager takes care of it.
That is not a real source of potential problems.
as for logs:
like most Linuxes, Manjaro uses systemd
logs are accessed / looked at … using variations of the
journalctl
command.
You should look it up - how to use it.
manual page:
man journalctl
I have no idea - and any idea I’d share would be pure speculation
I put 6.6 and 6.8 kernel logs (from journalctl -k --priority=5 ) in a diff tool, and only one difference is shown (except timestamps, keys, and boot image names of course)
kernel: /dev/sda3: Can’t open blockdev
This refers to a foreign partition, that is not necessary to mount for booting… despairing.
boot once the stuck kernel, then boot the working one and see the error log from previous boot
journalctl -b -1 -p3 --no-pager
The anination is intended to provide a clean boot - some prefers it that way others want to see everything - and then gets confused by the output.
To hide the animation press escape when the animation begins.
If that is not enough you can use shift in early boot to show the grub loader menu
Press e on the highlighted entry and remove quiet, splash and udev.log_priority=3 then press F10 continue boot.
this is an error that i have seen at least 5 times on this forum.
It’s conceivable that the boot process just waits indefinitely for this device.
Search the forums, you will see how others fixed the issue, if i remember correctly it’s to change fstab mount options due to kernel switching ntfs driver. And i think i saw one report of same happening with exfat
It may be that a common issue with the Plymouth boot screen (the three dots) has inadvertently been triggered.
Plymouth isn’t needed for booting Manjaro. Many users (myself included) remove it completely even if it isn’t causing issues; because, sooner or later, it will. Because Plymouth has close ties to boot processes, simply uninstalling the package is insufficient.
The correct procedure to remove Plymouth can be found on the Manjaro Plymouth Wiki page under the heading of REMOVAL. Please also see related information found in Disable or Remove Plymouth (boot splash).
It’s possible that this may not directly solve your issue. It will, at least, take Plymouth out of the equation as being a contributor to the problem.
Note that reverting to a previous kernel (for example kernel 6.6.x LTS) as previously suggested is another likely resolution. See Manjaro Kernels in the Wiki for information on how to do that.
I hope this is helpful. Cheers.
And that foreign partition has an NTFS volume, right?
There is a condition resulting from the recent kernel 6.8 update that does prevent mounting of NTFS volumes for some users. See the note in the Stable 2024-04-04 Update announcement to see if this also relates to you.
thank you all for your answers!
And that foreign partition has an NTFS volume, right?
YES! I readed the doc You linked me, but I don’t think it is the problem here. this partition holds a windows partition, so it shouldn’t prevent linux from booting.
boot once the stuck kernel, then boot the working one and see the error log from previous boot
journalctl -b -1 -p3 --no-pager
I did it, and that’s what it returns.
avril 09 19:28:32 HP-remi-manjaro kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GPP1.WLAN], AE_NOT_FOUND (20230628/dswload2-162)
avril 09 19:28:32 HP-remi-manjaro kernel: ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20230628/psobject-220)
avril 09 19:28:32 HP-remi-manjaro kernel: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_PR_.P000 (20230628/dspkginit-438)
avril 09 19:28:32 HP-remi-manjaro systemd-modules-load[274]: Failed to find module 'acpi_call'
avril 09 19:28:33 HP-remi-manjaro kernel: /dev/sda3: Can't open blockdev
avril 09 19:28:32 HP-remi-manjaro systemd[1]: Failed to mount /data/windows.
avril 09 19:28:36 HP-remi-manjaro kernel: amdgpu 0000:05:00.0: amdgpu: Secure display: Generic Failure.
avril 09 19:28:36 HP-remi-manjaro kernel: amdgpu 0000:05:00.0: amdgpu: SECUREDISPLAY: query securedisplay TA failed. ret 0x0
as @soundofthunder said, this is because ntfs volumes mounting is prevented by the 6.8 kernel.
Not quite the right wording here.
It’s not prevented.
It just requires a change in the mount options (syntax change).
Solution:
Migrate your mount options. For me the changes were:
allow_other→umask=000default_permissions→ [drop]user_id=1000→uid=1000group_id=1000→gid=1000
Not quite the right wording here.<
true that: still not a native nor good english speaker, so i understand but sometimes I answer with a lot less accuracy than needed.
this is the line corresponding to this volume in my /etc/fstab file:
UUID=54F2BE10F2BDF5F8 /data/windows ntfs umask=000,user_id=1000,gid=1000,noatime 0 2
I feel like i didnt do it at the correct place.
looks like you missed out on the
change
whether “noatime” is even relevant for NTFS - I don’t know
If the failing block device is NTFS youi need to
uname -a
Linux HP-remi-manjaro 6.8.4-1-MANJARO #1 SMP PREEMPT_DYNAMIC Thu Apr 4 20:38:32 UTC 2024 x86_64 GNU/Linux
THANK YOU A LOT!
how comes this windows volume not mounting could prevent the computer from booting? I mean: this volume doesn’t contain anything useful for linux, so I don’t understand why it make any boot fail…
By default anything that fails in fstab stops the booting. There is an option to prevent that (i do not remember right now) or one can use systemd to mount instead of fstab.
Read this VERY SLOWLY…
The NTFS volume did not prevent the machine from booting. It may have been prevented from MOUNTING, but nothing was said about booting.
Got it? 
@soundofthunder yeah, bad vocabulary, my bad.
@Teo said that fstab fails stops the booting by default (the nominal one with all green flags and tadaaaam it works). why? is it a protection? against what? in other words, there seems to be an option to change this behaviour (nofail), what are the risks setting up this option?
I think the reason is that by default all drives should be checked for damage before being mounted (the very last number 0,1 or 2 is the filesystem check priority). Because mounting something broken can break it even more. But for example external drives are not always connected and thus if not found cannot be checked that is why nofail exists to allow the boot process to continue if a drive is missing.
so, if I understand well, adding this “nofail” flag to my fstab config for this windows volume might not be causing problems in my system, as my system doesn’t rely on it, right?
Yes but this is emergency failback, you have to check why it is not mounting in the first place (dirty bit or wrong options, as shown in the solution.)
Yes but this is emergency failback, you have to check why it is not mounting in the first place (dirty bit or wrong options, as shown in the solution.)
definitely wrong options. it works now with the flags Linux-Aarhus gave me rw,umask=0000,noatime,iocharset=utf8, I was just wondering why and how the magic worked, and how I could prevent this behaviour without compromising my system.
Well thank You all for the help, I kinda learnt a lot with this.
This is no doubt one the very reasons that the ntfs3 kernel driver was chosen in preference to ntfs-3g.
ntfs3 checks for an indication of damage (a dirtry bit) to an NTFS volume before mounting it, and if finds the dirty bit, it refuses to mount the volume.
This security measure is a layer of protection that ntfs-3g simply does not have. Instead, ntfs-3g ignores the dirty bit, completely.
ntfs3 
-
“It looks like this NTFS volume is damaged. You better run chkdsk on it as soon as possible.”
ntfs-3g 
-
“Whatever, dude… 
a mounting we will go, a mounting we will go… ”
It always seems to be when something breaks…
that we learn the most… Why is that?! 