Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [Solved] Update from 6.13.7 to 6.14.4: No Longer Boots  (Read 1943 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[Solved] Update from 6.13.7 to 6.14.4: No Longer Boots

After updating to Kernel 6.14.4 from 6.13.7 the system on booting halts after 'cupsd'.
I've checked 'dmesg' but it doesn't show anything useful.
After 'cupsd' I believe the next steps begin loading the system

I'm currently using the live environment to search for answers.

From the troubleshooting section in the Wiki, I have mounted and ran an update. No effect.

Tried to downgrade the Kernel, but 6.13.7 has been purged/cleaned from the pkg file.
That would explain why 'Fallback' option in the Advanced Options of the boot screen didn't work.
There is no 6.13.7 Kernel present.

What logs would show where the failure starts?
'journalctl -b' isn't installed. I think it's systemd based.

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #1 –
I would try linux-lts first: I have installed both and use it as fallback.

From the Livesystem use "artix-chroot" to enter the system and install it.

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #2 –
Quote from: tsedek1 – on
After updating to Kernel 6.14.4 from 6.13.7 the system on booting halts after 'cupsd'.
I've checked 'dmesg' but it doesn't show anything useful.
After 'cupsd' I believe the next steps begin loading the system

I'm currently using the live environment to search for answers.

From the troubleshooting section in the Wiki, I have mounted and ran an update. No effect.

Tried to downgrade the Kernel, but 6.13.7 has been purged/cleaned from the pkg file.
That would explain why 'Fallback' option in the Advanced Options of the boot screen didn't work.
There is no 6.13.7 Kernel present.

What logs would show where the failure starts?
'journalctl -b' isn't installed. I think it's systemd based.
If it only hangs when reaching cupsd, you can log in to system (pass init=/usr/bin/sh to kernel command line), disable this service and boot without it (exec /sbin/init). Once system is started you could check what exactly makes cups and/or system hang.
If you have syslog-ng running, /var/log/everything.log should contain all logs. If cups is configured to send logs to /dev/log it would be there. Alternatevely, all inits except for openrc (maybe it also) can save stdout/stderr of all the services, if configured per service
ARMtix
If you need to contact me, use email

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #3 –
it is not cupsd that is the problem.  It started.  It is an end user problem.  It is almost definitely because the end user mucked up the innards of the boot system.  It is certainly not the kernel.

Quote
I'm currently using the live environment to search for answers.

Ummm - your live environment uses safari as a browser?

Quote
'journalctl -b' isn't installed. I think it's systemd based.

Please - you have posted advanced OS configurations but you aren't aware of what journalctl is?

I had a friend as a child who would take apart car engines and then put everything back together again.  Sometimes it didn't work but that was before the internet and he never complained about it.

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #4 –
Quote from: phoenix_king_rus – on
If it only hangs when reaching cupsd, you can log in to system (pass init=/usr/bin/sh to kernel command line), disable this service and boot without it (exec /sbin/init). Once system is started you could check what exactly makes cups and/or system hang.
If you have syslog-ng running, /var/log/everything.log should contain all logs. If cups is configured to send logs to /dev/log it would be there. Alternatevely, all inits except for openrc (maybe it also) can save stdout/stderr of all the services, if configured per service
Currently, I have a fresh install which I can't upgrade using
Code: [Select]
$ sudo pacman -Syu
This will update the Kernel, and after the kernel is updated, rebooting the system, on boot hangs at cupsd.
Learning to install packages manually for offline installs, I installed only the Kernel files based on the minimum mentioned in the Arch Wiki to see if it is the Kernel causing this, and the behavior repeated with just a Kernel upgrade only.
This does not mean it is the kernel files causing the problem, so I thought log files would help verify the new kernels downloaded are the issue or not.
I am currently using 6.13.7 from the ISO.
Also I reviewed settings in the Bios/Uefi again, like 'secure boot' is enabled or if UEFI was disabled to use Legacy, but all of the settings are how I have had them for almost a year now.
If there was some silent UEFI update, I don't see any setting changes, so not sure there.

After 'cupsd' the next process to boot is 'local'.
I'm guessing that 'local' is where the gui desktop system begins to be brought up.

The only changes I have introduced to my setup from a fresh install:
Installed nftables
Installed Slim Login manager
Un-installed lightdm lightdm-gtk-greeter lightdm-openrc
/etc/ssh/sshd_config > permitrootlogin = no
/etc/securetty > (delete contents) console, tty0....tty7, hc0.
sometimes.../etc/passwd > root::root:usr/bin/nologin...but not currently.

@phoenix_king_rus I'm going to have to re-read your post to make sure I understand it.
I don't know how to add kernel parameters on boot, I guess that's grub. I'll have to refresh myself with grub-console or open a console even, 'It's Been Awhile'.
What is the simplest method that will reveal the most information?
I can install syslog-ng, configure it if necessary, then upgrade the Kernel, and if it hangs, boot with live iso and see if there are logs and copy those to my flash drive.

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #5 –
Quote from: mrbrklyn – on
Quote
'journalctl -b' isn't installed. I think it's systemd based.
Please - you have posted advanced OS configurations but you aren't aware of what journalctl is?
When the error message is 'Command not found',  when typing 'journalctl' it can mean it isn't installed. So I moved on to other methods.

Be careful with attacking perceived weaknesses, I am not A Fruit.

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #6 –
Quote from: tsedek1 – on
@phoenix_king_rus I'm going to have to re-read your post to make sure I understand it.
I don't know how to add kernel parameters on boot, I guess that's grub. I'll have to refresh myself with grub-console or open a console even, 'It's Been Awhile'.
What is the simplest method that will reveal the most information?
I can install syslog-ng, configure it if necessary, then upgrade the Kernel, and if it hangs, boot with live iso and see if there are logs and copy those to my flash drive.
If you have access to the system, install linux-lts alongside linux. After that you can remove services from boot while on lts kernel and check which one actually hangs system. The idea is similar to what i proposed with boot flags but should be a bit simpler and maybe faster
ARMtix
If you need to contact me, use email
 

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #7 –
The most hilarious thing happened when I followed your recommendation trying to install 'linux-lts':

Code: [Select]
[zedeq1]:~$ sudo pacman -Syyuu
:: Synchronizing package databases...
error: failed to synchronize all databases (no servers configured for repository)

Despite pacman.conf, mirrorlist, and mirrorlist-arch, they look fine. ehhh.

Usually I limit my mirrorlist files to only 2 or 3 servers to eliminate dangerous hosting countries, like any in Islamic Nations or Ukraine, because they are friendly to attacking the 'West', just in case that is a threat vector.

Just prior to this, there were a bunch of these in the logs...

Code: [Select]
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt (t=626.743) [GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt (t=626.743) |[1][GFX1-]: GFX: CanvasTranslator failed creating WebGL shared context (t=781.961) [GFX1-]: GFX: CanvasTranslator failed creating WebGL shared context

I have been researching this recently because everytime my system is compromised a 'heap' of these end up in my logs, and my computer contains malicious tools or mysterious modifications. Apparently, when you want Remote Code Execution and/or Privilege Escalation, WebGL is a juicy target. It also goes through Xorg on Linux. Xserver is root, so game over I guess. With root they can Inter_process_communicate with anything.
Every year there are 5 or so CVE's about WebGL RCE, Tab Crashes leading to exploits, and privilege escalation.

Now I have to search why pacman doesn't see the mirrorlist/s.

Edit:
Well, fixing that typo was difficult...I installed the linux-lts kernel. If going backwards creates the same issue, then maybe it is in building the image.

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #8 –
Quote from: tsedek1 – on
Quote from: mrbrklyn – on

Please - you have posted advanced OS configurations but you aren't aware of what journalctl is?
When the error message is 'Command not found',  when typing 'journalctl' it can mean it isn't installed. So I moved on to other methods.

Be careful with attacking perceived weaknesses, I am not A Fruit.


I have zero to be careful about.  Everyone knows who I am.  I am the most unanonymous person on this board.  My address, phone, email address and servers are all a matter of public record.  You can't troll me and if you want to discuss this person to person, you know EXACTLY where to find me.

I have no idea what your reference to Fruit is, but I assure you, it matters not to me or anyone else. 

It is your blatant bigotry and trolling that pisses me off.  

You are taking advantage of these peoples good hearts and love of the technology to drag them through rabbit holes and then shit on them and the board.

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #9 –
Quote from: mrbrklyn – on
Quote from: tsedek1 – on

When the error message is 'Command not found',  when typing 'journalctl' it can mean it isn't installed. So I moved on to other methods.

Be careful with attacking perceived weaknesses, I am not A Fruit.


I have zero to be careful about.  Everyone knows who I am.  I am the most unanonymous person on this board.  My address, phone, email address and servers are all a matter of public record.  You can't troll me and if you want to discuss this person to person, you know EXACTLY where to find me.

I have no idea what your reference to Fruit is, but I assure you, it matters not to me or anyone else. 

It is your blatant bigotry and trolling that pisses me off.  

You are taking advantage of these peoples good hearts and love of the technology to drag them through rabbit holes and then shit on them and the board.

You replied "Probably using Safari"
Is Apple a Fruit or not?

Re: Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #10 –
The suggestions to install additional Kernels was the correct advice I discovered.
Upgrading the only kernel you have doesn't automatically place the old kernel in the fallback structure.
By installing two or more kernels puts the alternative kernel in the fallback .img,
Code: [Select]
sudo pacman install -Sy linux linux-headers linux-lts linux-lts-headers
This caused 'linux-lts' to be written as a fallback.img

I now have a fallback kernel in case of future kernel issues.

After accomplishing this, linux kernel 6.14.6 was installed and there was no longer a boot issue, proceeding from cupsd to local without a problem.

When I used Endeavor, the system automatically preserved previous kernels to boot into.
I assumed, when I saw 'Fallback' there was a similar system in place, but I was let down when I tried to use it in an emergency.
That was my lack of understanding 'Fallback' doesn't automate previous kernel saving.

Re: [Solved] Update from 6.13.7 to 6.14.4: No Longer Boots

Reply #11 –
Quote from: tsedek1 – on
When I used Endeavor, the system automatically preserved previous kernels to boot into.
I assumed, when I saw 'Fallback' there was a similar system in place, but I was let down when I tried to use it in an emergency.
That was my lack of understanding 'Fallback' doesn't automate previous kernel saving.
The fallback image you see is not the kernel, but just the initramfs created by mkinitcpio.
Quote from: wiki.archlinux.org
the fallback ramdisk image, same as [the default] except that the autodetect hook is skipped during creation, thus including a full range of modules which supports most systems.
The actual kernel image is called ' vmlinuz-linux[-lts]', and at least the 'file' utility can identify its version for you:
Code: [Select]
$  sudo file /boot/vmlinuz-linux-lts
If you want to back up the previous kernel image, then AFAIK you have to set this up manually yourself (on Arch and most derivatives).

Also, off topic, I strongly suspect that you don't actually need the linux headers installed. (Of course I don't know what sort of computing you actually do. If you know you need them, that's great.)