@suman already 4.17 ist out…
Can you give us any guidance when one of the next rockstor releases will have a new kernel in it?
As always - Thanks
@suman already 4.17 ist out…
Can you give us any guidance when one of the next rockstor releases will have a new kernel in it?
As always - Thanks
So I’ve been running for two weeks now, and it seems very stable. Haven’t noticed any issues at all.
@suman and @phillxnet
With reference to my previous post
4.17.3 is out (stable) and 4.18 is currently in RC2 status
→ are there currently any kernel tests ongoing on your side?
→ when do you expect the next kernel upgrade will come through the rockstor update channel?
I guess there would be a larger interest by all Rockstor users to get this upgrade (bug fixes and performance enhancements) through one of the next official Rockstor releases compared to individual upgrades like done by @kupan787.
Thanks for sharing your feedback with the community!
j’ai actuellement la 4.17.3 avec Rockstor 3.9.2.28 et je n’ai pas constaté de probleme
I currently have 4.17.3 with Rockstor 3.9.2.28 and I have not seen any problem
Hi Matt
(FR) Je vais regarder que je te tien au courant en samedi
(En) Hi Matt
I’ll watch that I’ll let you know on Saturday
@suman or @phillxnet
sorry for insisting here, but as there was again no statement with regards to a possible upcoming kernel upgrade from your side herewith another trial to get your feedback THX
I’ve just done this too although I’m rolling kernel 4.18.5-1 paired with btrfs-progs v4.17.1
Was entirely a requirement as my new i3 coffee lake outright wouldn’t boot with 4.12, and refused to load my NIC in 4.10
No issues so far, I think given the state of BTRFS development we should really be rolling close to bleeding edge here.
For everyone else’s benefit - I needed to yum install python34-setuptools
before make
was happy.
So - kernel manually downloaded, btrfstools built from source, as detailed by @kupan787 in the topic start, with the python-setuptools in between? I really should make the time to just go for it, really…
I went with enabling the kernel-ml package, but functionally it doesn’t really matter. python34-setuptools install can happen with everything else earlier.
It’s fairly low risk since the old kernels are still there to boot to if something goes wrong and you need to revert.
Edit: you can also skip compiling btrfs-progs entirely, but you’ll miss out on whatever bugfixes there are, of course.
thanks!
I still see the ball @ the rockstor owners to implement, it has been a long time since the last kernel update, so it is anyhow time…I’ll wait a bit more before investigating/applying on my own as well
Edit:
My previous attempts to get feedback from @suman were not fruitful at all
I’ve tried to upgrade as well, but at the progs section I get the following error while running the “autogen” command - any advise?
[root@rockstor btrfs-progs]# ./autogen.sh
You must have autoconf installed to generate btrfs-progs build system.
You must have autoheader installed to generate btrfs-progs build system.
The autoheader command is part of the GNU autoconf package.You must have automake installed to generate btrfs-progs build system.
Also when I try to edit the setting via
vi /opt/rockstor/src/rockstor/settings.py
I can change the text, but how can I save and exit this view?
Thx
Did you run the first step for the development tools?
Get dev/build tools
yum group install “Development Tools”
That should get you everything install that you need.
Using vi can be tricky, it has a lot of commands. After you have changes/entered any text, you need to hit ESC on the keyboard to exit the insert mode. Then hit : and type wq. This will write out the output and quit vi.
Alternatively, you can use nano:
nano /opt/rockstor/src/rockstor/settings.py
which can be a bit easier to move around in.
FYI, look like kernel 4.20 is soon to be made available, and contains a number of new fixes.
I’m not sure what kernel rockstor is currently packaged on, but I’m on 4.19, and plan on upgrade to 4.20 as soon as it is available.
So I have upgraded to 4.20, and so far so good. I think I’ve got the process a bit simplified.
This will install the kernel via yum, instead of a manual download:
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
yum -y --enablerepo=elrepo-kernel install kernel-ml
kernelvers=`rpm -qa | grep -i kernel-ml-4.20 | cut -c 11-`
sed -i "/SUPPORTED_KERNEL_VERSION/c\SUPPORTED_KERNEL_VERSION = '${kernelvers}'" /opt/rockstor/src/rockstor/settings.py
grub2-set-default 0
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-editenv list
Build and install the BTRFS tools.
yum -y group install "Development Tools"
yum -y install xmlto.x86_64 asciidoc.noarch e2fsprogs-devel.x86_64 libblkid-devel.x86_64 zlib-devel.x86_64 libzstd-devel.x86_64 python34-devel lzo-devel.x86_64 python34-setuptools
cd
mkdir src
cd src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
cd btrfs-progs/
./autogen.sh
./configure --prefix=/usr/sbin
make
make install
The above for BTRFS progs assumes you didn’t pull down the source before. If you did, then it should be as simple as:
cd ~/src/btrfs-progs/
git pull
./autogen.sh
./configure --prefix=/usr/sbin
make
make install
I followed this guide, and it looked like it worked.
The kernel is reported as “4.20.0-1.el7.elrepo.x86_64” by the rockstor web interface.
But when I run “btrfs version”, in a ssh session i get “btrfs-progs v4.12”
So it seems btrfs progs weren’t updated?
Where could I have gone wrong. I didn’t see any error messages, but would also not know what to be looking for
Rockstor is up and running and everything seems OK, so so far so good …
OK. I found some guides online and found that in the line
./configure --prefix=/usr/sbin
None og the other guides seemed to use the --prefix=/usr/sbin, so I tried again without it.
And voila, after a reboot my btrfs-progs now reads:
btrfs version
btrfs-progs v4.19.1
I hope this didn’t break anything
The reason I did that (with the prefix) is because in the Rockstor code (at least the version I have) the path to btrfs is hardcoded in a few places:
/opt/rockstor/src/rockstor/scripts/qgroup_clean.py:BTRFS = ‘/usr/sbin/btrfs’
/opt/rockstor/src/rockstor/scripts/qgroup_maxout_limit.py:BTRFS = ‘/usr/sbin/btrfs’
/opt/rockstor/src/rockstor/scripts/qgroup_test.py:BTRFS = ‘/usr/sbin/btrfs’
So if you install btrfs-progs from source, and let it install into /usr/local/bin, then Rockstor will continue to use the old version in /usr/sbin (which is v4.12) and not the new one (which is v4.19).
So by using your method, Rockstor will use the new version, but via SSH you’ll get the old version?
This seems rather counter intuitive
Or why did it show 4.12 via SSH?
Just trying to understand
And by doing it two times in different ways, I have two copies of 4.19.1 installed, being used by different parts of RockStor?
When logged in via SSH, it’ll use whatever is on your path. So you must have two versions of the btrfs-profs installed.
You can check the location that is being used in your ash session by typing:
which btrfs
On my system I only have the tools in both /use/sbin and /usr/local/bin
@kupan787 and @KarstenV
Ben, I used the latest instructions that you so graciously posted, and I ran into the same issue as Karsten. After using the same “fix” the tools version also changed to btrfs-progs v4.20.1
“which brtfs” is now giving back: /usr/local/bin/btrfs,
before which brtfs showed the /usr/sbin/btrfs (and when I now directly query the version in that directory it still gives the version btrfs-progs v4.12.).
And the Rockstor version I currently play with (3.9.2-47) has the same hard-coded paths …