Upgrading to latest elrepo kernel - kernel-ml-4.15.0-1.el7.elrepo.x86_64.rpm

[jim.allum]

I experienced a kernel panic with stable kernel update 4.12.4-1.e17.elrepo.x86_64 from 4.10.6-1, running under hyper-v, not long after boot. This appeared to happen after the Resilio rock-on started to sync, although I do not think this is related to the rock-on and may be an IPV6 problem in the kernel from what I have read elsewhere.

You can see full details of this original problem at:

kernel panic after upgrading to 4.12.4-1.e17.elrepo.x86_64 (hyper-V VM)

I decided to upgrade the kernel to the latest stable elrepo kernel kernel-ml-4.15.0-1.el7.elrepo.x86_64.rpm which can be found at Index of /linux/kernel/el7/x86_64/RPMS.

I downloaded the kernel RPM file and saved it into one of my Rockstor samba shares which was located using the following Rockstor system shell commands in this screen shot when logged in using user root:

Replace “iso” with the name of your Rockstor share.

I then issued the following shell commands:

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -i kernel-ml-4.15.0-1.el7.elrepo.x86_64.rpm

I now have 3 kernels available, the original working kernel-ml-4.10.6-1.el7.elrepo.x86_64, the one that crashes after the last Rockstor stable update, kernel-ml-4.12.4-1.el7.elrepo.x86_64 and the latest one kernel-ml-4.15.0-1.el7.elrepo.x86_64.rpm. See the gihubt report for a screen shot of this at:

kernel panic after upgrading to 4.12.4-1.e17.elrepo.x86_64 (hyper-V VM)

My Rockstor system now performs without any problem. No more kernel panic.

Currently, I am selecting the latest newly installed stable kernel-ml-4.15.0-1.el7.elrepo.x86_64.rpm manually, but I will research this next to make this the default boot kernel.

Hope this helps.

[phillxnet (Philip Guyton)]

@jim.allum Welcome to the Rockstor community. Nice write-up and thanks for sharing it. Glad you found a work around for your 4.12 kernel related issue.

@jim.allum

… but I will research this next to make this the default boot kernel.

On a related note to the above Rockstor’s banner warning reference re the kernel version not matching it’s ‘idea’ on what you should be running: that info/setting is held in the following file:

/opt/rockstor/src/rockstor/settings.py.

Under the entry:

SUPPORTED_KERNEL_VERSION

I.e the current entry (given we currently assume 4.12) is as follows:

SUPPORTED_KERNEL_VERSION = '4.12.4-1.el7.elrepo.x86_64'

Try changing that entry (ie via nano) to the full version reference of your installed kernel:
ie “4.15.0-1.el7.elrepo.x86_64”

Linking to a prior forum request for the same info when we ran a much older kernel where, like your experience, a newer variant was required; @Dragon2611 related post:

Override Kernel autoboot?

How do I override the auto boot of the rockstor kernel I used to have problems with 4.2x and BTRFS crashes I haven’t tried the latest offical kernel but tbh it’s running fine with my 4.3x kernel. At the moment if I shutdown/reboot (admittedly doesn’t happen often, usually only if I need to patch proxmox) i have to remember to set the kernel back to 4.3x on boot which means I can’t use autostart.

Let us know how that works out.

Thanks again for sharing your findings.

[jim.allum]

Hi Phil
Thanks this suppressed the warning message.
Unfortunately, at boot it always selects the 4.12 kernel and I have to manually select the latest 4.15 kernel that I now want to run. If I have an unscheduled reboot, I will end up with a kernel panic again which I am keen to avoid, at this renders Rockstor offline.
I hate to ask, but can you please point me at how to change the default boot kernel.
I have tried:

rockstor login: root
root@rockstor’s password:
Last login: Sun Feb 4 11:54:13 2018 from rockstor
[root@rockstor ~]# grub2-set-default 0
[root@rockstor ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file …
Found linux image: /boot/vmlinuz-4.15.0-1.el7.elrepo.x86_64
Found initrd image: /boot/initramfs-4.15.0-1.el7.elrepo.x86_64.img
Found linux image: /boot/vmlinuz-4.12.4-1.el7.elrepo.x86_64
Found initrd image: /boot/initramfs-4.12.4-1.el7.elrepo.x86_64.img
Found linux image: /boot/vmlinuz-4.10.6-1.el7.elrepo.x86_64
Found initrd image: /boot/initramfs-4.10.6-1.el7.elrepo.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-c781a2c0d7ae4472b62e1a4afe115c00
Found initrd image: /boot/initramfs-0-rescue-c781a2c0d7ae4472b62e1a4afe115c00.img
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (stretch/sid) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (8.10) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (9.3) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (8.0) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
Found Debian GNU/Linux (7.11) on /dev/sdb
done
[root@rockstor ~]# grub2-editenv list
saved_entry=0
[root@rockstor ~]# awk -F’ ‘$1=="menuentry " {print i++ " : " $2}’ /etc/grub2.cfg
0 : Rockstor (4.15.0-1.el7.elrepo.x86_64) 3 (Core)
1 : Rockstor (4.12.4-1.el7.elrepo.x86_64) 3 (Core)
2 : Rockstor (4.10.6-1.el7.elrepo.x86_64) 3 (Core)
3 : Rockstor (0-rescue-c781a2c0d7ae4472b62e1a4afe115c00) 3 (Core)
[root@rockstor ~]#

Thanks

[Haioken]

Hi @jim.allum,

Are you booting EFI? You can check for the existence of EFI firmware:

[ -d /sys/firmware/efi ] && echo "EFI" || echo "BIOS"

If booting EFI, you may be modifying the wrong grub config location (/boot/grub1/grub.cfg)
The correct location may be /boot/efi/EFI/centos/grub.cfg

[doenietzomoeilijk (Max)]

I was wondering: since the newer kernel should include a ton of BTRFS improvements, would this require a newer set of btrfs-progs, or is that mostly independent on the kernel version?

[phillxnet (Philip Guyton)]

@doenietzomoeilijk Hello again.

… would this require a newer set of btrfs-progs, or is that mostly independent on the kernel version?

Ideally yes, but my understanding is that it is not a necessity. And when there is a mismatch the lowest common denominator would prevail. When Rockstor updates it’s kernel the btrfs-progs is kept in step to optimise this arrangement.

[kupan787 (Ben)]

@phillxnet do you know if there is a timeframe for when Rockstor will push the new kernel and btrfs-progs out?

[phillxnet (Philip Guyton)]

@kupan787 Hello again.

@kupan787

… do you know … when Rockstor will push the new kernel and btrfs-progs out?

Sorry, I have yet to be involved with that side of things. But it’s definitely due. I think @suman is waiting for the
Meltdown and Spectre fixes to settle. Please see my other response to your other update question for more details on how to address this yourself if need be.

Thanks for your patience: kernel updates can be quite problematic especially earlier in a series ie see:

SSD Read / Write Caching

This does not affect any Rockstor releases but for those experimenting with kernel versions please note that early 4.14 kernels had an issue that affected bcache (with all fs types). But this was apparently fixed in 4.14.2: from: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg70825.html we have: > There is a known bug in 4.14 that affects all bcache backed file > systems (maybe more, I think it's not a bcache specific bug). You need > to downgrade or upgrade your kernel. Fix shou…