[solved] System upgrade without updating to the new kernel

nstgc · 2014-10-30 00:25:53

My system relies heavily on btrfs, which has a nasty bug in 3.17.1 that causes random corruption, especially for those systems using snapshots. I create about 8 snapshots each day. As a result I haven't run a system upgrade in a week. While I don't consider this to be too bad, I can't just wait around for a kernel to come out that won't break my system. I need to do something about this.

From my understanding of how Arch works, packages assume certain system configuration, such as which kernel is being run. For this reason I doubt I can simply run an upgrade with the kernel and a number of other core packages blacklisted. My next thought would be to migrate to LTS, however that would likely be too time consuming during the middle of the semester, and also I'm concerned about btrfs's backwards compatibility.

Prior to Arch I stayed in the Ubuntu subfamily of Debian where I never had to think about this sort of thing, and so now I don't know what to do. Aside from "you shouldn't have used btrfs" and "go back to Ubuntu n00b", what would be a reasonable way of handling this situation?

[edit] In the future I will likely black list the problematic update, however for now, since a fix is in testing, I'll just wait a few more days.

Last edited by nstgc (2014-10-31 16:54:09)

graysky · 2014-10-30 00:30:15

Why would `pacman - S linux-lts` be too time consuming?

firecat53 · 2014-10-30 00:40:40

I routinely add 'linux linux-headers' to the pacman.conf IgnorePackages line on all my Arch machines. This allows me to only upgrade the kernel and reboot when I'm ready. Whether that's best practice is debatable, but pacman will complain if you try and upgrade another package that depends on a higher kernel version, so I've considered it to be relatively safe and haven't yet experienced issues.

I am also awaiting the repair of the btrfs bugs before I upgrade.

Scott

Last edited by firecat53 (2014-10-30 00:42:22)

nstgc · 2014-10-30 00:45:20

graysky wrote:

Why would `pacman - S linux-lts` be too time consuming?

Time isn't my only concern. I also worry about issues that may arise from accessing a filing system that is "use to" being accessed by a newer kernel. I don't know if this is an issue or not.

Also, I know that Arch requires user intervention. Running a package manager certainly takes no time at all. The user intervention needed to keep things from crashing to the ground is another thing entirely. I tried searching for information on switching back and forth from lts to normal kernel, however this didn't turn anything up.

Before I do something potentially system breaking during an insane part of the semester, I was hoping to get some advice.

firecat53 wrote:

I routinely add 'linux linux-headers' to the pacman.conf IgnorePackages line on all my Arch machines. This allows me to only upgrade the kernel and reboot when I'm ready. Whether that's best practice is debatable, but pacman will complain if you try and upgrade another package that depends on a higher kernel version, so I've considered it to be relatively safe and haven't yet experienced issues.

Since I am fairly n00b at maintaining Arch (I've only been doing it since March), I'd rather avoid anything like that unless I can get a definitive "yeah its totally cool to blacklist kernel updates".

Last edited by nstgc (2014-10-30 00:48:48)

Trilby · 2014-10-30 00:47:12

I don't think I have any packages installed that have a specific kernel version dependency. I'm curious how many (if any) there are in the repos that need latest kernel. I doubt holding kernel (and header) updates for a week or two, or even a month or two, could have any negative side-effects at all.

GSF1200S · 2014-10-30 01:08:46

I believe the kernel issue applies only to read-only snapshots. In the interim you could switch to read-write snapshots if possible in your use case.

As for blacklisting the kernel, that will be fine for a time. You will likely have to downgrade vid drivers and possibly others, but just blacklist them until a new kernel comes out that fixes the btrfs problem. Memory serves me correctly the btrfs problem has already been fixed, so its just a matter of when Arch packages and releases a new kernel.

ratcheer · 2014-10-30 15:30:11

I'm also waiting on a new kernel revision that I hope will include the btrfs patches from upstream. I have been running "pacman -Syu", then replying "n", then running "pacman -S" with a list of packages excepting the 3.17.1 kernel. So far, I haven't had any dependency problems.

Tim

jasonwryan · 2014-10-30 16:09:19

ratcheer wrote:

I'm also waiting on a new kernel revision that I hope will include the btrfs patches from upstream. I have been running "pacman -Syu", then replying "n", then running "pacman -S" with a list of packages excepting the 3.17.1 kernel.

man pacman.conf | less -p IgnorePkg

ratcheer · 2014-10-30 17:31:12

Thanks, @jasonwryan. Done and done.

Tim

nstgc · 2014-10-31 16:53:19

I think for future issues I will just do as suggested here, to black list updates to the kernel. However, since a fix is in testing, I'll just wait another few days. Thanks for the advice.

GSF1200S · 2014-10-31 17:00:09

I have confirmed in #btrfs on freenode (IRC) that this problem affects people who take ro snapshots on a 3.17.0 kernel (which all of us already knew).

Further, btrfs-progs 3.17.2 now has code that can FIX the corruption caused by this bug, but it can still happen again if using a 3.17.0 kernel. Any linux kernel equal to or later than 3.17.2 has been patched where this corruption is no longer a problem.

In the interim you can either grab a kernel from the AUR that is 3.17.2 or later, downgrade to a kernel version older than 3.17.0, use only rw snapshots, or stay with the latest kernel and install btrfs-progs-git from the AUR which contains the code that can fix the corruption.

**EDIT**
Another option since there is a 3.17.2 linux kernel in the Testing repo is to download it manually from the website/mirror and pacman -U it onto the system. Be forewarned that its in testing because it hasnt been verified stable yet, but the option is there..

Last edited by GSF1200S (2014-10-31 18:00:46)

ratcheer · 2014-10-31 21:22:00

Thank you, @GSF1200S

Tim

lucke · 2014-10-31 21:48:44

<tips>I normally have linux in IgnorePkg and run "pacman -S linux" whenever pacman has told me that a kernel update is available (but ignored) and I plan to reboot (one would have to do the same for nvidia and nvidia-utils and whatnot). "pacman -Syu linux" works too, if I want to have a complete update through one command. Additionally, I have the testing repo uncommented at the bottom of pacman.conf, thus the newest kernel is just "pacman -S testing/linux" away.</tips>

Last edited by lucke (2014-10-31 21:54:32)

Arch Linux

#1 2014-10-30 00:25:53

[solved] System upgrade without updating to the new kernel

#2 2014-10-30 00:30:15

Re: [solved] System upgrade without updating to the new kernel

#3 2014-10-30 00:40:40

Re: [solved] System upgrade without updating to the new kernel

#4 2014-10-30 00:45:20

Re: [solved] System upgrade without updating to the new kernel

#5 2014-10-30 00:47:12

Re: [solved] System upgrade without updating to the new kernel

#6 2014-10-30 01:08:46

Re: [solved] System upgrade without updating to the new kernel

#7 2014-10-30 15:30:11

Re: [solved] System upgrade without updating to the new kernel

#8 2014-10-30 16:09:19

Re: [solved] System upgrade without updating to the new kernel

#9 2014-10-30 17:31:12

Re: [solved] System upgrade without updating to the new kernel

#10 2014-10-31 16:53:19

Re: [solved] System upgrade without updating to the new kernel

#11 2014-10-31 17:00:09

Re: [solved] System upgrade without updating to the new kernel

#12 2014-10-31 21:22:00

Re: [solved] System upgrade without updating to the new kernel

#13 2014-10-31 21:48:44

Re: [solved] System upgrade without updating to the new kernel

Board footer