8:45 a.m.
= Features/DracutHostOnly =
https://fedoraproject.org/wiki/Features/DracutHostOnly
Feature owner(s): Harald Hoyer <harald(a)redhat.com>
Only create "host-only" initramfs images. A generic fallback image should be
installed by anaconda on installation/update and never ever be removed.
== Detailed description ==
Current initramfs images contain most of the kernel drivers to boot from any
hardware. This results in a very big initramfs, which takes a long time to
load on system start and a long time to create on kernel updates. Switching to
host-only will improve the situation. To cope with hardware change, a boot
entry "Rescue System" should be installed with a full fledged initramfs also
containing debug tools. This boot entry can then be used to recover from
hardware changes and also from unforseen software failure after updates.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 a.m.
On 01/29/2013 02:45 PM, Jaroslav Reznik wrote:
= Features/DracutHostOnly =
https://fedoraproject.org/wiki/Features/DracutHostOnly
Feature owner(s): Harald Hoyer <harald(a)redhat.com>
Only create "host-only" initramfs images. A generic fallback image should be
installed by anaconda on installation/update and never ever be removed.
== Detailed description ==
Current initramfs images contain most of the kernel drivers to boot from any
hardware. This results in a very big initramfs, which takes a long time to
load on system start and a long time to create on kernel updates. Switching to
host-only will improve the situation. To cope with hardware change, a boot
entry "Rescue System" should be installed with a full fledged initramfs also
containing debug tools. This boot entry can then be used to recover from
hardware changes and also from unforseen software failure after updates.
About time ;)
JBG
9:42 a.m.
On Tue, Jan 29, 2013 at 02:45:34PM +0000, Jaroslav Reznik wrote:
Only create "host-only" initramfs images. A generic
fallback image should be
installed by anaconda on installation/update and never ever be removed.
Will there be a way to opt out of this? The fallback image will consume
space and not be useful in situations where one doesn't have the access to
boot into it. (Eg., EC2.)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:42 a.m.
On Tue, Jan 29, 2013 at 10:42:29AM -0500, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 02:45:34PM +0000, Jaroslav Reznik wrote:
> Only create "host-only" initramfs images. A generic fallback image should
be
> installed by anaconda on installation/update and never ever be removed.
Will there be a way to opt out of this? The fallback image will consume
space and not be useful in situations where one doesn't have the access to
boot into it. (Eg., EC2.)
Clarification: opt out of the generic fallback image. Not the rest. :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:53 a.m.
Le Mar 29 janvier 2013 16:42, Matthew Miller a écrit :
On Tue, Jan 29, 2013 at 10:42:29AM -0500, Matthew Miller wrote:
> On Tue, Jan 29, 2013 at 02:45:34PM +0000, Jaroslav Reznik wrote:
> > Only create "host-only" initramfs images. A generic fallback image
> should be
> > installed by anaconda on installation/update and never ever be
> removed.
> Will there be a way to opt out of this? The fallback image will consume
> space and not be useful in situations where one doesn't have the access
> to
> boot into it. (Eg., EC2.)
Clarification: opt out of the generic fallback image. Not the rest. :)
Also, fallback has interesting security properties…
--
Nicolas Mailhot
10:09 a.m.
On Tue, Jan 29, 2013 at 4:53 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
Le Mar 29 janvier 2013 16:42, Matthew Miller a écrit :
> On Tue, Jan 29, 2013 at 10:42:29AM -0500, Matthew Miller wrote:
>> On Tue, Jan 29, 2013 at 02:45:34PM +0000, Jaroslav Reznik wrote:
>> > Only create "host-only" initramfs images. A generic fallback
image
>> should be
>> > installed by anaconda on installation/update and never ever be
>> removed.
>> Will there be a way to opt out of this? The fallback image will consume
>> space and not be useful in situations where one doesn't have the access
>> to
>> boot into it. (Eg., EC2.)
>
> Clarification: opt out of the generic fallback image. Not the rest. :)
Also, fallback has interesting security properties…
Not sure what you mean ... care to elaborate?
10:40 a.m.
Le Mar 29 janvier 2013 17:09, drago01 a écrit :
On Tue, Jan 29, 2013 at 4:53 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
>
> Le Mar 29 janvier 2013 16:42, Matthew Miller a écrit :
>> On Tue, Jan 29, 2013 at 10:42:29AM -0500, Matthew Miller wrote:
>>> On Tue, Jan 29, 2013 at 02:45:34PM +0000, Jaroslav Reznik wrote:
>>> > Only create "host-only" initramfs images. A generic fallback
image
>>> should be
>>> > installed by anaconda on installation/update and never ever be
>>> removed.
>>> Will there be a way to opt out of this? The fallback image will
>>> consume
>>> space and not be useful in situations where one doesn't have the
>>> access
>>> to
>>> boot into it. (Eg., EC2.)
>>
>> Clarification: opt out of the generic fallback image. Not the rest. :)
>
> Also, fallback has interesting security properties…
Not sure what you mean ... care to elaborate?
Current rescue disc allow bypass of pretty much all the security controls
on installed systems. (that's why some entities disable optical drive in
bios and glue usb ports). Will fallback perform the security checks of
the main boot path? When I see 'never ever be removed' does that mean this
will make sure any Fedora box will have a boot entry to an old kernel,
with known security bugs, that you only need to trick boot into to get a
vulnerable system?
--
Nicolas Mailhot
10:44 a.m.
On Tue, Jan 29, 2013 at 05:40:04PM +0100, Nicolas Mailhot wrote:
bios and glue usb ports). Will fallback perform the security checks
of
the main boot path? When I see 'never ever be removed' does that mean this
will make sure any Fedora box will have a boot entry to an old kernel,
with known security bugs, that you only need to trick boot into to get a
vulnerable system?
Presumably the image is local-only, at least by default. That's not any
worse than letting one provide the kernel with arbitrary parameters at boot
time, which we do already by default. (I'm not sure if the new installer
even has an option for password-protecting grub2, offhand.)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:48 p.m.
On Jan 29, 2013, at 9:44 AM, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
(I'm not sure if the new installer
even has an option for password-protecting grub2, offhand.)
It doesn't. And this seems to be an area of confusion on the two grub lists for users
and distro developers alike, looking to implement it. So I'm not certain that it's
strictly an installer limitation.
Chris Murphy
12:56 p.m.
Am 29.01.2013 19:48, schrieb Chris Murphy:
On Jan 29, 2013, at 9:44 AM, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
> (I'm not sure if the new installer
> even has an option for password-protecting grub2, offhand.)
It doesn't. And this seems to be an area of confusion on the two grub lists for users
and distro developers alike, looking to implement it. So I'm not certain that it's
strictly an installer limitation.
grub2 in fedora is simply broken in this case
https://bugzilla.redhat.com/show_bug.cgi?id=882721
1:30 p.m.
On Jan 29, 2013, at 11:56 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
grub2 in fedora is simply broken in this case
https://bugzilla.redhat.com/show_bug.cgi?id=882721
So you've built grub2 from recent gnu.org source (Bazaar), and password protection
works? Just the Fedora version is broken?
Chris Murphy
1:34 p.m.
Am 29.01.2013 20:30, schrieb Chris Murphy:
On Jan 29, 2013, at 11:56 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
> grub2 in fedora is simply broken in this case
> https://bugzilla.redhat.com/show_bug.cgi?id=882721
So you've built grub2 from recent gnu.org source (Bazaar), and password protection
works? Just the Fedora version is broken?
no, but i did not decide switch to grub2 with it
wobbly configuration with a shell-language at all
1:47 p.m.
On Jan 29, 2013, at 12:34 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 29.01.2013 20:30, schrieb Chris Murphy:
>
> On Jan 29, 2013, at 11:56 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>>
>> grub2 in fedora is simply broken in this case
>> https://bugzilla.redhat.com/show_bug.cgi?id=882721
>
> So you've built grub2 from recent gnu.org source (Bazaar), and password
protection works? Just the Fedora version is broken?
no, but i did not decide switch to grub2 with it
wobbly configuration with a shell-language at all
If it's fundamentally broken upstream, then it's not really a Fedora bug.
Chris Murphy
2:47 p.m.
Am 29.01.2013 20:47, schrieb Chris Murphy:
On Jan 29, 2013, at 12:34 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
>
> Am 29.01.2013 20:30, schrieb Chris Murphy:
>>
>> On Jan 29, 2013, at 11:56 AM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
>>>
>>> grub2 in fedora is simply broken in this case
>>> https://bugzilla.redhat.com/show_bug.cgi?id=882721
>>
>> So you've built grub2 from recent gnu.org source (Bazaar), and password
protection works? Just the Fedora version is broken?
>
> no, but i did not decide switch to grub2 with it
> wobbly configuration with a shell-language at all
If it's fundamentally broken upstream, then it's not really a Fedora bug.
it did work in F16
sometimes later the config-file where i have defined
grub-pwd again after a lot of search was silently
renamed to rpmsave and the password DISABLED without
notice the user that his security is broken
so this is a regression and it does not bother
me who has made it - it was introduced after
it had worked
1:02 p.m.
On Tue, 29 Jan 2013 11:48:01 -0700
Chris Murphy <lists(a)colorremedies.com> wrote:
On Jan 29, 2013, at 9:44 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> (I'm not sure if the new installer
> even has an option for password-protecting grub2, offhand.)
It doesn't. And this seems to be an area of confusion on the two grub
lists for users and distro developers alike, looking to implement it.
So I'm not certain that it's strictly an installer limitation.
Chris Murphy
Not sure about the installer, but the one in kickstart is broken (and
has been broken since GRUB2):
https://bugzilla.redhat.com/show_bug.cgi?id=840160
It should be fixable though I've not yet found the time to dig into it.
I only ran into this last week since I (apparently) skipped F17 / GRUB2.
--Stijn
12:25 p.m.
On Tue, Jan 29, 2013 at 5:40 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
Le Mar 29 janvier 2013 17:09, drago01 a écrit :
> On Tue, Jan 29, 2013 at 4:53 PM, Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net> wrote:
>>
>> Le Mar 29 janvier 2013 16:42, Matthew Miller a écrit :
>>> On Tue, Jan 29, 2013 at 10:42:29AM -0500, Matthew Miller wrote:
>>>> On Tue, Jan 29, 2013 at 02:45:34PM +0000, Jaroslav Reznik wrote:
>>>> > Only create "host-only" initramfs images. A generic
fallback image
>>>> should be
>>>> > installed by anaconda on installation/update and never ever be
>>>> removed.
>>>> Will there be a way to opt out of this? The fallback image will
>>>> consume
>>>> space and not be useful in situations where one doesn't have the
>>>> access
>>>> to
>>>> boot into it. (Eg., EC2.)
>>>
>>> Clarification: opt out of the generic fallback image. Not the rest. :)
>>
>> Also, fallback has interesting security properties…
>
> Not sure what you mean ... care to elaborate?
Current rescue disc allow bypass of pretty much all the security controls
on installed systems. (that's why some entities disable optical drive in
bios and glue usb ports). Will fallback perform the security checks of
the main boot path? When I see 'never ever be removed' does that mean this
will make sure any Fedora box will have a boot entry to an old kernel,
with known security bugs, that you only need to trick boot into to get a
vulnerable system?
Why should this be the case?
The initrd is generated on kernel install .... just generate one as
"fallback" image and one host only for the main boot target.
12:33 p.m.
drago01 wrote:
Why should this be the case?
The initrd is generated on kernel install .... just generate one as
"fallback" image and one host only for the main boot target.
+1
Grub2 is already smart enough to handle an additional boot line for a
"recovery mode". Then we can have our cake and eat it, too.
10:20 a.m.
>> A generic fallback image should be
>> installed by anaconda on installation/update and never ever be
>> removed.
Also, fallback has interesting security properties…
"Rescue mode" forces a SELinux relabel at the next boot, and relabel
can take a very long time.
How does "fallback mode" handle this, particularly if there have been
updates to SELinux policy after the fallback was created?
--
12:28 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/29/2013 11:20 AM, John Reiser wrote:
>>> A generic fallback image should be installed by anaconda
on
>>> installation/update and never ever be removed.
> Also, fallback has interesting security properties…
"Rescue mode" forces a SELinux relabel at the next boot, and relabel can
take a very long time.
How does "fallback mode" handle this, particularly if there have been
updates to SELinux policy after the fallback was created?
The reason for this is we do not know what files were created on the system
while SELinux was disabled (Policy Not Loaded). If you know you did not
created files on the system you could remove the /.autorelabel file and boot
without a relabel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlEIFNgACgkQrlYvE4MpobPO/ACfcYzgUaDdnQj/Kdj2lyqCDhbu
ENEAoIZLa3xWD0O+nB/bGg+pVFAfHbPN
=3yRB
-----END PGP SIGNATURE-----
12:34 p.m.
On Tue, 2013-01-29 at 13:28 -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/29/2013 11:20 AM, John Reiser wrote:
>>>> A generic fallback image should be installed by anaconda on
>>>> installation/update and never ever be removed.
>
>> Also, fallback has interesting security properties…
>
>
> "Rescue mode" forces a SELinux relabel at the next boot, and relabel can
> take a very long time.
>
> How does "fallback mode" handle this, particularly if there have been
> updates to SELinux policy after the fallback was created?
>
The reason for this is we do not know what files were created on the system
while SELinux was disabled (Policy Not Loaded). If you know you did not
created files on the system you could remove the /.autorelabel file and boot
without a relabel.
Can we have a relabel mode that just searches only files changed after a
specific date ?
If we stored the time of last "good" shutdown somewhere it would mean we
might be able to relabel only a minor subset of files, saving a lot of
time ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:45 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/29/2013 01:34 PM, Simo Sorce wrote:
On Tue, 2013-01-29 at 13:28 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> On 01/29/2013 11:20 AM, John Reiser wrote:
>>>>> A generic fallback image should be installed by anaconda on
>>>>> installation/update and never ever be removed.
>>
>>> Also, fallback has interesting security properties…
>>
>>
>> "Rescue mode" forces a SELinux relabel at the next boot, and relabel
>> can take a very long time.
>>
>> How does "fallback mode" handle this, particularly if there have been
>> updates to SELinux policy after the fallback was created?
>>
> The reason for this is we do not know what files were created on the
> system while SELinux was disabled (Policy Not Loaded). If you know you
> did not created files on the system you could remove the /.autorelabel
> file and boot without a relabel.
Can we have a relabel mode that just searches only files changed after a
specific date ? If we stored the time of last "good" shutdown somewhere it
would mean we might be able to relabel only a minor subset of files, saving
a lot of time ?
Simo.
Well you would still need to search everywhere on the file system. for those
files. If the filesystem gave an easy way to find the latest fds that have
been changed, then ...
I guess we could compare any file created after /.autorelabel, and then get
the relabel to be
find / -newer /.autorelabel -print0 | restorecon -f - -0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlEIGNcACgkQrlYvE4MpobOm0QCgmD0eaIy8arEliV2EEOg68iPE
rjkAoKGTL1IhvVkqDM2phKbPqiyq+r+1
=zoBy
-----END PGP SIGNATURE-----
12:57 p.m.
On Tue, 2013-01-29 at 13:45 -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/29/2013 01:34 PM, Simo Sorce wrote:
> On Tue, 2013-01-29 at 13:28 -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 01/29/2013 11:20 AM, John Reiser wrote:
>>>>>> A generic fallback image should be installed by anaconda on
>>>>>> installation/update and never ever be removed.
>>>
>>>> Also, fallback has interesting security properties…
>>>
>>>
>>> "Rescue mode" forces a SELinux relabel at the next boot, and
relabel
>>> can take a very long time.
>>>
>>> How does "fallback mode" handle this, particularly if there have
been
>>> updates to SELinux policy after the fallback was created?
>>>
>> The reason for this is we do not know what files were created on the
>> system while SELinux was disabled (Policy Not Loaded). If you know you
>> did not created files on the system you could remove the /.autorelabel
>> file and boot without a relabel.
>
> Can we have a relabel mode that just searches only files changed after a
> specific date ? If we stored the time of last "good" shutdown somewhere
it
> would mean we might be able to relabel only a minor subset of files, saving
> a lot of time ?
>
> Simo.
>
Well you would still need to search everywhere on the file system. for those
files. If the filesystem gave an easy way to find the latest fds that have
been changed, then ...
I guess we could compare any file created after /.autorelabel, and then get
the relabel to be
find / -newer /.autorelabel -print0 | restorecon -f - -0
Yeah that may be an idea, if you can insure .autorelabel is the first
file that gets created.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
4:34 a.m.
Am 29.01.2013 19:28, schrieb Daniel J Walsh:
On 01/29/2013 11:20 AM, John Reiser wrote:
>>>> A generic fallback image should be installed by anaconda on
>>>> installation/update and never ever be removed.
>> Also, fallback has interesting security properties…
> "Rescue mode" forces a SELinux relabel at the next boot, and relabel can
> take a very long time.
> How does "fallback mode" handle this, particularly if there have been
> updates to SELinux policy after the fallback was created?
The reason for this is we do not know what files were created on the system
while SELinux was disabled (Policy Not Loaded). If you know you did not
created files on the system you could remove the /.autorelabel file and boot
without a relabel.
The "rescue" initramfs carries just more kernel drivers to cope with different
HW and will also have more debug tools, if you really really screwed up your
real root. Nothing security fancy here, besides that you might want to passwort
protect this entry, either via grub or via including /etc/passwd with a rescue
root password in the initramfs.
11:14 a.m.
On Fri, 01 Feb 2013 11:34:40 +0100
Harald Hoyer <harald.hoyer(a)gmail.com> wrote:
The "rescue" initramfs carries just more kernel drivers to
cope with
different HW and will also have more debug tools, if you really
really screwed up your real root. Nothing security fancy here,
besides that you might want to passwort protect this entry, either
via grub or via including /etc/passwd with a rescue root password in
the initramfs.
So, is this 'rescue' mode the same as the current rescue mode on
dvd/netinstall via anaconda? Or just similar?
Is it intended to replace those?
Can you easily setup network and find your installs (if any)?
kevin
4:32 a.m.
Am 29.01.2013 17:20, schrieb John Reiser:
>>> A generic fallback image should be
>>> installed by anaconda on installation/update and never ever be
>>> removed.
> Also, fallback has interesting security properties…
"Rescue mode" forces a SELinux relabel at the next boot, and relabel
can take a very long time.
How does "fallback mode" handle this, particularly if there have been
updates to SELinux policy after the fallback was created?
The "rescue" initramfs and all initramfs in general do _not_ carry any selinux
policies. These are turned on later on the real root. Nothing changes here.
9:53 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Tue, 29 Jan 2013 14:45:34 +0000
Jaroslav Reznik <jreznik(a)redhat.com> escribió:
= Features/DracutHostOnly =
https://fedoraproject.org/wiki/Features/DracutHostOnly
Feature owner(s): Harald Hoyer <harald(a)redhat.com>
Only create "host-only" initramfs images. A generic fallback image
should be installed by anaconda on installation/update and never ever
be removed.
== Detailed description ==
Current initramfs images contain most of the kernel drivers to boot
from any hardware. This results in a very big initramfs, which takes
a long time to load on system start and a long time to create on
kernel updates. Switching to host-only will improve the situation. To
cope with hardware change, a boot entry "Rescue System" should be
installed with a full fledged initramfs also containing debug tools.
This boot entry can then be used to recover from hardware changes and
also from unforseen software failure after updates.
as legal has said we cannot pregenerate initramfses i think this should
be a non-starter. even loading a 20mb initramfs from a sdcard on a slow
arm box doesnt take that long, and id personally much rather be able to
change hardware or yank the drive and put it into a different box
without worrying about making sure i have the right initramfs bits in
place. at least to me the costs outweigh the benefits. the grub timeout
on my laptop/desktops is longer than the time it takes to load the
initramfs.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlEH8IAACgkQkSxm47BaWfeK0QCfbg5Sa4YKjOY53mAyVh7IK9E/
YugAoKsEGgkLroJ1ht3FT+v5gJJxYqFS
=S7mz
-----END PGP SIGNATURE-----
10:26 a.m.
On Tue, Jan 29, 2013 at 4:53 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Tue, 29 Jan 2013 14:45:34 +0000
Jaroslav Reznik <jreznik(a)redhat.com> escribió:
> = Features/DracutHostOnly =
> https://fedoraproject.org/wiki/Features/DracutHostOnly
>
> Feature owner(s): Harald Hoyer <harald(a)redhat.com>
>
> Only create "host-only" initramfs images. A generic fallback image
> should be installed by anaconda on installation/update and never ever
> be removed.
>
> == Detailed description ==
> Current initramfs images contain most of the kernel drivers to boot
> from any hardware. This results in a very big initramfs, which takes
> a long time to load on system start and a long time to create on
> kernel updates. Switching to host-only will improve the situation. To
> cope with hardware change, a boot entry "Rescue System" should be
> installed with a full fledged initramfs also containing debug tools.
> This boot entry can then be used to recover from hardware changes and
> also from unforseen software failure after updates.
as legal has said we cannot pregenerate initramfses i think this should
be a non-starter.
It can be generated at install time.
5:22 p.m.
On Tue, 29 Jan 2013 16:32:12 +0000
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
> as legal has said we cannot pregenerate initramfses i think this
> should be a non-starter.
We already ship several pre-generated initramfses.
that are built at kernel build time? the issue with building it at
build time was making sure we knew exactly what sourcs we needed to
ship to match all the binaries in the initramfs. the initramfs's we
build and ship as part of teh install tree we know exactly what sources
because they match what is in the release tree rather than what was in
the buildroot at build time.
Dennis
5:53 p.m.
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote:
> We already ship several pre-generated initramfses.
that are built at kernel build time? the issue with building it at
build time was making sure we knew exactly what sourcs we needed to
ship to match all the binaries in the initramfs. the initramfs's we
build and ship as part of teh install tree we know exactly what sources
because they match what is in the release tree rather than what was in
the buildroot at build time.
Does the kernel source RPM matching the initrd contain the necessary
sources?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
5:57 p.m.
On Tue, Jan 29, 2013 at 6:53 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote:
> > We already ship several pre-generated initramfses.
> that are built at kernel build time? the issue with building it at
> build time was making sure we knew exactly what sourcs we needed to
> ship to match all the binaries in the initramfs. the initramfs's we
> build and ship as part of teh install tree we know exactly what sources
> because they match what is in the release tree rather than what was in
> the buildroot at build time.
Does the kernel source RPM matching the initrd contain the necessary
sources?
What? No. The kernel source RPM contains kernel sources. It has
nothing to do with the initramfs. It creates a dummy file with the same
name by dd'ing from /dev/zero and marks that as %ghost. The actual
initramfs is built by grubby when the kernel package is installed because
of the call to new-kernel-pkg.
josh
6:43 p.m.
On Tue, Jan 29, 2013 at 06:57:29PM -0500, Josh Boyer wrote:
>> that are built at kernel build time? the issue with building
it at
>> build time was making sure we knew exactly what sourcs we needed to
>> ship to match all the binaries in the initramfs. the initramfs's we
>> build and ship as part of teh install tree we know exactly what sources
>> because they match what is in the release tree rather than what was in
>> the buildroot at build time.
> Does the kernel source RPM matching the initrd contain the necessary
> sources?
What? No. The kernel source RPM contains kernel sources. It has
nothing to do with the initramfs. It creates a dummy file with the same
name by dd'ing from /dev/zero and marks that as %ghost. The actual
initramfs is built by grubby when the kernel package is installed because
of the call to new-kernel-pkg.
I kind of feel like you're just jumping in the middle here. The discussion
was about building these at kernel build time, rather than having grubby do
it. Then the above would cease to be true. If we've got binary bits we can't
track back to the source, I can see why legal would be concerned.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
7:11 p.m.
On Tue, Jan 29, 2013 at 7:43 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Tue, Jan 29, 2013 at 06:57:29PM -0500, Josh Boyer wrote:
> >> that are built at kernel build time? the issue with building it at
> >> build time was making sure we knew exactly what sourcs we needed to
> >> ship to match all the binaries in the initramfs. the initramfs's we
> >> build and ship as part of teh install tree we know exactly what sources
> >> because they match what is in the release tree rather than what was in
> >> the buildroot at build time.
> > Does the kernel source RPM matching the initrd contain the necessary
> > sources?
> What? No. The kernel source RPM contains kernel sources. It has
> nothing to do with the initramfs. It creates a dummy file with the same
> name by dd'ing from /dev/zero and marks that as %ghost. The actual
> initramfs is built by grubby when the kernel package is installed because
> of the call to new-kernel-pkg.
I kind of feel like you're just jumping in the middle here. The discussion
Er... indeed. I was. I thought you were asking a different question. I
misread, so apologies.
was about building these at kernel build time, rather than having
grubby do
it. Then the above would cease to be true. If we've got binary bits we can't
track back to the source, I can see why legal would be concerned.
Yes. Also, that sounds horrible.
josh
5:59 p.m.
On Tue, 29 Jan 2013 18:53:00 -0500
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote:
> > We already ship several pre-generated initramfses.
> that are built at kernel build time? the issue with building it at
> build time was making sure we knew exactly what sourcs we needed to
> ship to match all the binaries in the initramfs. the initramfs's we
> build and ship as part of teh install tree we know exactly what
> sources because they match what is in the release tree rather than
> what was in the buildroot at build time.
Does the kernel source RPM matching the initrd contain the necessary
sources?
not for every binary in the initramfs its much more than just the
kernel and its modules.
Dennis
6:25 p.m.
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote:
On Tue, 29 Jan 2013 16:32:12 +0000
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
> > as legal has said we cannot pregenerate initramfses i think this
> > should be a non-starter.
>
> We already ship several pre-generated initramfses.
>
that are built at kernel build time? the issue with building it at
build time was making sure we knew exactly what sourcs we needed to
ship to match all the binaries in the initramfs. the initramfs's we
build and ship as part of teh install tree we know exactly what sources
because they match what is in the release tree rather than what was in
the buildroot at build time.
Yeah ok that case is a problem.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:06 a.m.
On Wed, Jan 30, 2013 at 1:25 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote:
> On Tue, 29 Jan 2013 16:32:12 +0000
> Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
> > > as legal has said we cannot pregenerate initramfses i think this
> > > should be a non-starter.
> >
> > We already ship several pre-generated initramfses.
> >
>
> that are built at kernel build time? the issue with building it at
> build time was making sure we knew exactly what sourcs we needed to
> ship to match all the binaries in the initramfs. the initramfs's we
> build and ship as part of teh install tree we know exactly what sources
> because they match what is in the release tree rather than what was in
> the buildroot at build time.
Yeah ok that case is a problem.
Not really. We use a chroot for builds you can look at root.log to see
which packages where present at buildtime so we know the sources that
are needed.
Does not really sound like a hard problem to me.
4:39 a.m.
Am 30.01.2013 00:22, schrieb Dennis Gilmore:
On Tue, 29 Jan 2013 16:32:12 +0000
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
>> as legal has said we cannot pregenerate initramfses i think this
>> should be a non-starter.
>
> We already ship several pre-generated initramfses.
>
that are built at kernel build time? the issue with building it at
build time was making sure we knew exactly what sourcs we needed to
ship to match all the binaries in the initramfs. the initramfs's we
build and ship as part of teh install tree we know exactly what sources
because they match what is in the release tree rather than what was in
the buildroot at build time.
Dennis
The problem with kernel modules is, that the system can have/need non-kernel.rpm
modules and you would have to stack several initramfs images then and that leads
to the problem with depmod generated files.
9:56 a.m.
On Tue, Jan 29, 2013 at 6:22 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
that are built at kernel build time? the issue with building it at
build time was making sure we knew exactly what sourcs we needed to
ship to match all the binaries in the initramfs. the initramfs's we
build and ship as part of teh install tree we know exactly what sources
because they match what is in the release tree rather than what was in
the buildroot at build time.
That _is_ a missing piece of the dracut/initramfs toolchain: we need
something in dracut that scans what files have been included from the
buildhost, finds what rpm they belong to and writes down the NEVRA
into a file that goes _into_ the initramfs.
Right now, it is impossible to trace back the origin of an arbitrary
initramfs built by dracut. Unless you find the build host (and it
hasn't changed!).
At OLPC we've had a few incidents of "where the hell did you build
this initramfs?" and "how can I respin this initramfs with only this
patch applied, no other changes whatsoever?".
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
12:02 p.m.
On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
as legal has said we cannot pregenerate initramfses i think this
should
be a non-starter.
Intriguing .. what is the objection to pre-generating an initramfs?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
12:27 p.m.
On Tue, Jan 29, 2013 at 4:53 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Tue, 29 Jan 2013 14:45:34 +0000
Jaroslav Reznik <jreznik(a)redhat.com> escribió:
> = Features/DracutHostOnly =
> https://fedoraproject.org/wiki/Features/DracutHostOnly
>
> Feature owner(s): Harald Hoyer <harald(a)redhat.com>
>
> Only create "host-only" initramfs images. A generic fallback image
> should be installed by anaconda on installation/update and never ever
> be removed.
>
> == Detailed description ==
> Current initramfs images contain most of the kernel drivers to boot
> from any hardware. This results in a very big initramfs, which takes
> a long time to load on system start and a long time to create on
> kernel updates. Switching to host-only will improve the situation. To
> cope with hardware change, a boot entry "Rescue System" should be
> installed with a full fledged initramfs also containing debug tools.
> This boot entry can then be used to recover from hardware changes and
> also from unforseen software failure after updates.
as legal has said we cannot pregenerate initramfses i think this should
be a non-starter.
Thinking about this some more ... that does not make sense. A
initramfs does not link anything but simply put stuff into an image
similar to a tarball or even an ISO image.
So what exactly are the objections raised by legal?
3:12 p.m.
On Tue, Jan 29, 2013 at 4:53 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
even loading a 20mb initramfs from a sdcard on a slow
arm box doesnt take that long, and id personally much rather be able to
change hardware or yank the drive and put it into a different box
without worrying about making sure i have the right initramfs bits in
place. at least to me the costs outweigh the benefits. the grub timeout
on my laptop/desktops is longer than the time it takes to load the
initramfs.
This actually suggests a different way to achieve the same result:
Teach grub to preload the kernel and initrd while waiting for the
timeout. That gives us _even better_ speedup, and doesn't sacrifice
the generic usability of the initrd.
Mirek
4:07 p.m.
Miloslav Trmač (mitr(a)volny.cz) said:
On Tue, Jan 29, 2013 at 4:53 PM, Dennis Gilmore
<dennis(a)ausil.us> wrote:
> even loading a 20mb initramfs from a sdcard on a slow
> arm box doesnt take that long, and id personally much rather be able to
> change hardware or yank the drive and put it into a different box
> without worrying about making sure i have the right initramfs bits in
> place. at least to me the costs outweigh the benefits. the grub timeout
> on my laptop/desktops is longer than the time it takes to load the
> initramfs.
This actually suggests a different way to achieve the same result:
Teach grub to preload the kernel and initrd while waiting for the
timeout. That gives us _even better_ speedup, and doesn't sacrifice
the generic usability of the initrd.
Well, if the plan is to not timeout, that won't help. But it could be
interesting. Although, everything I've heard about the grub code makes
me entirely concerned when something that amounts to 'introduce threads'
is suggested.
Bill
5:44 p.m.
On 01/30/2013 02:07 PM, Bill Nottingham wrote:
Miloslav Trmač (mitr(a)volny.cz) said:
> Teach grub to preload the kernel and initrd while waiting for
the
> timeout. That gives us _even better_ speedup, and doesn't sacrifice
> the generic usability of the initrd.
Well, if the plan is to not timeout, that won't help. But it
could be
interesting. Although, everything I've heard about the grub code makes
me entirely concerned when something that amounts to 'introduce threads'
is suggested.
Threads are not needed and not desired; the analog of SIGALRM works fine
single-threaded.
The problem is the possibility of I/O errors when reading ahead.
Recovery from an I/O error can take a very long time, and may be
not interruptable. For instance, the linux kernel can take _minutes_
to recover from CD/DVD errors, and grub might be no better.
If read-ahead (after no wait) on the default choice "always" runs into
trouble, then selecting some other choice might be impossible.
--
4:37 a.m.
Am 29.01.2013 16:53, schrieb Dennis Gilmore:
El Tue, 29 Jan 2013 14:45:34 +0000
Jaroslav Reznik <jreznik(a)redhat.com> escribió:
> = Features/DracutHostOnly =
> https://fedoraproject.org/wiki/Features/DracutHostOnly
> Feature owner(s): Harald Hoyer <harald(a)redhat.com>
> Only create "host-only" initramfs images. A generic fallback image
> should be installed by anaconda on installation/update and never ever
> be removed.
> == Detailed description ==
> Current initramfs images contain most of the kernel drivers to boot
> from any hardware. This results in a very big initramfs, which takes
> a long time to load on system start and a long time to create on
> kernel updates. Switching to host-only will improve the situation. To
> cope with hardware change, a boot entry "Rescue System" should be
> installed with a full fledged initramfs also containing debug tools.
> This boot entry can then be used to recover from hardware changes and
> also from unforseen software failure after updates.
as legal has said we cannot pregenerate initramfses i think this should
be a non-starter. even loading a 20mb initramfs from a sdcard on a slow
arm box doesnt take that long, and id personally much rather be able to
change hardware or yank the drive and put it into a different box
without worrying about making sure i have the right initramfs bits in
place. at least to me the costs outweigh the benefits. the grub timeout
on my laptop/desktops is longer than the time it takes to load the
initramfs.
Dennis
If you are running a lot of virtual machines, you will care about
a) boot time
b) disk size
c) yum update time (including generation of the initramfs)
4:46 a.m.
Am 01.02.2013 11:37, schrieb Harald Hoyer:
Am 29.01.2013 16:53, schrieb Dennis Gilmore:
> as legal has said we cannot pregenerate initramfses i think this should
> be a non-starter. even loading a 20mb initramfs from a sdcard on a slow
> arm box doesnt take that long, and id personally much rather be able to
> change hardware or yank the drive and put it into a different box
> without worrying about making sure i have the right initramfs bits in
> place. at least to me the costs outweigh the benefits. the grub timeout
> on my laptop/desktops is longer than the time it takes to load the
> initramfs.
>
If you are running a lot of virtual machines, you will care about
a) boot time
b) disk size
c) yum update time (including generation of the initramfs)
in this case you have already the following because on
virtual machines it is very unlikely that hardware
fundenemtally changes - but on real hardware as DEFAULT?
yes i have the same also on real hardware
but i would not recommend it to any other person
[root@testserver:~]$ cat /etc/dracut.conf.d/90-plymouth.conf
omit_dracutmodules+="plymouth"
[root@testserver:~]$ cat /etc/dracut.conf.d/91-host-only.conf
hostonly="yes"
11:22 a.m.
On Fri, 2013-02-01 at 11:46 +0100, Reindl Harald wrote:
in this case you have already the following because on
virtual machines it is very unlikely that hardware
fundenemtally changes
Porting machines from one virt system to another isn't that unusual, and
that can cause the hardware to change.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:02 p.m.
Am 01.02.2013 18:22, schrieb Adam Williamson:
On Fri, 2013-02-01 at 11:46 +0100, Reindl Harald wrote:
> in this case you have already the following because on
> virtual machines it is very unlikely that hardware
> fundenemtally changes
Porting machines from one virt system to another isn't that unusual, and
that can cause the hardware to change
one reson more to NOT make HostOnly DEFAULT
there where i work you setup HA clusters and failover and
will not change for fun the infrastructure behind the guests
because the main target of virtualization is abstraction
from the real hardware and so HostOnly is OK, i can live with
it but i can see no sense in making it default to make others
lifes harder
12:44 p.m.
On Jan 29, 2013, at 6:09 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
A generic fallback image should be
installed by anaconda on installation/update and never ever be removed.
FYI, this will require change/supplementing grub2, possibly with a 4x_custom file, or
rescue specific, in /etc/grub.d. Without such addition, grub2-mkconfig will create a
grub.cfg without the rescue entry.
And grubby quickly messes up existing grub2 grub.cfgs by progressively deleting entries,
so it may need to be looked at to make sure it doesn't delete either container
entries, or the rescue entries themselves.
Chris Murphy
1:34 p.m.
Jaroslav Reznik (jreznik(a)redhat.com) said:
= Features/DracutHostOnly =
https://fedoraproject.org/wiki/Features/DracutHostOnly
Feature owner(s): Harald Hoyer <harald(a)redhat.com>
Only create "host-only" initramfs images. A generic fallback image should be
installed by anaconda on installation/update and never ever be removed.
== Detailed description ==
Current initramfs images contain most of the kernel drivers to boot from any
hardware. This results in a very big initramfs, which takes a long time to
load on system start and a long time to create on kernel updates. Switching to
host-only will improve the situation. To cope with hardware change, a boot
entry "Rescue System" should be installed with a full fledged initramfs also
containing debug tools. This boot entry can then be used to recover from
hardware changes and also from unforseen software failure after updates.
Do we actually have agreement on the anaconda/lorax side for the changes
required here?
What happens if the updated system (due to userspace, SELinux policy, what
have you) moves beyond something that can be properly rescued?
Will there be a fedup module to regenerate the rescue image on OS upgrade?
Bill
1:51 a.m.
Hi Jaroslav,
I would like to raise a caution about implementing this change. Several other non-Linux
systems are able to handle a variety of hardware changes after installation, and still
boot afterwards. I think it would be unfortunate if, after changing hardware, it were not
possible to boot other than with a rescue image. Hardware is becoming faster, and even on
our small ARM boards, initramfs size is not such a huge problem, especially in the medium
term.
Jon.
--
Sent from my iPad
On Jan 29, 2013, at 10:00, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
= Features/DracutHostOnly =
https://fedoraproject.org/wiki/Features/DracutHostOnly
Feature owner(s): Harald Hoyer <harald(a)redhat.com>
Only create "host-only" initramfs images. A generic fallback image should be
installed by anaconda on installation/update and never ever be removed.
== Detailed description ==
Current initramfs images contain most of the kernel drivers to boot from any
hardware. This results in a very big initramfs, which takes a long time to
load on system start and a long time to create on kernel updates. Switching to
host-only will improve the situation. To cope with hardware change, a boot
entry "Rescue System" should be installed with a full fledged initramfs also
containing debug tools. This boot entry can then be used to recover from
hardware changes and also from unforseen software failure after updates.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
8:47 a.m.
= Features/DracutHostOnly =
https://fedoraproject.org/wiki/Features/DracutHostOnly
... This results in a very big initramfs, which takes a long time to
load on system start and a long time to create on kernel updates.
For speed in creating an initramfs, please consider Requiring
the package 'pigz' (Parallel Implementation of GZip), or at least highlight
this feature in the documentation. If pigz is present in $PATH,
then already today dracut uses it, and this speeds up the compression
by a factor equal to the number of CPUs. On my 3GHz box with 2 CPUs
the gzip time is about 20 seconds, but using pigz takes only 10 seconds.
--
8:50 a.m.
Am 04.02.2013 15:47, schrieb John Reiser:
> = Features/DracutHostOnly =
> https://fedoraproject.org/wiki/Features/DracutHostOnly
> ... This results in a very big initramfs, which takes a long time to
> load on system start and a long time to create on kernel updates.
For speed in creating an initramfs, please consider Requiring
the package 'pigz' (Parallel Implementation of GZip), or at least highlight
this feature in the documentation. If pigz is present in $PATH,
then already today dracut uses it, and this speeds up the compression
by a factor equal to the number of CPUs. On my 3GHz box with 2 CPUs
the gzip time is about 20 seconds, but using pigz takes only 10 seconds
thanks for that
below the output of a HostOnly one before
and after "yum install pigz" and so i take
this package in my base-metapackage
[root@rh:~]$ date; dracut -f; date
Mo 4. Feb 15:47:50 CET 2013
Mo 4. Feb 15:48:02 CET 2013
[root@rh:~]$ date; dracut -f; date
Mo 4. Feb 15:48:31 CET 2013
Mo 4. Feb 15:48:36 CET 2013
4091
days inactive
4098
days old
52 comments
24 participants
participants (24)
-
Adam Williamson -
Bill Nottingham -
Chris Murphy -
Colin Walters -
Daniel J Walsh -
Dennis Gilmore -
drago01 -
Harald Hoyer -
Jaroslav Reznik -
John Reiser -
Jon Masters -
Josh Boyer -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Martin Langhoff -
Matthew Garrett -
Matthew Miller -
Michael Cronenworth -
Miloslav Trmač -
Nicolas Mailhot -
Reindl Harald -
Richard W.M. Jones -
Simo Sorce -
Stijn Hoop