1:07 p.m.
On Wed, 2009-08-26 at 11:45 +0200, Hans de Goede wrote:
dracut using kernel come with a prebuild
initrd-generic-<version> instead
of initrd-<version>, so if we fail to find /boot/initrd-<version>.img, check
for /boot/initrd-generic-<version>.img instead. I've done things this way
so that if we ever need to generate system specific (so non generic) initrd's
for some reason the code will stay working.
Is the plan to basically migrate to entirely pre-built "generic"
"initrd" initramfs pre-built image files then? Will we even be
generating the kernel specific stuff in the future?
Jon.
1:11 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Wed, 2009-08-26 at 14:07 -0400, Jon Masters wrote:
On Wed, 2009-08-26 at 11:45 +0200, Hans de Goede wrote:
> dracut using kernel come with a prebuild initrd-generic-<version> instead
> of initrd-<version>, so if we fail to find /boot/initrd-<version>.img,
check
> for /boot/initrd-generic-<version>.img instead. I've done things this way
> so that if we ever need to generate system specific (so non generic) initrd's
> for some reason the code will stay working.
Is the plan to basically migrate to entirely pre-built "generic"
"initrd" initramfs pre-built image files then? Will we even be
generating the kernel specific stuff in the future?
Jon.
That was the plan, however we're finding more and more situations where
this introduces a lot more pain than it solves. For F12 at least it
seems quite too late to switch to using dracut images by default anyway.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:48 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Wednesday 26 August 2009 01:11:28 pm Jesse Keating wrote:
On Wed, 2009-08-26 at 14:07 -0400, Jon Masters wrote:
> On Wed, 2009-08-26 at 11:45 +0200, Hans de Goede wrote:
> > dracut using kernel come with a prebuild initrd-generic-<version>
> > instead of initrd-<version>, so if we fail to find
> > /boot/initrd-<version>.img, check for
> > /boot/initrd-generic-<version>.img instead. I've done things this
way
> > so that if we ever need to generate system specific (so non generic)
> > initrd's for some reason the code will stay working.
>
> Is the plan to basically migrate to entirely pre-built "generic"
> "initrd" initramfs pre-built image files then? Will we even be
> generating the kernel specific stuff in the future?
>
> Jon.
That was the plan, however we're finding more and more situations where
this introduces a lot more pain than it solves. For F12 at least it
seems quite too late to switch to using dracut images by default anyway.
some
arches need to create special initrds for some situations to work with
hardware limitations. there will likely always be a need to create initrds
Dennis
3:26 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hi,
On 08/26/2009 08:11 PM, Jesse Keating wrote:
On Wed, 2009-08-26 at 14:07 -0400, Jon Masters wrote:
> On Wed, 2009-08-26 at 11:45 +0200, Hans de Goede wrote:
>> dracut using kernel come with a prebuild initrd-generic-<version> instead
>> of initrd-<version>, so if we fail to find
/boot/initrd-<version>.img, check
>> for /boot/initrd-generic-<version>.img instead. I've done things this
way
>> so that if we ever need to generate system specific (so non generic)
initrd's
>> for some reason the code will stay working.
>
> Is the plan to basically migrate to entirely pre-built "generic"
> "initrd" initramfs pre-built image files then? Will we even be
> generating the kernel specific stuff in the future?
>
> Jon.
>
>
That was the plan, however we're finding more and more situations where
this introduces a lot more pain than it solves. For F12 at least it
seems quite too late to switch to using dracut images by default anyway.
As one of the persons involved in dracut and in integrating dracut into the
distribution I'm rather surprised to hear this.
Where has this been discussed ? Were are the bugs for the situations where
this does not work properly ?
Also as one of the mkinitrd maintainers I would like to know if we're sticking
with mkinitrd for Fedora 12, as there are some open issues which would be
really good to fix before the beta if we go this way.
Regards,
Hans
12:17 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Wed, 2009-09-02 at 10:26 +0200, Hans de Goede wrote:
As one of the persons involved in dracut and in integrating dracut
into the
distribution I'm rather surprised to hear this.
Where has this been discussed ? Were are the bugs for the situations where
this does not work properly ?
Also as one of the mkinitrd maintainers I would like to know if we're sticking
with mkinitrd for Fedora 12, as there are some open issues which would be
really good to fix before the beta if we go this way.
The fact that it wasn't turned on at Alpha means it really shouldn't be
on now, not without FESCo approval.
We've got some licensing concerns with a pre-generated binary blob of
bits from other packages being shipped with the kernel package, and the
kernel srpm doesn't have any sources to match those binary blobs.
Those are my biggest issues. I'd much prefer to see work continue on
dracut and have it available for F-12 users, but not default. We only
have one more major test point, the Beta, and there is very little time
after the beta to repair such a critical function as our initrd
generation, and no opportunity to test such repairs. It is simply too
late for F-12.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:22 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/02/2009 07:17 PM, Jesse Keating wrote:
On Wed, 2009-09-02 at 10:26 +0200, Hans de Goede wrote:
> As one of the persons involved in dracut and in integrating dracut into the
> distribution I'm rather surprised to hear this.
>
> Where has this been discussed ? Were are the bugs for the situations where
> this does not work properly ?
>
> Also as one of the mkinitrd maintainers I would like to know if we're sticking
> with mkinitrd for Fedora 12, as there are some open issues which would be
> really good to fix before the beta if we go this way.
>
The fact that it wasn't turned on at Alpha means it really shouldn't be
on now, not without FESCo approval.
That is interesting reasoning, first keep it out of Alpha even though it was
ready as you were afraid it would delay the Alpha further (although there were
no open bugs) and no now use that to also keep it out of Fedora 12 entirely.
We've got some licensing concerns with a pre-generated binary
blob of
bits from other packages being shipped with the kernel package, and the
kernel srpm doesn't have any sources to match those binary blobs.
We already do the same with the stage1 and stage2 images of anaconda. The
initrd is just a cpio archive, like the livecd images are just an iso, it is
all mere aggregation.
Those are my biggest issues. I'd much prefer to see work
continue on
dracut and have it available for F-12 users, but not default. We only
have one more major test point, the Beta, and there is very little time
after the beta to repair such a critical function as our initrd
generation, and no opportunity to test such repairs.
dracut already is the default in rawhide and there are very little bug
reports because of it. Not to mention that other Features such as:
https://fedoraproject.org/wiki/Anaconda/Features/FCoE
https://fedoraproject.org/wiki/Anaconda/Features/MDRaid
Depend up on it.
Regards,
Hans
8:36 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
> The fact that it wasn't turned on at Alpha means it really
shouldn't be
> on now, not without FESCo approval.
That is interesting reasoning, first keep it out of Alpha even though it was
ready as you were afraid it would delay the Alpha further (although there were
no open bugs) and no now use that to also keep it out of Fedora 12 entirely.
I agree - certainly, there has been nothing raised to FESCo yet to
disable it, and it was not removed from the feature list in any FESCo
discussion. That discussion can certainly be had if someone wants to raise
it to FESCo.
> We've got some licensing concerns with a pre-generated binary
blob of
> bits from other packages being shipped with the kernel package, and the
> kernel srpm doesn't have any sources to match those binary blobs.
>
We already do the same with the stage1 and stage2 images of anaconda. The
initrd is just a cpio archive, like the livecd images are just an iso, it is
all mere aggregation.
The issue is that stage1/stage2 are generated at *tree* build time, and
therefore are guaranteed to match the tree (and source RPMs) we ship.
As dracut images are currently built at *kernel* build time, that is
not the case. Moving to building initramfs at kernel install time would
solve this.
Bill
9:57 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hi,
On 09/03/2009 03:36 PM, Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
>> The fact that it wasn't turned on at Alpha means it really shouldn't be
>> on now, not without FESCo approval.
>
> That is interesting reasoning, first keep it out of Alpha even though it was
> ready as you were afraid it would delay the Alpha further (although there were
> no open bugs) and no now use that to also keep it out of Fedora 12 entirely.
I agree - certainly, there has been nothing raised to FESCo yet to
disable it, and it was not removed from the feature list in any FESCo
discussion. That discussion can certainly be had if someone wants to raise
it to FESCo.
>> We've got some licensing concerns with a pre-generated binary blob of
>> bits from other packages being shipped with the kernel package, and the
>> kernel srpm doesn't have any sources to match those binary blobs.
>>
>
> We already do the same with the stage1 and stage2 images of anaconda. The
> initrd is just a cpio archive, like the livecd images are just an iso, it is
> all mere aggregation.
The issue is that stage1/stage2 are generated at *tree* build time, and
therefore are guaranteed to match the tree (and source RPMs) we ship.
As dracut images are currently built at *kernel* build time, that is
not the case. Moving to building initramfs at kernel install time would
solve this.
Yes, but also loose one of the main advantage, that everyone with
kenrel-versionFoo is using the exact same initrd, if we build at install
time, and there is for example an mdraid issue, how do I know which exact version
of mdadm is in the initrd ?
I know this argument can be reversed, that if the exact version is not known, people
cannot excercise their rights under the GPL. So I suggest we add a list of package
NEVR's to the kernel rpm which contains the exact packages used to build the initrd,
yet still keep building it as part of the kernel rpm (so at build time), as this is
much easier for debugging issues.
It really is like having to support gentoo, versus having to support a distro using
pre build packages. And I would really like to move to the having to support a
pre-build package model for the initrd.
Regards,
Hans
10:05 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 10:57 AM, Hans de Goede wrote:
It really is like having to support gentoo, versus having to support
a
distro using pre build packages. And I would really like to move to the having to
support a pre-build package model for the initrd.
The problem is this:
The kernel binary RPM contains this pre-built initrd. The kernel source
RPM does not contain the sources necessary to make this pre-built initrd.
This makes me rather uncomfortable from a Licensing perspective. I'm
also concerned about it from a security perspective, as these binaries
are very likely to be overlooked when security updates are pushed.
~spot
10:35 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hi,
On 09/03/2009 05:05 PM, Tom "spot" Callaway wrote:
On 09/03/2009 10:57 AM, Hans de Goede wrote:
> It really is like having to support gentoo, versus having to support a
> distro using pre build packages. And I would really like to move to the having to
> support a pre-build package model for the initrd.
The problem is this:
The kernel binary RPM contains this pre-built initrd. The kernel source
RPM does not contain the sources necessary to make this pre-built initrd.
This makes me rather uncomfortable from a Licensing perspective.
True, but we do provide SRPMS with the sources, if we include a list of
the SRPMS with the sources, with full NEVR in the kernel rpm as doc,
wouldn't that be sufficient?
I'm
also concerned about it from a security perspective, as these binaries
are very likely to be overlooked when security updates are pushed.
We already have that issue with mkinitrd, and will have it when we move
to generating dracut initrd's in %post too. IOW the security issue will
always be there, so lets focus on the licensing issue please.
Regards,
Hans
11 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 11:35 AM, Hans de Goede wrote:
> The kernel binary RPM contains this pre-built initrd. The kernel
source
> RPM does not contain the sources necessary to make this pre-built initrd.
> This makes me rather uncomfortable from a Licensing perspective.
True, but we do provide SRPMS with the sources, if we include a list of
the SRPMS with the sources, with full NEVR in the kernel rpm as doc,
wouldn't that be sufficient?
Ehhhhhh. I'm still thinking about that. We don't generally permit other
packages to do that.
> I'm
> also concerned about it from a security perspective, as these binaries
> are very likely to be overlooked when security updates are pushed.
We already have that issue with mkinitrd, and will have it when we move
to generating dracut initrd's in %post too. IOW the security issue will
always be there, so lets focus on the licensing issue please.
Well, it is less of an issue with mkinitrd, because the user can easily
regenerate it. I do not think this is the same case with the "generic
initrd". Perhaps we could regenerate the generic initrd on the user's
system if any of the binary packages that are used to make it get an update?
~spot
1:20 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hi,
On 09/03/2009 06:00 PM, Tom "spot" Callaway wrote:
On 09/03/2009 11:35 AM, Hans de Goede wrote:
>> The kernel binary RPM contains this pre-built initrd. The kernel source
>> RPM does not contain the sources necessary to make this pre-built initrd.
>> This makes me rather uncomfortable from a Licensing perspective.
>
> True, but we do provide SRPMS with the sources, if we include a list of
> the SRPMS with the sources, with full NEVR in the kernel rpm as doc,
> wouldn't that be sufficient?
Ehhhhhh. I'm still thinking about that. We don't generally permit other
packages to do that.
Ok let me know which way it is going to be. I'm personally a fan of generating
the initrd on the buildsys, as that way I can get the exact same initrd as
a bug reporter easily. But if you say it has to be generated in %post, I'll start
making the necessary adjustments to new-kernel-pkg and kernel.spec
>> I'm
>> also concerned about it from a security perspective, as these binaries
>> are very likely to be overlooked when security updates are pushed.
>
> We already have that issue with mkinitrd, and will have it when we move
> to generating dracut initrd's in %post too. IOW the security issue will
> always be there, so lets focus on the licensing issue please.
Well, it is less of an issue with mkinitrd, because the user can easily
regenerate it. I do not think this is the same case with the "generic
initrd". Perhaps we could regenerate the generic initrd on the user's
system if any of the binary packages that are used to make it get an update?
Regeneration is as easy with dracut as it is with mkinitrd, actually they
have the same cmdline syntax.
The only extra step required with dracut when using pre-generated images is:
yum install dracut
Regards,
Hans
2:10 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 02:20 PM, Hans de Goede wrote:
Regeneration is as easy with dracut as it is with mkinitrd, actually
they
have the same cmdline syntax.
The only extra step required with dracut when using pre-generated images
is:
yum install dracut
Okay, so is there any reason why we don't have some sort of scriplet
that regenerates the initrd when any of the system binaries used in the
initrd are updated?
~spot
2:06 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 09:10 PM, Tom "spot" Callaway wrote:
On 09/03/2009 02:20 PM, Hans de Goede wrote:
> Regeneration is as easy with dracut as it is with mkinitrd, actually they
> have the same cmdline syntax.
>
> The only extra step required with dracut when using pre-generated images
> is:
> yum install dracut
Okay, so is there any reason why we don't have some sort of scriplet
that regenerates the initrd when any of the system binaries used in the
initrd are updated?
Because people really dislike non booting systems. Automatically regenerating
a very crucial part of the boot sequence is a very bad idea, as it will break
occasionally. There is a reason why we keep a backup kernel at hand at all times
and that reason is not only that sometimes a new kernel fails to work on certain
systems, but also that sometimes a new initrd fails (for example due to changes in
things it depends on).
Also for there to be a security issue, there needs to be an attack vector, and
during early userspace, there is very little attack vector, no other programs
are running, no network interfaces are up, etc.
Regards,
Hans
8:40 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/04/2009 03:06 AM, Hans de Goede wrote:
Also for there to be a security issue, there needs to be an attack
vector, and during early userspace, there is very little attack vector, no other
programs are running, no network interfaces are up, etc.
I suppose this would be somewhat difficult to exploit, except possibly
at the keyboard. :)
~spot
11:29 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
>> It really is like having to support gentoo, versus having to
support a
>> distro using pre build packages. And I would really like to move to the having
to
>> support a pre-build package model for the initrd.
>
> The problem is this:
>
> The kernel binary RPM contains this pre-built initrd. The kernel source
> RPM does not contain the sources necessary to make this pre-built initrd.
> This makes me rather uncomfortable from a Licensing perspective.
True, but we do provide SRPMS with the sources, if we include a list of
the SRPMS with the sources, with full NEVR in the kernel rpm as doc,
wouldn't that be sufficient?
Not really. In the case of initrd-built-with-kernel, it could be packages
in the buildroot that never leave koji for release/updates, and are then
garbage collected.
Bill
1:25 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hi,
On 09/03/2009 06:29 PM, Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
>>> It really is like having to support gentoo, versus having to support a
>>> distro using pre build packages. And I would really like to move to the
having to
>>> support a pre-build package model for the initrd.
>>
>> The problem is this:
>>
>> The kernel binary RPM contains this pre-built initrd. The kernel source
>> RPM does not contain the sources necessary to make this pre-built initrd.
>> This makes me rather uncomfortable from a Licensing perspective.
>
> True, but we do provide SRPMS with the sources, if we include a list of
> the SRPMS with the sources, with full NEVR in the kernel rpm as doc,
> wouldn't that be sufficient?
Not really. In the case of initrd-built-with-kernel, it could be packages
in the buildroot that never leave koji for release/updates, and are then
garbage collected.
Only if one and the same package gets rebuild twice in a day, and between
those rebuilds a kernel get build. Or a package from updates-testing gets
tagged into the buildroot override and then never becomes stable.
Note that we have the same problem with any package which does static linking
against an lgpl library (such as glibc). Actually if the kernel rpm contains
nevr's of the packages used, a package which does static linking against an
lgpl library will be a bigger problem as there we are not telling the user
which exact version to get to get the library sources used.
And if we have the NEVR as used during build, we can always regenerate the
srpm from CVS + the lookaside cache.
Regards,
Hans
2:22 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 02:25 PM, Hans de Goede wrote:
Note that we have the same problem with any package which does
static
linking against an lgpl library (such as glibc).
This is (one of the big reasons) why we only permit static linking with
explicit approval from FESCo.
I'm really very uncomfortable with the generic initrd not including
matching sources in the corresponding SRPM (whether that is kernel or
some dedicated "generic-dracut" package is immaterial). The answer of
"the sources are in the Fedora lookaside cache, somewhere, go track it
down yourself" isn't really sufficient for me.
Unfortunately, I can't think of a good way to package up a generic
initrd in a way that we can provide source properly. I'm open to
suggestions though.
~spot
3:50 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 03:22 PM, Tom "spot" Callaway wrote:
On 09/03/2009 02:25 PM, Hans de Goede wrote:
> Note that we have the same problem with any package which does static
> linking against an lgpl library (such as glibc).
This is (one of the big reasons) why we only permit static linking with
explicit approval from FESCo.
I'm really very uncomfortable with the generic initrd not including
matching sources in the corresponding SRPM (whether that is kernel or
some dedicated "generic-dracut" package is immaterial). The answer of
"the sources are in the Fedora lookaside cache, somewhere, go track it
down yourself" isn't really sufficient for me.
Unfortunately, I can't think of a good way to package up a generic
initrd in a way that we can provide source properly. I'm open to
suggestions though.
~spot
The problem is how we associate objects in rpmbuild/koji. You can look at RPM building as
transitioning between 3 types of objects:
1) We begin with a pile of SOURCES for a package.
2) We compile those sources into a collection of ARTIFACTS
3) We cpio, compress, and tag those artifacts into one or more PACKAGES (typically one.
More if we have sub-packages).
The problem here is that the ARTIFACTS phase isn't really represented. We relate
packages to sources and that's that. If we tracked the results of the build process
independently of the RPM itself, we could track much more complicated relationships
between packages (for example, the kernel borrowing bits of the output from the last glibc
build to make its initrd).
I believe there are package managers that do this. RPM isn't well suited to it though.
It would take a lot of muscle.
--CJD
3:59 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
If we tracked the results of the build process independently of the
RPM
itself, we could track much more complicated relationships between
packages (for example, the kernel borrowing bits of the output from the
last glibc build to make its initrd).
Koji's database has that information, sort of. It can tell you exactly
which other packages were installed in the buildroot, so that is the
superset of what-all bits could have been rolled into the output.
4:08 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 04:59 PM, Roland McGrath wrote:
Koji's database has that information, sort of. It can tell you
exactly
which other packages were installed in the buildroot, so that is the
superset of what-all bits could have been rolled into the output.
Yes, but I do not think we are in good faith satisfying the requirement
to distribute the source for those binaries by pointing back to koji
pages and possibly forcing the user to dig into the lookaside cache.
~spot
4:39 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 05:08 PM, Tom "spot" Callaway wrote:
On 09/03/2009 04:59 PM, Roland McGrath wrote:
> Koji's database has that information, sort of. It can tell you exactly
> which other packages were installed in the buildroot, so that is the
> superset of what-all bits could have been rolled into the output.
Yes, but I do not think we are in good faith satisfying the requirement
to distribute the source for those binaries by pointing back to koji
pages and possibly forcing the user to dig into the lookaside cache.
~spot
Isn't it more that we know how to do it? If someone came to the mailing
list and said "I formally demand, as per GPLvX, that you give me the
source for $Foo" we can quickly comply. We don't want to handle a large
number of requests in that way, but we can do it for the auditors.
--CJD
4:46 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
> Yes, but I do not think we are in good faith satisfying the
requirement
> to distribute the source for those binaries by pointing back to koji
> pages and possibly forcing the user to dig into the lookaside cache.
The requirement is to provide a written offer to give someone the source
when they ask.
Isn't it more that we know how to do it? If someone came to the
mailing
list and said "I formally demand, as per GPLvX, that you give me the
source for $Foo" we can quickly comply. We don't want to handle a large
number of requests in that way, but we can do it for the auditors.
Right. We could possibly attempt to automate something to generate an
easy-to-download list of "possibly-related sources". That could even be
self-service with a web thingy you can just hand a Fedora rpm N-V-R. But
at any rate, we can automate it enough to make sure that we are not put out
by manual work involved in complying with legitimate requests to produce
the sources.
Thanks,
Roland
4:51 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 05:46 PM, Roland McGrath wrote:
The requirement is to provide a written offer to give someone the
source
when they ask.
Well, that's true for GPL. Can someone generate a list of the binaries
used in the generic initrd and the packages that they came from?
~spot
5:14 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Thu, 2009-09-03 at 14:46 -0700, Roland McGrath wrote:
> > Yes, but I do not think we are in good faith satisfying the
requirement
> > to distribute the source for those binaries by pointing back to koji
> > pages and possibly forcing the user to dig into the lookaside cache.
The requirement is to provide a written offer to give someone the source
when they ask.
We don't distribute under that clause of the GPL, because the 3 year
timeline on it is entirely too vague and we don't want to fall into that
trap. We distribute under the clause that says if we offer binaries, we
have to offer source with them. This gives us the ability to remove
binary and source packages at will, because when we stop offering the
binary, we can stop offering the source. This is why the kernel rpm
having binaries with no matching source in the kernel srpm is a problem
for us.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:25 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 06:14 PM, Jesse Keating wrote:
We don't distribute under that clause of the GPL, because the 3
year
timeline on it is entirely too vague and we don't want to fall into that
trap.
Ugh. I had conveniently forgotten about that, thanks for the reminder.
~spot
2:10 a.m.
New subject: static linking and LGPL libraries
On 09/03/2009 09:22 PM, Tom "spot" Callaway wrote:
On 09/03/2009 02:25 PM, Hans de Goede wrote:
> Note that we have the same problem with any package which does static
> linking against an lgpl library (such as glibc).
This is (one of the big reasons) why we only permit static linking with
explicit approval from FESCo.
Still we do allow it for certain packages and every such package has the
potential LGPL problem Notting described. I personally think it would
be a good idea to include root.log inside the srpm of packages, this
way people can truely use their GPL rights and exactly re-create the
package by using all the same packages in a chroot as used during the
original build.
Regards,
Hans
8:23 a.m.
New subject: static linking and LGPL libraries
On 09/04/2009 03:10 AM, Hans de Goede wrote:
On 09/03/2009 09:22 PM, Tom "spot" Callaway wrote:
> On 09/03/2009 02:25 PM, Hans de Goede wrote:
>> Note that we have the same problem with any package which does static
>> linking against an lgpl library (such as glibc).
>
> This is (one of the big reasons) why we only permit static linking with
> explicit approval from FESCo.
>
Still we do allow it for certain packages and every such package has the
potential LGPL problem Notting described. I personally think it would
be a good idea to include root.log inside the srpm of packages, this
way people can truely use their GPL rights and exactly re-create the
package by using all the same packages in a chroot as used during the
original build.
We don't keep every Koji build indefinitely. We need to garbage-collect
older builds or our storage requirements would grow without bound.
Rebuilding a package using *exactly* the same NVRs present in the
buildroot is not practical, and after a few weeks, generally not possible.
10:10 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/03/2009 12:29 PM, Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
>>> It really is like having to support gentoo, versus having to support a
>>> distro using pre build packages. And I would really like to move to the
having to
>>> support a pre-build package model for the initrd.
>>
>> The problem is this:
>>
>> The kernel binary RPM contains this pre-built initrd. The kernel source
>> RPM does not contain the sources necessary to make this pre-built initrd.
>> This makes me rather uncomfortable from a Licensing perspective.
>
> True, but we do provide SRPMS with the sources, if we include a list of
> the SRPMS with the sources, with full NEVR in the kernel rpm as doc,
> wouldn't that be sufficient?
Not really. In the case of initrd-built-with-kernel, it could be packages
in the buildroot that never leave koji for release/updates, and are then
garbage collected.
There's a related problem here - glibc32 .
--
Peter
I was born not knowing and have had only a little time to
change that here and there.
-- Feynman
11:47 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/08/2009 12:04 PM, Tom "spot" Callaway wrote:
On 09/08/2009 11:10 AM, Peter Jones wrote:
> There's a related problem here - glibc32 .
I don't think we distribute glibc32.
Hrm. Yeah, probably jumped the gun there. Just want to make
sure we keep it in mind.
--
Peter
I hope you know that this will go down on your permanent record.
11:59 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Tue, 2009-09-08 at 12:47 -0400, Peter Jones wrote:
On 09/08/2009 12:04 PM, Tom "spot" Callaway wrote:
> On 09/08/2009 11:10 AM, Peter Jones wrote:
>> There's a related problem here - glibc32 .
>
> I don't think we distribute glibc32.
Hrm. Yeah, probably jumped the gun there. Just want to make
sure we keep it in mind.
--
Peter
I hope you know that this will go down on your permanent record.
The related problem is that we need to make sure that glibc32/64 stays
current with the real glibc counterparts, so that what we build against
is shipped in the real glibc srpms.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:37 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Thu, Sep 3, 2009 at 5:05 PM, Tom "spot" Callaway<tcallawa(a)redhat.com>
wrote:
On 09/03/2009 10:57 AM, Hans de Goede wrote:
> It really is like having to support gentoo, versus having to support a
> distro using pre build packages. And I would really like to move to the having to
> support a pre-build package model for the initrd.
The problem is this:
The kernel binary RPM contains this pre-built initrd. The kernel source
RPM does not contain the sources necessary to make this pre-built initrd.
As long as we (fedora) ship the source code this shouldn't be an
issue, or am I missing something?
12:33 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Thu, 2009-09-03 at 18:37 +0200, drago01 wrote:
As long as we (fedora) ship the source code this shouldn't be an
issue, or am I missing something?
See the other messages. We have no facility to ensure that the binaries
used in generation of the initrd during kernel build have matching srpms
always available during the time that the kernel binary is available.
We have no facility to even guarantee that the binaries used to generate
the initrd at build time will ever be actually shipped, if say kernel
was built at 0800, then say plymouth was built at 1600, and rawhide
composed at 2000 you'd never actually publish the plymouth binary that
went into the initrd, let alone the srpm to match it.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:53 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Thu, 2009-09-03 at 11:05 -0400, Tom "spot" Callaway wrote:
On 09/03/2009 10:57 AM, Hans de Goede wrote:
> It really is like having to support gentoo, versus having to support a
> distro using pre build packages. And I would really like to move to the having to
> support a pre-build package model for the initrd.
...but not for drivers ;) It's funny how sometimes building binaries
makes life easier for users, but other times it's horribly wrong :)
The problem is this:
The kernel binary RPM contains this pre-built initrd. The kernel source
RPM does not contain the sources necessary to make this pre-built initrd.
This makes me rather uncomfortable from a Licensing perspective. I'm
also concerned about it from a security perspective, as these binaries
are very likely to be overlooked when security updates are pushed.
The problem I have is that some folks want to include additional drivers
into their initrd. What are we going to recommend for this case? I know
one can still build a kernel-specific version, but I fear that this
results in many users having no benefit of the generic image because
it'll not contain the additional bits they needed to add.
Can't we at least ensure all deps are available on the system by
default, so that users *can* rebuild?
Jon.
10:27 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Fri, Sep 04, 2009 at 11:14:43AM -0400, Dave Jones wrote:
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote:
> The problem I have is that some folks want to include additional drivers
> into their initrd.
examples please.
Out-of-tree modules: pvscsi, vmxnet (for VMWare). Generally
stuff frowned-upon. BTW, I believe changing Plymouth theme require
regeneration of initrd.
--
Tomasz Torcz Only gods can safely risk perfection,
xmpp: zdzichubg(a)chrome.pl it's a dangerous thing for a man. -- Alia
11:19 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Fri, 2009-09-04 at 17:27 +0200, Tomasz Torcz wrote:
On Fri, Sep 04, 2009 at 11:14:43AM -0400, Dave Jones wrote:
> On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote:
>
> > The problem I have is that some folks want to include additional drivers
> > into their initrd.
>
> examples please.
Out-of-tree modules: pvscsi, vmxnet (for VMWare). Generally
stuff frowned-upon. BTW, I believe changing Plymouth theme require
regeneration of initrd.
Yeah. Most of it is "evil" stuff. But I am bringing it up because nobody
else has - the fact of the matter is that there are lots of third party
drivers and tools that are going to break if they cannot regenerate the
initrd. I think it's acceptable for Fedora to completely loathe and
distrust binary drivers, but I really don't think it's acceptable to
actively prevent someone from using them if they would like to.
What'll happen is that lots of people will start building per-kernel
initrd images again, and third party websites will talk about how to
"work around" dracut defaults rather than embracing them because they
won't have an option for a generated, portable image.
Jon.
1:51 p.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Fri, 2009-09-04 at 17:27 +0200, Tomasz Torcz wrote:
On Fri, Sep 04, 2009 at 11:14:43AM -0400, Dave Jones wrote:
> On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote:
>
> > The problem I have is that some folks want to include additional drivers
> > into their initrd.
>
> examples please.
Out-of-tree modules: pvscsi, vmxnet (for VMWare). Generally
stuff frowned-upon. BTW, I believe changing Plymouth theme require
regeneration of initrd.
Plymouth has just been changed to create its own initrd, I believe.
11:51 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote:
The problem I have is that some folks want to include additional
drivers
into their initrd. What are we going to recommend for this case? I know
one can still build a kernel-specific version, but I fear that this
results in many users having no benefit of the generic image because
it'll not contain the additional bits they needed to add.
Isn't the point of the new infrastructure that we can provide multiple
initramfs modules that will all end up in the filesystem on boot? Users
who want to add drivers could do it even more easily than they currently
can.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:45 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On 09/04/2009 12:51 PM, Matthew Garrett wrote:
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote:
> The problem I have is that some folks want to include additional drivers
> into their initrd. What are we going to recommend for this case? I know
> one can still build a kernel-specific version, but I fear that this
> results in many users having no benefit of the generic image because
> it'll not contain the additional bits they needed to add.
Isn't the point of the new infrastructure that we can provide multiple
initramfs modules that will all end up in the filesystem on boot? Users
who want to add drivers could do it even more easily than they currently
can.
I am skeptical that we are ready for this. Not all non-x86 boot loaders
are capable of handling multiple initrd's, and various types of netboot
wont do it either. This is a very late time to rely upon such a new
feature for something this important.
Warren
11:56 a.m.
New subject: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
On Tue, Sep 08, 2009 at 12:45:43PM -0400, Warren Togami wrote:
On 09/04/2009 12:51 PM, Matthew Garrett wrote:
> Isn't the point of the new infrastructure that we can provide multiple
> initramfs modules that will all end up in the filesystem on boot? Users
> who want to add drivers could do it even more easily than they currently
> can.
>
I am skeptical that we are ready for this. Not all non-x86 boot loaders
are capable of handling multiple initrd's, and various types of netboot
wont do it either. This is a very late time to rely upon such a new
feature for something this important.
cpio archives can be concatenated, right? It seems like a
straightforward workaround.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
5337
days inactive
5350
days old
41 comments
17 participants
participants (17)
-
Bill Nottingham -
Casey Dahlin -
Dave Jones -
Dennis Gilmore -
drago01 -
Hans de Goede -
Jesse Keating -
Jon Masters -
Jon Masters -
Matthew Garrett -
Matthias Clasen -
Mike Bonnet -
Peter Jones -
Roland McGrath -
Tom Callaway -
Tomasz Torcz -
Warren Togami