Not booting with kernel 6.8, infinite "3-dots manjaro logo animation"

Support
1

Hi,

The problem

after installing latest kernel, 6.8, at first restart I get an infinite loop at manjaro logo with 3 dots.
I don’t know how, but I got the system to boot in emergency mode on this kernel, so I can get infos as root.

What I tried:

  • read “not white nor green lines” logs from journalctl -xb as advised by manjaro emergency prompt (and compare with those from the working 6.6 LTS kernel) → I didn’t find anything (You may need them, how do I give them to You?)
  • remove 6.8 kernel and reinstall it (either with plasma settings interface, and with pacman in shell) → didn’t work for both

As I’m quite a newbie with all this stuff, as my distro worked as expected for the five last years without any problem, I didn’t learn a lot about how to repair this kind of complicated stuff :wink:

PS: sorry for my poor english, I try to fix this aswell

2

Well, what is your goal?

The easy way out seems to be to just not use the 6.8 kernel, but

reinstallation never does change anything - it can’t.
The same stuff will be put at the very same place - and it’ll work the same way (or not …)

It doesn’t look like anything needs to be repaired - just don’t use what doesn’t work if you have the option? … to use something that did and still does work

1 Like
3

thanks for your answer!

Well, what is your goal?

my goal is to run with the stable up-to-date kernel, is it compromised, or a bad habit? I always heard this kind of “DO THE UPDATE WHEN IT EXISTS (and gets out of nightly repos :stuck_out_tongue: )” takes…

The easy way out seems to be to just not use the 6.8 kernel

This is why I always keep an LTS backup kernel (and today I was really happy doing this for this long)

reinstallation never does change anything - it can’t.
The same stuff will be put at the very same place - and it’ll work the same way (or not …)

yes, I was trying to troubleshoot. I think I had to try if a problem occured during installation…

4

6.6 LTS is that - it’s not the newest, but it is up to date and … stable

no - it’s your choice

reinstallation … is not really “troubleshooting”

I guess you’ll need to have a look at some system logs and compare where they differ between booting one or the other kernel.

1 Like
5

reinstallation … is not really “troubleshooting”

seeing if a trouble happened while installation: corrupted files, internet cut at the worse moment, I get maybe too suspicious I’m not skilled enough to do alot more in-depth investigations as i don’t know “important package names ans what they bring to the system”.

your post gave me an idea:

  • I’m peeling log files in /var/log (are there mhwd-kernel logs somewhere else? and where?)
  • pacman ones seems “normal” to me: no “couldn’t line” in recent logs.

Do you think next kernel (or next LTS one maybe?) will work better with my computer and i only have to wait the release, or will 6.6 be eternally the last kernel available for me?

6

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

7

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.

8

boot once the stuck kernel, then boot the working one and see the error log from previous boot

journalctl -b -1 -p3 --no-pager
9

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.

10

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

11

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.

1 Like
12

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.

13

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=000
  • default_permissions → [drop]
  • user_id=1000 → uid=1000
  • group_id=1000 → gid=1000
1 Like
14

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.

15

looks like you missed out on the

change

whether “noatime” is even relevant for NTFS - I don’t know

16

If the failing block device is NTFS youi need to

  1. boot into windows and run chkdsk to ensure there is no issues
  2. disable Windows Fast Startup, disable hibernation , shutdown windows clean
  3. modify your fstab ntfs3 rw,noatime,iocharset=utf8,umask=0000
  4. save fstab and reboot
17 
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…

18

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.

19

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? :wink:

1 Like
20

@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?