Linux 6.4 To Remove Old Workaround For Running On Very Outdated Distributions

[kneedragon]

This affects literally no one.

[shrug] I'd agree, it effects a very small number of users or situations. I can sorta see a point to allowing newer kernels into older installs for maybe 3 ~ 4 years or something, but 15? This is a little bit ridiculous.

[oiaohm]

I had the opposite case. Old redhat outside, new debian inside the chroot. New kernel was required for some chroot features and generally for the chrooted application.

It simple to forget you can start a cgroup isolation or chroot isolation in system appearance can start in the initramfs.

SYSFS_DEPRECATED with new in old and old in new either way is not ideal helpful. Using new mount options to help up with chroot you would be wanting the /sys/class/block/ bit. Note the thing that since 2009/2010 the new tooling don't work with SYSFS_DEPRECATED.

Yes even what appears to be a opposite case can be turned into new with old inside at the initramfs.

For the remaining cases it will be just getting use to doing it the other way. So SYSFS_DEPRECATED disappearing makes no difference to the software that can be run. Only changes the method to run the old software.

[mangeek]

I had the opposite case. Old redhat outside, new debian inside the chroot. New kernel was required for some chroot features and generally for the chrooted application.

I'm guessing these changes will break chroot for a bunch of those use cases, if they're not already broken. Still, that buys you about. four years from now with a mainstream enterprise/LTS distro before you're totally on your own, right?

[oiaohm]

I'm guessing these changes will break chroot for a bunch of those use cases, if they're not already broken. Still, that buys you about. four years from now with a mainstream enterprise/LTS distro before you're totally on your own, right?

Not break in unfixable ways. /sys/class/block/ mapped to /sys/block/ is what the removed feature does and the way it does it the /sys/class/block/ disappears.

mount --bind /sys/class/block /sys/block

Ok the result of that mount --bind command block directory exists in both locations at the same time. So new and old programs will work after that..

I guess 1 bind mount being done in the initramfs would fix over 99.9% of issues of the feature being removed.

This is why it does not pay to guess. You have to remember back in 2006 when feature that was just removed now as added to the Linux kernel mount --bind did not exist in the Linux kernel. Same kind of move stuff around happened today a feature like SYSFS_DEPRECATED would not be added instead it would be use mount --bind.

Linux kernel has changed a lot since 2006 including adding new ways to solve problems.

So running really old distributions with new kernel is still possible just method changes slightly. Yes that mount --bind can be done from the initramfs.

[hwertz]

I'm relatively close on this one. I have an Ubuntu 11.04 system I have mythtv (DVR) running on, but with a Ubuntu 18.04 HWE 32-bit kernel (5.4 kernel like 20.04 shipped with originally.) I installed this when I bought a second USB tuner and realized it was far too new for the kernel on there to use. I had to disable "propolice" security (since 18.04 has more stringent security, with more settings that the 11.04-era settings didn't provide), and that was it. I added the new tuner to mythtv, the old tuners still showed up, everything was up and running fine without having to fiddle with a thing.

But even that is an extreme case, I was more pleasantly surprised it did work than expecting it to though. I was expecting to make sure my backup was up to date, install a new ubuntu install and reinstall mythtv on there. Good on them for ditching some kernel kruft.