Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Why is the latest kernel supported by ZFS removed shortly...
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
stefantalpalaru
n00b
n00b


Joined: 11 Jan 2009
Posts: 65
Location: Italy

PostPosted: Wed Aug 14, 2024 9:57 pm    Post subject: Reply with quote

sitquietly wrote:
Single-disk zfs is pointless (use btrfs for that -- you get very nice bootable snapshots).


On the contrary. ZFS is much more reliable than btrfs, as long as you don't use encryption.

sitquietly wrote:
There is no protection from corruption on a single-disk since there is no redundancy. So any error can be detected, but cannot be corrected. When the corruption is detected the disk will not mount.


It will mount read-only, allowing you to recover your uncorrupted data: https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/importing-pool-read-only-mode.html
Back to top
View user's profile Send private message
sitquietly
Apprentice
Apprentice


Joined: 23 Oct 2010
Posts: 150
Location: On the Wolf River, Tennessee

PostPosted: Wed Aug 14, 2024 10:43 pm    Post subject: Reply with quote

stefantalpalaru wrote:
sitquietly wrote:
Single-disk zfs is pointless (use btrfs for that -- you get very nice bootable snapshots).


On the contrary. ZFS is much more reliable than btrfs, as long as you don't use encryption.

sitquietly wrote:
There is no protection from corruption on a single-disk since there is no redundancy. So any error can be detected, but cannot be corrected. When the corruption is detected the disk will not mount.


It will mount read-only, allowing you to recover your uncorrupted data: https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/importing-pool-read-only-mode.html


Thank for that info. I don't know from experience because I've never had a single-disk zfs boot drive fail or even have unrecoverable errors. I can't say that either zfs or btrfs is better for a single-disk, I've used both without problems.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20479

PostPosted: Wed Aug 14, 2024 10:54 pm    Post subject: Reply with quote

sitquietly wrote:
There is no protection from corruption on a single-disk since there is no redundancy. So any error can be detected, but cannot be corrected. When the corruption is detected the disk will not mount.
Can you point to documentation that clarifies this? As far as I know, the "copies" property does just that and would have been available in the open source version of ZFS. Quoting only the relevant information:
The copies Property wrote:
Available values are 1, 2, or 3. The default value is 1. These copies are in addition to any pool-level redundancy, such as in a mirrored or RAID-Z configuration.
Quote:
Provides data protection, even when only a single disk is available.
https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/copies-property.html

I've never used Solaris 11, though I'm almost certain I remember it from Solaris 10.

EDIT: I don't recall the term "ditto blocks," but it indeed appears to have been there.

From 2006:
https://web.archive.org/web/20150301234541/https://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
lars_the_bear
Guru
Guru


Joined: 05 Jun 2024
Posts: 512

PostPosted: Thu Aug 15, 2024 7:01 am    Post subject: Reply with quote

pjp wrote:
I'm not a lawyer either, but it's business and business law happens every day. If Oracle wanted to, there's probably little from stopping them from doing it. Oracle / Larry has demonstrated they don't really care about the non-business Linux community. It would also be relatively easy to say, "Sorry, we tried and it can't be done." So it isn't even worth that much of their time.


In my experience, nothing in corporate contract law is 'relatively easy'. I've been waiting three years for my company's lawyers to give me an opinion on whether the work I do complies with Oracle's EULA. Almost everybody I work with thinks the situation is uncomplicated, but none of them are lawyers, or even kind-of-ex-lawyers like me. The real lawyers don't think it's uncomplicated. Of course, there's always a possibility that they're making it out to be more difficult than it is, to hike their fees. Sure won't be the first time a lawyer did that.

You say " If Oracle wanted to, there's probably little from stopping them from doing it." I say that there's a whole world of complexity hidden in that 'probably'. My gut feeling is that the version of ZFS that Oracle owns all the IP rights to is likely to be quite old -- possibly pre-dating OpenSolaris. I don't think that Oracle can appropriate the IP rights of contributions to ZFS post-CDDL. I suspect that the version of ZFS that Oracle could release, without legal risk to itself, under GPL would be a version that nobody actually wanted. But who knows? Maybe Oracle has a private version that it's been maintaining using its own resources since the OpenSolaris days? If they do, they aren't saying.

It would certainly be easy for Oracle to say "Sorry, we tried and it can't be done". But I doubt it would be easy to say that with any conviction. That's where the lawyers come in. It isn't worth any of Oracle's time, because they won't make any money out of it. Other businesses have ways to make money from open source; Oracle, on the whole, does not. Spending money in the interests of being a good citizen is a good way to have the shareholders fire the directors.

In the interests of full disclosure, I should point out that I once knew barely enough about IP law to scrape a passing mark in the examination, and that was 20+ years ago. I'm really, really not an expert on this. My point is that everybody else who is arguing one way or the other, if you'll pardon me for saying so, is not an expert either. If there actually is somebody on this forum who is a specialist IP lawyer, I'll defer to that person's judgement.

I also have to point out that I'm not defending Oracle on anything except the very narrow point at issue here.

BR, Lars.
Back to top
View user's profile Send private message
gienah
Developer
Developer


Joined: 24 Nov 2010
Posts: 213
Location: AU

PostPosted: Thu Aug 15, 2024 7:12 am    Post subject: Reply with quote

zfs seems to compile, boot and run with kernel 6.10.5 with the zfs-kmod-2.2.5.ebuild tweaked to build against 6.10:

Code:
/ # diff -ur /var/db/repos/gentoo/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild /var/db/repos/xportage/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild
--- /var/db/repos/gentoo/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild  2024-08-11 09:37:18.955494720 +1000
+++ /var/db/repos/xportage/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild        2024-08-15 12:30:45.122117317 +1000
@@ -9,7 +9,7 @@
 DESCRIPTION="Linux ZFS kernel module for sys-fs/zfs"
 HOMEPAGE="https://github.com/openzfs/zfs"

-MODULES_KERNEL_MAX=6.9
+MODULES_KERNEL_MAX=6.10
 MODULES_KERNEL_MIN=3.10

 if [[ ${PV} == 9999 ]] ; then
@@ -110,6 +110,10 @@
                # Set module revision number
                sed -Ei "s/(Release:.*)1/\1${PR}-gentoo/" META || die
        fi
+
+       sed -i META \
+               -e "s/\(Linux-Maximum:\) .*/\1 ${MODULES_KERNEL_MAX}/" \
+               || die
 }

 src_configure() {
/ #
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20479

PostPosted: Thu Aug 15, 2024 3:52 pm    Post subject: Reply with quote

lars_the_bear wrote:
In my experience, nothing in corporate contract law is 'relatively easy'. I've been waiting three years for my company's lawyers to give me an opinion on whether the work I do complies with Oracle's EULA.
It would seem that the EULA issue isn't considered a high priority.

Quote:
You say " If Oracle wanted to, there's probably little from stopping them from doing it."
Quote:
It would certainly be easy for Oracle to say "Sorry, we tried and it can't be done".
The point I was trying to make is that the possible situations are limited. They own it, they don't, or they don't know; they don't want to change the license, they can't change the license, or it costs to much to try to determine if they can change the license / it serves no business interest. As a partial answer, we know that they discontinued the open source effort and have made no indication of changing their mind. That also seems to indicate they have rights to any external contributions made while it was open. It was discontinued in 2010... is there a statute of limitations on claims?


lars_the_bear wrote:
If there actually is somebody on this forum who is a specialist IP lawyer, I'll defer to that person's judgement.
That doesn't take a specialist. Either they own it, they don't, or they don't know. As far as the licensing issue is concerned, this section has some interesting references. Elsewhere there's a comment that there was belief among some involved at Sun that the CDDL was "not an obstacle."
https://en.m.wikipedia.org/wiki/CDDL#ZFS_in_the_Linux_kernel
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
eschwartz
Developer
Developer


Joined: 29 Oct 2023
Posts: 214

PostPosted: Fri Aug 16, 2024 6:31 am    Post subject: Reply with quote

lars_the_bear wrote:

The legal situation is way, way more complicated than you think. FWIW I do, in fact, have a law background, although I haven't practised for a long time. But I retain just enough grasp of intellectual property law to realize how difficult it is to fiddle about with license terms after the fact. Open-source licenses are painful to adjudicate at the best of times, even when nobody is trying to change things. This is an area of law which is still in its infancy. Which, in lawyer-speak, means "add another couple of zeros to the invoice".


The scenario of a real, true, honest to goodness rights-holder choosing to re-license their software, is something there's quite a bit of real world experience for. Lawyers have, in fact, written public statements about it (and sometimes they even write license terms that talk about it).

Granted it's more common to see them take a GPL thing, make it closed source, and start selling it for money while not permitting customers to see or share the source (things that the GPL requires, if only the GPL were being followed here).

I have not heard of anyone else consider the topic to be ambiguous. The rights-holder of a work is permitted to do ANYTHING, no exceptions, with their OWN work. Licenses exist to tell other people what they can do with stuff that doesn't belong to them.

Open Source communities strive hard to guarantee that "the rights-holder of a work" is no one single person, because then no rights-holder can infringe on *another* rights-holder's work, and license changes can only occur when all contributors agree. This is beneficial to them, because they chose an open source license and now their biggest fear is that it suddenly becomes closed source. Corporate communities combat this by only accepting contributions under the terms of a CLA.

Licenses are, also, legal documents. Interpreting the exact meaning and ramifications of a legal document is certainly something lawyers charge good money for due to the complexity. But again, if you're the rights-holder then you aren't subject to a license.

So it boils down to, is Oracle the rights-holder for ZFS? Is Oracle a partial rights-holder but has to negotiate with other rights-holders? If so, who?

As you yourself pointed out, they bought Sun to obtain control over Java, not ZFS. I don't have to be a lawyer to doubt that when Oracle bought Sun, they acquired all of Sun's IP, "just in case", and didn't turn their nose up at the ZFS portion of the old Sun IP. I daresay that Oracle has just as much right to make legally binding decisions about ZFS as Sun did.

Which leads us to...

lars_the_bear wrote:

And even if I'm wrong about that, you still haven't told me why Oracle should attract criticism for not doing something which they have absolutely nothing to gain by doing.


Indeed. Oracle has every ability and capability to relicense ZFS under the GPL2, or the MIT if they like. They won't, because (this is specifically an Oracle company culture thing) they won't do anything that doesn't make them money, and changing the ZFS license is not a money-making operation.

But they *could*. It is correct to say that Oracle *could* solve this problem if they wanted to. It is foolish to expect Oracle to care what we think though. :) And that's why it hasn't happened, in all these years.


lars_the_bear wrote:

PS. You can spot the qualified lawyers because they are the people who won't offer a legal opinion on a web forum. Everybody else seems to be willing to do this. The most important thing you learn in law school is how complicated everything is, and how hard it is to express general principles.


Hmm, I thought the lawyers are the people who won't offer a legal opinion on a web forum, because legal opinions are valuable and worth lots of money when they come from a lawyer. :)

lars_the_bear wrote:

You say " If Oracle wanted to, there's probably little from stopping them from doing it." I say that there's a whole world of complexity hidden in that 'probably'. My gut feeling is that the version of ZFS that Oracle owns all the IP rights to is likely to be quite old -- possibly pre-dating OpenSolaris. I don't think that Oracle can appropriate the IP rights of contributions to ZFS post-CDDL. I suspect that the version of ZFS that Oracle could release, without legal risk to itself, under GPL would be a version that nobody actually wanted. But who knows? Maybe Oracle has a private version that it's been maintaining using its own resources since the OpenSolaris days? If they do, they aren't saying.


This is a very valid point. Making today's OpenZFS mergeable for the linux kernel would require a) Oracle to grant permission for the IP that belongs to Oracle, b) the OpenZFS developers and contributors to grant permission for the IP that belongs to them.

It could certainly be done -- if Oracle cared or wanted to. The OpenZFS team has done themselves exactly zero favors here, because they could have licensed "all future contributions under a dual CDDL / GPL2 license" and then tried to either get Oracle on-board or suffer the rather painful legal process of vetting all the code, checking to see how much of Oracle's IP is actually left, and then rewriting/reimplementing what remains so that they could say "all code that still exists today is GPL2-compatible".

OpenZFS has options too -- and they even considered doing it for about a minute, before getting huffy because GregKH said he didn't believe they could do it and they are full of hot air and he's not backing down on his opinion that OpenZFS sucks. So OpenZFS stormed off and basically said "yeah? Well... guess what. We're not gonna try to relicense. That oughta show you, Greg!!!"

The funny thing is they don't even have to care whether GregKH likes them. If they could, somehow, *somehow*, get over that hurdle and become GPL2 licensed, then GregKH becomes powerless against them. OpenZFS's second big problem, historically, has been the pain of fighting with the kernel's GPL symbol compatibility constraints. That problem would vanish and there's nothing GregKH could do, because it is the fundamental right of a GPL2 kernel module to use ANY GPL2 kernel symbols it wants. Even if OpenZFS was *never* merged into the mainline kernel, this one factor would make their lives so much easier.

But OpenZFS won't even *try*. They won't even try to collect agreements from continuing contributors to grant permission in advance for a future GPL2 relicensing. And so, the amount of CDDL code grows, and grows, and grows...
Back to top
View user's profile Send private message
lars_the_bear
Guru
Guru


Joined: 05 Jun 2024
Posts: 512

PostPosted: Fri Aug 16, 2024 9:19 am    Post subject: Reply with quote

eschwartz wrote:
[
So it boils down to, is Oracle the rights-holder for ZFS? Is Oracle a partial rights-holder but has to negotiate with other rights-holders? If so, who?


I agree entirely -- that's the question. There's little doubt that Oracle owns _some_ IP in ZFS. Trivially, they own rights in the name "ZFS". Undoubtedly they purchased some other IP rights from Sun, back in the day.

But what?

Most people with an interest in this subject tacitly assume that Sun once owned all the IP rights in ZFS, because it was developed by their employees. But even that isn't entirely clear-cut. That employers automatically own the work of their employees isn't unarguably true in any jurisdiction, or any line of business; but it's a particularly weak principle in some circumstances.

Subject to the same caveats, Oracle probably owns IP rights in whatever work was subsequently done on ZFS under contracts of employment. We (outside Oracle) don't know what that work was and, more importantly, we don't know whether it was influenced by contributions made under CDDL. If it was so influenced or, worse, Oracle has directly absorbed contributions made under CDDL, that complicates things for Oracle even further, by raising the possibility that what Oracle believes to be its IP is legally a derivative work of some kind.

So, even if Oracle had unambiguous rights to pre-CDDL ZFS, it seems plausible to me that, by this time, Oracle isn't going to be able to find out exactly what ZFS code is uninfluenced by CDDL contributions. This goes back twenty years, after all; I'm not sure anybody's record-keeping is that good.

If I were Oracle's legal adviser, I would want to be very, very careful that I had traced everybody who might conceivably have a claim on ZFS IP. I'd have to start by working out exactly what IP rights Sun had, and in what, when Oracle bought it. That might require an investigation of the employment contracts of Jeff Bonwick et al. Then I'd have to try to trace everybody who might have had a material influence on ZFS within Oracle who was not under contract to Oracle. Or accept that this will be impractical, and advise Oracle about what it owns unambiguously. Conceivably that won't be worth much any more.

I think my advice would be "leave well alone". Or, if I were canny, "Give me $100k and then leave well alone."

BR, Lars.
Back to top
View user's profile Send private message
zar Marco
Guru
Guru


Joined: 09 Sep 2016
Posts: 450
Location: Colle Umberto ( TV )

PostPosted: Wed Sep 04, 2024 1:47 pm    Post subject: Reply with quote

gienah wrote:
zfs seems to compile, boot and run with kernel 6.10.5 with the zfs-kmod-2.2.5.ebuild tweaked to build against 6.10:

Code:
/ # diff -ur /var/db/repos/gentoo/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild /var/db/repos/xportage/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild
--- /var/db/repos/gentoo/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild  2024-08-11 09:37:18.955494720 +1000
+++ /var/db/repos/xportage/sys-fs/zfs-kmod/zfs-kmod-2.2.5.ebuild        2024-08-15 12:30:45.122117317 +1000
@@ -9,7 +9,7 @@
 DESCRIPTION="Linux ZFS kernel module for sys-fs/zfs"
 HOMEPAGE="https://github.com/openzfs/zfs"

-MODULES_KERNEL_MAX=6.9
+MODULES_KERNEL_MAX=6.10
 MODULES_KERNEL_MIN=3.10

 if [[ ${PV} == 9999 ]] ; then
@@ -110,6 +110,10 @@
                # Set module revision number
                sed -Ei "s/(Release:.*)1/\1${PR}-gentoo/" META || die
        fi
+
+       sed -i META \
+               -e "s/\(Linux-Maximum:\) .*/\1 ${MODULES_KERNEL_MAX}/" \
+               || die
 }

 src_configure() {
/ #


Sorry, but I'm using gentoo with zfs with gentoo-kernel-bin, so I currently using kernel 6.8.10 because zfs-2.2.5 doesn't compatible with 6.10 family. I read your post, but I can't found xportage repo. Can you help me to find it?
Back to top
View user's profile Send private message
Nowa
Developer
Developer


Joined: 25 Jun 2014
Posts: 422
Location: Nijmegen

PostPosted: Thu Sep 05, 2024 9:44 am    Post subject: Reply with quote

There is no need to tweak any ebuilds, if you want to ignore the upper compatibility limit specified in the ebuild then disable the "dist-kernel-cap" USE flag.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
zar Marco
Guru
Guru


Joined: 09 Sep 2016
Posts: 450
Location: Colle Umberto ( TV )

PostPosted: Fri Sep 06, 2024 8:16 pm    Post subject: Reply with quote

Thanks so much. But if I disable this flag, after portage install all kernel version also if are incompatible with zfs, right?
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2293
Location: Adendorf, Germany

PostPosted: Mon Oct 28, 2024 10:52 am    Post subject: Reply with quote

"Oops, they did it again!"

zfs-kmod is still limited to max kernel 6.10, which is still available on kernel.org, although marked as EOL, but it has been removed from the portage tree already.
_________________
Edited 220,176 times by Yamakuzure
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22603

PostPosted: Mon Oct 28, 2024 2:04 pm    Post subject: Reply with quote

Why do you say "Oops" here? There was little activity in this thread from Gentoo developers, but from the posts they did make, none of them seem to me to even be hinting that they would change how they handle this, so I don't see how it is a mistake that they continued to follow their standard procedure. Upstream abandoned 6.10.x, so Gentoo removed gentoo-sources-6.10.x, exactly as has been done with every past stable release. I find this entirely unsurprising, and fully expect we will see a repeat when 6.11.x is abandoned upstream, and again for 6.12.x, and so on.

Also, as Nowa mentioned, the limit to 6.10 can be bypassed if you turn off the safety check - assuming zfs-kmod is actually compatible and just hasn't advertised that yet.
Back to top
View user's profile Send private message
Zucca
Moderator
Moderator


Joined: 14 Jun 2007
Posts: 3686
Location: Rasi, Finland

PostPosted: Tue Oct 29, 2024 9:33 am    Post subject: Reply with quote

I'd just use LTS kernels. Or do zfs-kmod devs specifically test it against only the newer kernel versions?
_________________
..: Zucca :..

My gentoo installs:
init=/sbin/openrc-init
-systemd -logind -elogind seatd

Quote:
I am NaN! I am a man!
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2293
Location: Adendorf, Germany

PostPosted: Tue Oct 29, 2024 10:00 am    Post subject: Reply with quote

Hu wrote:
Why do you say "Oops" here? There was little activity in this thread from Gentoo developers, but from the posts they did make, none of them seem to me to even be hinting that they would change how they handle this, so I don't see how it is a mistake that they continued to follow their standard procedure. Upstream abandoned 6.10.x, so Gentoo removed gentoo-sources-6.10.x, exactly as has been done with every past stable release. I find this entirely unsurprising, and fully expect we will see a repeat when 6.11.x is abandoned upstream, and again for 6.12.x, and so on.

Also, as Nowa mentioned, the limit to 6.10 can be bypassed if you turn off the safety check - assuming zfs-kmod is actually compatible and just hasn't advertised that yet.


"Why do you say "Oops" here?"
Because they did it with the last iteration, too. Same procedure. And there is no real use in removing the latest ebuild of the still available kernel version other than to dump multiple issues on users of packages that can not go for the next kernel iteration.
(... and I just felt like citing Britney ...)


"Upstream abandoned 6.10.x, so Gentoo removed gentoo-sources-6.10.x"
No. Upstream marked it as EOL, but has it still available for download from the main page at kernel.org marked as "stable". Big difference. And leaving the ebuild lying around for a few weeks does not hurt anyone or imposes any problem or maintenance need or anything. Unless, of course, a severe security issue is found that won't be patched. Then it should be removed, of course.

"the limit to 6.10 can be bypassed if you turn off the safety check"
There are defects with 6.11. So bypassing those tests may be not the best idea.
Also suggesting something like that as a work-around to prematurely removed ebuilds and missing updates from other upstreams is ... problematic.

That is like suggesting to ram a screwdriver into an engine because a missing part has not yet been delivered.

Anyway, I currently upgrade with
Code:
--exclude sys-kernel/gentoo-sources
and do not do any
Code:
--depclean
unless the next zfs release is ready.
_________________
Edited 220,176 times by Yamakuzure
Back to top
View user's profile Send private message
sMueggli
Guru
Guru


Joined: 03 Sep 2022
Posts: 489

PostPosted: Tue Oct 29, 2024 10:24 am    Post subject: Reply with quote

Yamakuzure wrote:
Hu wrote:
Why do you say "Oops" here? There was little activity in this thread from Gentoo developers, but from the posts they did make, none of them seem to me to even be hinting that they would change how they handle this, so I don't see how it is a mistake that they continued to follow their standard procedure. Upstream abandoned 6.10.x, so Gentoo removed gentoo-sources-6.10.x, exactly as has been done with every past stable release. I find this entirely unsurprising, and fully expect we will see a repeat when 6.11.x is abandoned upstream, and again for 6.12.x, and so on.

Also, as Nowa mentioned, the limit to 6.10 can be bypassed if you turn off the safety check - assuming zfs-kmod is actually compatible and just hasn't advertised that yet.


"Why do you say "Oops" here?"
Because they did it with the last iteration, too. Same procedure. And there is no real use in removing the latest ebuild of the still available kernel version other than to dump multiple issues on users of packages that can not go for the next kernel iteration.
(... and I just felt like citing Britney ...)


They will do it also in the future. Because the maintainers do the job of maintaining the repo. Maintainers are not archivers. If you want to use a specific kernel you can copy the ebuild into a local overlay.

Yamakuzure wrote:
"Upstream abandoned 6.10.x, so Gentoo removed gentoo-sources-6.10.x"
No. Upstream marked it as EOL, but has it still available for download from the main page at kernel.org marked as "stable". Big difference. And leaving the ebuild lying around for a few weeks does not hurt anyone or imposes any problem or maintenance need or anything. Unless, of course, a severe security issue is found that won't be patched. Then it should be removed, of course.


How does removing an ebuild from the repo make the world safer? The removal of a specific kernel version from the repo does not change the amount of running kernels with the same version.

Yamakuzure wrote:
"the limit to 6.10 can be bypassed if you turn off the safety check"
There are defects with 6.11. So bypassing those tests may be not the best idea.
Also suggesting something like that as a work-around to prematurely removed ebuilds and missing updates from other upstreams is ... problematic.

That is like suggesting to ram a screwdriver into an engine because a missing part has not yet been delivered.


What do you think is the role of the system administrator? If a system administrator is using ZFS on the system and installs unstable kernel versions, wouldn't you expect that the system administrator knows what he is doing?
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2293
Location: Adendorf, Germany

PostPosted: Tue Oct 29, 2024 11:15 am    Post subject: Reply with quote

Yes, of course, keeping a local copy would be an idea if there was any hint that the tree copy would be gone with the next update.

Not the point. Keeping the ebuild a while longer does not hurt anybody was the point. I just wanted to add that a timely removal is understandable if the version referenced had severe security issues.

Not the point. Suggesting to force a combination that is known to be dangerous is problematic was the point.

Anyway, I know it will stay like it is, and I wanted to post an update that it happened again. That's it.
If you feel like debating everything again, then go ahead.
_________________
Edited 220,176 times by Yamakuzure
Back to top
View user's profile Send private message
Nowa
Developer
Developer


Joined: 25 Jun 2014
Posts: 422
Location: Nijmegen

PostPosted: Tue Oct 29, 2024 11:19 am    Post subject: Reply with quote

Quote:
Keeping the ebuild a while longer does not hurt anybody was the point.


Not true, supporting more major kernel versions is more work regardless of whether upstream is still developing that version or not. Now if you're volunteering to join the dist-kernel project and do some of the work then we can discuss this, otherwise this discussion is pointless.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1946

PostPosted: Tue Oct 29, 2024 3:04 pm    Post subject: Reply with quote

Zucca wrote:
I'd just use LTS kernels. Or do zfs-kmod devs specifically test it against only the newer kernel versions?


As the ZFS maintainer in Gentoo, I strongly recommend people use LTS with ZFS anyway, as porting changes often take a while, even if it builds successfully against newer kernels (runtime issues often only get reported & fixed later). That's not ZFS's fault per se, it's just the nature out of an out-of-tree kernel module and the (lack of) guarantees the Linux kernel gives for its APIs. In fact, really, if you can, you should try use the non-latest LTS series at least for a bit until the latest LTS has been tested more.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20479

PostPosted: Thu Oct 31, 2024 12:02 am    Post subject: Reply with quote

Yamakuzure wrote:
Yes, of course, keeping a local copy would be an idea if there was any hint that the tree copy would be gone with the next update.
Leave it installed(?) and you have a copy of the ebuild in /var/db/pkg/sys-kernel/...

Also, when you first emerge a kernel and BEFORE doing anything with it, create a squashfs image of the /usr/src/linux-version directory. Now you have the ebuild and a clean copy of the installed sources.

Alternatively you could create a post sync script that checks if the ebuild has been removed and plays the song... :P
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2293
Location: Adendorf, Germany

PostPosted: Fri Nov 01, 2024 9:26 am    Post subject: Reply with quote

Nowa wrote:
Quote:
Keeping the ebuild a while longer does not hurt anybody was the point.


Not true, supporting more major kernel versions is more work regardless of whether upstream is still developing that version or not. Now if you're volunteering to join the dist-kernel project and do some of the work then we can discuss this, otherwise this discussion is pointless.


Which work exactly if the only work involved is removing the ebuild a few weeks later?
I am curious, what did I miss?
_________________
Edited 220,176 times by Yamakuzure
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2293
Location: Adendorf, Germany

PostPosted: Fri Nov 01, 2024 9:31 am    Post subject: Reply with quote

pjp wrote:
Yamakuzure wrote:
Yes, of course, keeping a local copy would be an idea if there was any hint that the tree copy would be gone with the next update.
Leave it installed(?)
That is what I am doing; the original issue was, that a --depclean removed it.

Which currently can not happen, because merging of the LTS version fails, so I am using --exclude sys-kernel/gentoo-sources on each call now.

Anyway, it is what it is.
_________________
Edited 220,176 times by Yamakuzure
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1946

PostPosted: Fri Nov 01, 2024 9:34 am    Post subject: Reply with quote

Yamakuzure wrote:
Nowa wrote:
Quote:
Keeping the ebuild a while longer does not hurt anybody was the point.


Not true, supporting more major kernel versions is more work regardless of whether upstream is still developing that version or not. Now if you're volunteering to join the dist-kernel project and do some of the work then we can discuss this, otherwise this discussion is pointless.


Which work exactly if the only work involved is removing the ebuild a few weeks later?
I am curious, what did I miss?


The version being in-tree implies it is supported, which means people may well be running it, which means we need to remember what issues it has. We also have issues where e.g. if we hold back until ZFS supports a newer non-LTS kernel and then we clean up, someone may then complain about some other out-of-tree module which isn't ready. It's also one more ebuild to update/test if changing any infrastructure.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2293
Location: Adendorf, Germany

PostPosted: Fri Nov 01, 2024 11:02 am    Post subject: Reply with quote

That makes sense, yes.
Thank you very much for the information.
_________________
Edited 220,176 times by Yamakuzure
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum