[SOLVED] Can’t update kernel

Trilby · 2020-07-06 19:13:22

Good catch, I hadn't looked at the dates. The db was sycnronized many times but not a single thing was ever updated until that overwrite was used to *only* install the linux package and it's dependencies: every other package was left at 6 years out-datated. This is the worst partial upgrade ever. Bosscat, what went wrong with all the attempted updates over the years such that nothing was every actually updated?

Bosscat · 2020-07-06 19:32:28

Oh, my mistake, I didn't notice the archiso flags in the journal

[root@archiso /]# journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal was found.

I've changed the config to make journalctl persistent, but that doesn't really help us currently.

I know overwrite is typically dangerous, I was just getting frustrated. My system was up to date and I was on top of most manual interventions up until this new year when I stopped using this system frequently. I wish I could remember what started all of this but it's been a few months now. I think everything was fine, I updated as usual, and next time I started the laptop it started doing this.

loqs · 2020-07-06 19:38:42

Did you forget to chroot in before `journalctl -b -1`?

Trilby · 2020-07-06 19:40:26

You need to run journalctl from within the chroot to get your system's journal.

Bosscat wrote:

... My system was up to date.

Not according to your pacman log is wasn't. The pacman log doesn't show any package ever being updated until you used the overwrite flag yesterday, and that only then updated a subset of packages. So it would seem that a large portion of your packages are from 2015 or so, while some are current.

Last edited by Trilby (2020-07-06 19:42:06)

Bosscat · 2020-07-06 19:41:58

No, I'm posting this from an X session running through arch-chroot. Really sorry for all the confusion. I'm far from a linux expert, hoping I haven't ruined my whole installation.

Edit: So it seems the pacman.log I posted must be exclusive to the iso as well right? Though that doesn't really make sense... It must only be showing pacman commands I've run from a chroot over the years because that can't be right. I have certainly had 1000's of successful pacman installations and removals from 2014-2020

Last edited by Bosscat (2020-07-06 19:52:32)

loqs · 2020-07-06 19:57:30

pacman.log exists for the installation only. The journal exists for the archiso and the installation.
You can chroot in then the journal will be for the installation or use `journalctl --root=/mnt -b -1` to work on an installation mounted under /mnt.

[2017-09-06 21:35] [PACMAN] Running 'pacman -Syu'
[2017-09-06 21:35] [PACMAN] synchronizing package lists
[2017-09-06 21:35] [PACMAN] starting full system upgrade
[2020-07-03T23:56:55-0400] [PACMAN] Running 'pacman -Syy'
[2020-07-03T23:56:55-0400] [PACMAN] synchronizing package lists
[2020-07-04T00:05:57-0400] [PACMAN] Running 'pacman -Syy'
[2020-07-04T00:05:57-0400] [PACMAN] synchronizing package lists
[2020-07-04T00:08:01-0400] [PACMAN] Running 'pacman -Syy'
[2020-07-04T00:08:01-0400] [PACMAN] synchronizing package lists
[2020-07-04T00:10:32-0400] [PACMAN] Running 'pacman -Syy'
[2020-07-04T00:10:32-0400] [PACMAN] synchronizing package lists
[2020-07-04T00:11:00-0400] [PACMAN] Running 'pacman -Syu'

Is the time gap between 2017-09-06 and 2020-07-03 accurate or is there contents missing from pacman.log?
Edit:
Should clarify the journal exists for the current boot of the archiso in memory only. It is not written to the installation's persistent journal.

Last edited by loqs (2020-07-06 20:02:34)

Bosscat · 2020-07-06 20:19:42

The time gap is absolutely inaccurate, there is a massive amount of content missing from pacman.log.

I’m having some serious issues with logs... on the iso AND in chroot I’m seeing

journalctl —list-boots

only showing one boot ID, which is from me booting the iso. I must be making a rookie mistake here.

Last edited by Bosscat (2020-07-06 20:20:06)

Trilby · 2020-07-06 20:32:00

From the live iso outside the chroot, mount *every* partition on the machine one by one. Mount a partition on /mnt, the run the following two commands, then unmount the partition, and move on to the next one:

ls -ld /mnt/*
find /mnt -name pacman.log
find /mnt -name fstab

Then for any partition that has an fstab, post the content of that fstab here (as well as which partition it was on).

We know your partitions got swapped around at least once, maybe it happened more than once (e.g., maybe the "swap" and "root" partitions were mixed up at some point).

Bosscat · 2020-07-06 21:05:24

Well, I must be slow. /dev/sda2 is a /var partition, for whatever reason. I haven't been mounting that, lol. Doing as you say, I've found the missing pacman logs on /dev/sda2 but it's 24,000+ lines. I can post the last month or so since that'll be the most relevant. fstab only exists on /dev/sda1, root, and doesn't seem to have any issues that I can tell. Here it is: https://pastebin.com/XHatkwKG

loqs · 2020-07-06 21:11:42

Is the journal for the system's last boot found with /var mounted to /mnt/var?

jasonwryan · 2020-07-06 21:17:20

Just reinstall. If nothing else, you may learn how an Arch system actually works.

Bosscat · 2020-07-06 21:28:40

jasonwryan wrote:

Just reinstall. If nothing else, you may learn how an Arch system actually works.

I considered this but that would be a bit counter intuitive after spending all of this time trying to salvage it.

loqs wrote:

Is the journal for the system's last boot found with /var mounted to /mnt/var?

Yes, it is. Now I have some insight on whats actually gone wrong. As this has gone too far from the original topic, I'll close the thread. I appreciate all the help.

Trilby · 2020-07-06 21:32:06

Well, there is an issue in that sda2 should be mounted with that fstab, but apparently very rarely has been. In any case, this sporadic mounting of another partition over /var would be the source of your symptoms. We could try to keep digging to find the exact causal path from that source to your current symptoms, but the fact is there likely are other symptoms that may not currently be evident, and the solutions would be about the same anyways.

I'd second the recommendation for a reinstall. But this can be done without touching your home partition. Just make new filesystems on sda1-3, mount them appropriately but don't mount home, then istall the "new" system. You can add back your home partition with all it's data still intact after that.

I'd encourage you to also reconsider whether you want a seperate var partition. If it were me, I'd remove sda2 and expand sda1 to claim that space. As you are using the same filesystem on sda1+2 and sda1 is mounted rw, neither of the common purposes for a seperate var partition are even being taken advantage of.

jasonwryan · 2020-07-06 21:32:30

Bosscat wrote:

jasonwryan wrote:
Just reinstall. If nothing else, you may learn how an Arch system actually works.
I considered this but that would be a bit counter intuitive after spending all of this time trying to salvage it.

How would learning about your system be counter-intuitive? Or would you prefer to just keep typing the commands that the people in this thread are feeding you?

Trilby · 2020-07-06 21:53:45

Well, to be fair, it could be counterintuitive, but human intuition sucks. Regardless of whether it would be intuitive, I'd argue that reinstalling would be the most logical and rational next step by a substantial margin.

loqs · 2020-07-06 22:05:38

If you do not reinstall at least remove the contents of /var/ on the root filesystem so that in future if you forget to mount /var in the chroot pacman operations will fail due to the lack of databases.
Also reinstall all packages due to there being two sets of pacman databases producing a confused set of updates and ensure the contents of fstab is correct.

Bosscat · 2020-07-06 22:20:45

Considering the amount of issues in the journal, I have to agree. The sunk cost was definitely something I was thinking about, but I can only see that getting worse from here. Had this setup for so long I barely know what I've done to it in the past, but since I don't have to touch /home it will certainly be best to know where and why everything else is the way it is. Thanks again!

Arch Linux

#26 2020-07-06 19:13:22

Re: [SOLVED] Can’t update kernel

#27 2020-07-06 19:32:28

Re: [SOLVED] Can’t update kernel

#28 2020-07-06 19:38:42

Re: [SOLVED] Can’t update kernel

#29 2020-07-06 19:40:26

Re: [SOLVED] Can’t update kernel

#30 2020-07-06 19:41:58

Re: [SOLVED] Can’t update kernel

#31 2020-07-06 19:57:30

Re: [SOLVED] Can’t update kernel

#32 2020-07-06 20:19:42

Re: [SOLVED] Can’t update kernel

#33 2020-07-06 20:32:00

Re: [SOLVED] Can’t update kernel

#34 2020-07-06 21:05:24

Re: [SOLVED] Can’t update kernel

#35 2020-07-06 21:11:42

Re: [SOLVED] Can’t update kernel

#36 2020-07-06 21:17:20

Re: [SOLVED] Can’t update kernel

#37 2020-07-06 21:28:40

Re: [SOLVED] Can’t update kernel

#38 2020-07-06 21:32:06

Re: [SOLVED] Can’t update kernel

#39 2020-07-06 21:32:30

Re: [SOLVED] Can’t update kernel

#40 2020-07-06 21:53:45

Re: [SOLVED] Can’t update kernel

#41 2020-07-06 22:05:38

Re: [SOLVED] Can’t update kernel

#42 2020-07-06 22:20:45

Re: [SOLVED] Can’t update kernel

Board footer