[SOLVED] Install hanging by thread after botched kernel upgrade

covid19 · 2020-08-22 01:21:57

I have an install barely hanging on by a thread, and I'm terrified of making a wrong move. Basically the mistake I had made was adding grub to the IgnorePkg list, installed kernel 5.8, and things went horribly wrong, as the Grub version I was using was a modified 2.04-4. The reason for using the patched GRUB in the first place is for the ordering of the kernels, because no matter what, installing linux-lts second will NEVER mean that is the kernel I want as a default, it means it's the kernel I want as a backup when the main kernel fails as in this case. So catch 22, this issue didn't need to happen at all, even if I hadn't been careless or simply forgot as was the case, the default assumed behavior is just.... sigh.

I can only boot my system via efibootmgr, I've tried arch-chrooting a dozen times, correcting the issue installing vanilla versions of packages and re-creating the configuration but I'm not getting anywhere, I *MUST* mash F9 on my HP laptop to bring up the OS selection EFI list, and selecting an older entry of arch works. (Adding another one via "# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch-grub" also does not work, and complains about not being able to mount /boot/efi, even though the entry is fine in the fstab file.

How can I correct the behavior of my system to how it was previously? There is a reason the first thing I do on an Arch install is add linux, linux-headers to the IgnorePkg section of the pacman.conf, and I'm regretting taking the upgrades so much as now I've created so much more work and don't even have a general clue as to what is wrong.

Selecting that arch entry is obviously loading a grubx64.efi and apparently kernel stuff with it, I'm not sure what to change to get the result to be system wide and be booting as usual
Any help appreciated

5.8.2

Last edited by covid19 (2020-08-26 00:29:35)

Trilby · 2020-08-22 01:26:49

Less drama, more facts please.

For a specific example, here ...

covid19 wrote:

"# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch-grub" also does not work, and complains about not being able to mount /boot/efi, even though the entry is fine in the fstab file.

As noted in the link "does not work" is not an error message. And a summary of what is complained about doesn't help - post the complete output. As for /boot/efi being fine in the fstab file, show us.

covid19 · 2020-08-22 01:34:17

Trying to load with just grub like before botched update, I get:

Loading Linux linux ...
error: premature end of file /boot/vmlinuz-linux.
Loading initial ramdisk ....
error: you need to load the kernel first.

Press any key to continue

fstab:

UUID=3fa8ecba-3ab4-4252-b029-ec87db096500	/         	ext4      	rw,noatime	0 1
UUID=82E7-E228					/boot/efi	vfat		defaults,rw	0 2
tmpfs                                                 /tmp                                                tmpfs   nosuid,nodev,noatime,mode=1777                                                0       0
tmpfs                                                 /var/tmp                                            tmpfs   nosuid,nodev,noatime,mode=1777                                                0       0
tmpfs                                                 /home/covid/.config/chromium                          tmpfs   nosuid,nodev,noatime,mode=1777                                                0       0

Trying to load the LTS kernel fails with unable to mount the /boot/efi partition, even though the UUID matches up with the correct partition, it's as if there's mismatching modules or something else weird happening.

I tried installing GRUB with both the --removable option and without, it says successful when aimed @ the EFI target directory, but for some reason the only way to boot is with laptops OS manager

$ efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0001,0000
Boot0000* arch	HD(1,GPT,0d024583-35fa-0f4f-a699-0fca3161e548,0x800,0x64000)/File(\EFI\arch\grubx64.efi)
Boot0001* arch-grub	HD(1,GPT,0d024583-35fa-0f4f-a699-0fca3161e548,0x800,0x64000)/File(\EFI\arch-grub\grubx64.efi)
Boot0080* Mac OS X	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(3,GPT,3a77ec51-107a-4093-929c-2a5f14f74b0a,0xe9afc48,0xe6dfde0)

Mac OSX only shows up as this is a former hackintosh/hackbook, irrelevant. However, arch-grub does not boot, while just 'arch' does

Last edited by covid19 (2020-08-22 01:39:39)

covid19 · 2020-08-22 01:42:32

This is the patch that I had applied, if it makes any difference https://bugs.archlinux.org/task/28081?getfile=14976 and if I can test anything based upon given info

Am using unpatched, stock version of GRUB for now, regenerated the config file, and regenerated the initramfs', made no difference

Maybe something I need to copy out of the working EFI partition where the grubx64.efi resides? There has to be some kind of obvious reason why only one of these works and only a botched upgrade produced this

Last edited by covid19 (2020-08-22 02:00:49)

covid19 · 2020-08-22 02:30:43

OK... not sure what I did but it's booting now, I copied the GRUBX64.efi from arch into arch-grub, and voila, however I still have issues.
I've decided I want to run with the 5.7.9 kernel, but I'm having DKMS issues with vmware, something I kinda rely on

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                                           [----------------------------------------] 100%
(1/1) checking package integrity                                         [----------------------------------------] 100%
(1/1) loading package files                                              [----------------------------------------] 100%
(1/1) checking for file conflicts                                        [----------------------------------------] 100%
(1/1) checking available disk space                                      [----------------------------------------] 100%
:: Running pre-transaction hooks...
(1/1) Remove upgraded DKMS modules
==> dkms remove --no-depmod -m vmware-workstation -v 15.5.6_16341506 -k 5.4.59-1-lts
==> Unable to remove module vmware-workstation/15.5.6_16341506 for kernel 5.7.9-arch1-1: Not found in dkms status output.
:: Processing package changes...
(1/1) reinstalling vmware-workstation                                            [----------------------------------------------] 100%
:: Running post-transaction hooks...
(1/6) Reloading system manager configuration...
(2/6) Arming ConditionNeedsUpdate...
(3/6) Install DKMS modules
==> dkms install --no-depmod -m vmware-workstation -v 15.5.6_16341506 -k 5.7.9-arch1-1
Error! Bad return status for module build on kernel: 5.7.9-arch1-1 (x86_64)
Consult /var/lib/dkms/vmware-workstation/15.5.6_16341506/build/make.log for more information.
==> Warning, `dkms install --no-depmod -m vmware-workstation -v 15.5.6_16341506 -k 5.7.9-arch1-1' returned 10
==> dkms install --no-depmod -m vmware-workstation -v 15.5.6_16341506 -k 5.4.59-1-lts
==> depmod 5.4.59-1-lts
==> depmod 5.7.9-arch1-1
(4/6) Updating icon theme caches...

Never seen these before.... what have I done to a perfectly working system?

$ dkms status
broadcom-wl, 6.30.223.271, 5.4.59-1-lts, x86_64: installed
vmware-workstation, 15.5.6_16341506, 5.4.59-1-lts, x86_64: installed

so no dkms for non-lts kernel..

Last edited by covid19 (2020-08-22 02:36:18)

covid19 · 2020-08-22 03:37:34

Sigh okay apparently I chose a bad time to do things, its GCC incompatibilities mixed with old/new/incompatible versions of various things, I'm guessing I need to just sit still for a few days for everything to be in sync
Next time I willingly go upgrade my kernel I may aswell go stick the other hand in the blender, lesson well learned. I've ran this system for over 6 months and it's been so STABLE because I've been doing since day 1:

IgnorePkg   = linux linux-headers linux-image linux-api-headers linux-firmware

Guess I have it in a partial state where vmware works right now

broadcom-wl, 6.30.223.271, 5.4.59-1-lts, x86_64: installed
vmware-workstation, 15.5.6_16341506, 5.7.9-arch1-1, x86_64: installed

This is the result of undoing and taking upgrade; and as for first post, wasn't really drama, its something nobody is going to look at because it would imply/suggest something is wrong with the current logic. If other distros can figure out the logic of "this is a backup kernel", why can't we have that? Unbelievable this is something that has to be manually patched in. I'd like to meet ONE person who thinks installing a second kernel implies he/she wants to replace it with the primary one. I might be bitching because of a self-issue, but the larger issue still exists and has existed for multiple years and will continue to do so. Why does nobody give a shit the only real question when this is one of those things that actually effects people, who doesn't want a spare kernel if the main one screws up on a ROLLING RELEASE distro of all.
Thanks anyway, if it doesn't all sync up over the next couple days I doubt I'll be doing a full reinstall
Edit
Seems it is working... apparently I mostly need to sit tight for vmware rls

broadcom-wl, 6.30.223.271, 5.4.52-1-lts, x86_64: installed
broadcom-wl, 6.30.223.271, 5.7.9-arch1-1, x86_64: installed
vmware-workstation, 15.5.6_16341506, 5.4.52-1-lts, x86_64: installed
vmware-workstation, 15.5.6_16341506, 5.7.9-arch1-1, x86_64: installed

That looks all right (downgraded LTS since vmware being problematic with current non-lts), still no idea how I "fixed" this problem, the arch/arch-grub, what else can I use these for (and how/why it let to kernel modules)

Last edited by covid19 (2020-08-22 05:27:47)

covid19 · 2020-08-22 06:00:14

In the same directory

[archbook covid]# ls -l /boot/efi/EFI
total 2
drwxr-xr-x 2 root root 512 Aug 21 16:10 arch
drwxr-xr-x 2 root root 512 Aug 21 19:24 arch-grub
drwxr-xr-x 2 root root 512 Aug 21 11:39 BOOT

/boot/efi/EFI/BOOT:
-rwxr-xr-x 1 root root 208896 Aug 21 16:03 BOOTX64.EFI

Can I replace that third entry in BOOT with a working GRUBX64.EFI? Or is that for something else

Last edited by covid19 (2020-08-22 06:00:44)

Allan · 2020-08-22 08:23:16

covid19 wrote:

I've been doing since day 1:

IgnorePkg   = linux linux-headers linux-image linux-api-headers linux-firmware

linux-api-headers should not be in that list.

2ManyDogs · 2020-08-22 12:24:41

covid19,

1. If no one has replied to your post, please do not keep posting; instead, edit your post with new information as necessary.

2. Please read https://wiki.archlinux.org/index.php/Co … pics/rants -- we know you are frustrated, but angry rants are discouraged here.

covid19 · 2020-08-22 17:25:34

OK sorry will do, so is there any sensible way to deal with grub not booting "linux" as default kernel but instead lts? The patch I had been using had made grub perfect but wow @ the waste of time this caused me, totally unnecessary breakage. Can grub really not deal with boot entries in a more acceptable sensible way?

I guess I could just edit the grub.cfg by hand to behave like it should by default...

Last edited by covid19 (2020-08-22 17:30:37)

Trilby · 2020-08-22 17:33:57

Yes there is a sensible way, and it's all covered in the sensible wiki. Forum members can certainly help you if you having trouble implementing the guidance in the wiki, but just venting about it not magically working (or ranting) when there is no evidence at all that you've even read the wiki or tried following the guidance in it is ridiculous - as is assuming GRUB just cannot do this sort of thing that is clearly covered in the documentation.

Last edited by Trilby (2020-08-22 17:34:29)

covid19 · 2020-08-22 18:26:47

I did read the wiki! The "sensible" way is telling it what to highlight in the config file so that's what gets selected on subsequent boot? :\ Seemed more of a workaround than a "fix" unless I'm not reading the correct place or looking at something outdated
Not expecting it to magically work all I'm saying is if someone installs a second kernel its most likely as a backup, and Arch just does everything but treat it as such. Nothing more nothing less

Last edited by covid19 (2020-08-22 18:32:22)

loqs · 2020-08-22 18:35:19

Which wiki page did you follow? Tips_and_tricks#Changing_the_default_menu_entry does not mention higlighting.
What actions did you perform? What is the contents of /etc/default/grub

Trilby · 2020-08-22 20:10:26

covid19 wrote:

... Arch just does everything but treat it as such.

"Arch" doesn't do anything. It's up to you to configure your system, including your boot loader.

covid19 · 2020-08-26 00:28:59

I guess I've "fixed" it properly and repatched the bootloader, regenerated config file and things look sane again...the above referenced patch really ought to be a part of the Arch grub patches, is there some bleeding obvious reason it isn't? Does it negatively affect some other behavior or cause some sort of other conflict further down the line?

It just seems "sensisble", the main linux kernel is the default entry, and then when selecting the second entry "Advanced entries...", linux and linux-fallback are listed first, and then its linux-lts and linux-lts-fallback
Not a rant, just wondering why this patch isn't accepted as default behavior, other distros, hell even manjaro does a phenomenal job handling kernels. I didn't tweak the pkgrel etc values in the PKGBUILD this time so I /shouldn't/ break in the future.
Better to just be not lazy and repatch grub when theres an update for it whether it pertains to me or not. Thanks for the help guys in getting this fixed, almost thought this install was gone...
Feels like a pretty "dirty" install though!, to keep things working until vmware's lame ass can push something out for kernel 5.8, don't these developers get months ahead of notice? What excuse does vmware as a proprietary for profit corp have for not having a product ready for the current linux kernel... Have IgnorePkg on

linux linux-headers qt5-base qtpass gcc gcc-libs

until then probably a good idea to not update much until getting that update before all hell potentially breaks loose

Would still like some insight as to what went wrong in the first place, why alternate versions of GRUBX64 were not booting, what it means @ "end of /boot/vmlinuz-linux reached prematurely" and why copying the GRUBX64 I had previously somehow magically fixed everything It's nice having gone through the wiki way for install and putting it all together so its relatively easy to try and successfully fix things, but I don't understand what's happening with the latter part of this at all. Are those "special EFI" folders/files of some significance

Last edited by covid19 (2020-08-26 01:15:58)

Trilby · 2020-08-26 03:07:26

covid19 wrote:

the above referenced patch really ought to be a part of the Arch grub patches, is there some bleeding obvious reason it isn't?

Because I gather it's not needed if your RTFW and configure your system.

covid19 wrote:

Not a rant ... until vmware's lame ass... don't these developers get months ahead of notice? What excuse does vmware as a proprietary for profit corp have.

Yup, it's not a rant, it's an inflammatory trolling.

covid19 wrote:

Would still like some insight as to what went wrong in the first place

You did. In many ways in this thread.

covid19 · 2020-08-26 03:53:44

How the hell is that trolling ? Just never mind alright, doesn't matter.
People like you with that toxic attitude always looking to put someone down, what is your problem? Half of the post is re paid content, if you were a paying customer and not someone in their mothers basement maybe you'd get half the issue.
If you don't have anything constructive to add, why not just piss off rather than initiate hostility/think you're so slick and smart
Clearly you haven't seen the difference whatsoever between fixing the issue vs adding a cheap low quality band aid fix that which you refer to from the wiki.
It was a legitimate question @ why it couldn't be accepted as a patch instead of taking the piss just being a douche and not answering shit.
Or is your only source of dopamine in life sitting on a linux forum putting other people with much less experience than yourself down. Good job.
At least I'm TRYING to figure shit out.

Last edited by covid19 (2020-08-26 04:15:44)

fukawi2 · 2020-08-26 04:16:03

And we're done here. Two wrongs do not make a right. https://wiki.archlinux.org/index.php/Co … ther_users

Closing.

Arch Linux

#1 2020-08-22 01:21:57

[SOLVED] Install hanging by thread after botched kernel upgrade

#2 2020-08-22 01:26:49

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#3 2020-08-22 01:34:17

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#4 2020-08-22 01:42:32

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#5 2020-08-22 02:30:43

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#6 2020-08-22 03:37:34

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#7 2020-08-22 06:00:14

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#8 2020-08-22 08:23:16

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#9 2020-08-22 12:24:41

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#10 2020-08-22 17:25:34

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#11 2020-08-22 17:33:57

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#12 2020-08-22 18:26:47

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#13 2020-08-22 18:35:19

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#14 2020-08-22 20:10:26

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#15 2020-08-26 00:28:59

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#16 2020-08-26 03:07:26

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#17 2020-08-26 03:53:44

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

#18 2020-08-26 04:16:03

Re: [SOLVED] Install hanging by thread after botched kernel upgrade

Board footer