On 2017-09-20 00:29, Anton Aylward wrote:
On 19/09/17 08:14 AM, Carlos E. R. wrote:
On 2017-09-19 13:57, Anton Aylward wrote:
On 19/09/17 07:28 AM, Per Jessen wrote:
This is also all YaST-only, and I still find it pretty odd, but it won't prevent anyone continuing to use reiserfs.
it WILL prevent anyone using the installer to upgrade to leap15 if they want to continue using ReiserFS. it looks like there will be no provision in the Leap15 kernel for ReiserFS as a module any more.
Only if it is used on the "/" partition.
No, ANY AND ALL. it says quite clearly that it scans all entries in the /etc/fstab
And then *suggests* to change it. Does not block the upgrade.
ReiserFS never was part of the kernel, it was always a module. If you wanted it in the kernel you had to recompile it yourself. Ditto Reiser4.
But the announcement doesn't say anything about removing the module from the distribution kernel, only from YaST.
YaST is just a UI front end. You can't remove Reiser fro Yast since it was never in yast in the first place.
Yes, it was. We could, in the past, create reiserfs partitions. The YaST partitioner supported it. Leap does not.
ReiserFS is, at lest up to the kernel I'm running, 4.13.2-1.g68f4aee-default, under 42.2, a module. It never was compiled into a distribution, though heavens knows what the Build Service may have produced! I've always used it as a module.
That reiserfs was and is compiled as a module doesn't mean it is not part of the kernel or that it is built separately. It does not matter, it is an integral part of the kernel. As always, except when it was born. The only difference is that if you do not have any reiserfs partition, you save some kernel memory space.
Now the issue is whether or not Leap-15 removes it as a module. Forget this obsession with yast.
The announcement is only about YaST. Forget what RB said, there is no announcement to remove it from the kernel. I don't think he has that power, as it comes from upstream. At worst, he could disable ('n') its compilation, and then we would have to build our own kernels. A nuisance, certainly. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)