9:10 a.m.
Hello, everybody,
I'd like to know your opinion on one issue we have hit on live
installations due to the DracutHostOnly feature [1]. Long story short:
1) Anaconda installs the kernel package
2) installation of the kernel package triggers dracut to generate initrd
3) dracut now generates so called "host-only" initrd, which, among the
other things, means, that it contains only one keymap -- the one that
was set in /etc/vconsole.conf at the time dracut was triggered to run
4) Anaconda configures the installed system based on the values set
during the installation.
The actual result is that if users type in their LUKS password with a
keyboard layout different from 'us', let's say 'gb' they cannot type
the
password again on boot, because the initrd has only the 'us' keymap (set
by default in the configuration file), even if there is
'vconsole.keymap=gb' as a boot option.
There are two basic approaches how to fix this on the installer side:
1) write out keyboard configuration before packages are installed
2) regenerate the initrd at the end of the installation
Both these solutions are not ideal from my point of view. And even if
one of them is accepted and applied, there would still be the problem
with systems, that have an initrd that blocks functionality of boot
options (maybe there are more than vconsole.keymap, I don't know).
So, is it a right thing to do to generate 3 MB smaller initrd's (the
summed up size of all keymaps) not supporting some boot options? Does
HostOnly mean the initrd works only with a specific host or that it
works only with a specific configuration of a specific host? I
understand having firmware for hardware that does not exist in the
system might be useless, but not supporting boot with a different
configuration options seems to me as a different thing.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=994180
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
9:44 a.m.
On 09/05/2013 04:25 PM, "Jóhann B. Guðmundsson" wrote:
On 09/05/2013 02:10 PM, Vratislav Podzimek wrote:
> 2) regenerate the initrd at the end of the installation
This is what should be done both for live and regular installs.
JBG
I concur and say:
1) write out keyboard configuration before packages are installed
1b) write out language configuration before packages are installed
10:52 a.m.
On 09/05/2013 02:44 PM, Harald Hoyer wrote:
I concur and say:
1) write out keyboard configuration before packages are installed
1b) write out language configuration before packages are installed
Had we narrowed it down to only keyboard/language configuration since I
vaguely recall coming across other type of bugs that required initramfs
re-genartion straight after install to fix.
JBG
2:51 a.m.
On Thu, 2013-09-05 at 15:52 +0000, "Jóhann B. Guðmundsson" wrote:
On 09/05/2013 02:44 PM, Harald Hoyer wrote:
> I concur and say:
> 1) write out keyboard configuration before packages are installed
> 1b) write out language configuration before packages are installed
Had we narrowed it down to only keyboard/language configuration since I
vaguely recall coming across other type of bugs that required initramfs
re-genartion straight after install to fix.
That's why I think re-generating
initrd would be a better and more solid
solution, hopefully effective for a long time.
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
10:17 a.m.
On Thu, 2013-09-05 at 14:25 +0000, "Jóhann B. Guðmundsson" wrote:
On 09/05/2013 02:10 PM, Vratislav Podzimek wrote:
> 2) regenerate the initrd at the end of the installation
This is what should be done both for live and regular installs.
JBG
The LUKS password issue is pretty serious. Anyone know if there is a
bug report for this?
2:46 a.m.
On Thu, 2013-09-05 at 10:17 -0500, Michael Catanzaro wrote:
On Thu, 2013-09-05 at 14:25 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 09/05/2013 02:10 PM, Vratislav Podzimek wrote:
> > 2) regenerate the initrd at the end of the installation
>
> This is what should be done both for live and regular installs.
>
> JBG
>
The LUKS password issue is pretty serious. Anyone know if there is a
bug report for this?
https://bugzilla.redhat.com/show_bug.cgi?id=994180
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
9:51 a.m.
On 09/05/2013 04:10 PM, Vratislav Podzimek wrote:
Hello, everybody,
I'd like to know your opinion on one issue we have hit on live
installations due to the DracutHostOnly feature [1]. Long story short:
1) Anaconda installs the kernel package
2) installation of the kernel package triggers dracut to generate initrd
3) dracut now generates so called "host-only" initrd, which, among the
other things, means, that it contains only one keymap -- the one that
was set in /etc/vconsole.conf at the time dracut was triggered to run
4) Anaconda configures the installed system based on the values set
during the installation.
The actual result is that if users type in their LUKS password with a
keyboard layout different from 'us', let's say 'gb' they cannot type
the
password again on boot, because the initrd has only the 'us' keymap (set
by default in the configuration file), even if there is
'vconsole.keymap=gb' as a boot option.
There are two basic approaches how to fix this on the installer side:
1) write out keyboard configuration before packages are installed
2) regenerate the initrd at the end of the installation
Both these solutions are not ideal from my point of view. And even if
one of them is accepted and applied, there would still be the problem
with systems, that have an initrd that blocks functionality of boot
options (maybe there are more than vconsole.keymap, I don't know).
So, is it a right thing to do to generate 3 MB smaller initrd's (the
summed up size of all keymaps) not supporting some boot options? Does
HostOnly mean the initrd works only with a specific host or that it
works only with a specific configuration of a specific host? I
understand having firmware for hardware that does not exist in the
system might be useless, but not supporting boot with a different
configuration options seems to me as a different thing.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=994180
host only means, it only works on that machine (kernel modules) with that disk
layout (including language and keymap for disk passwords).
https://fedoraproject.org/wiki/Features/DracutHostOnly#Release_Notes
This Fedora release builds an initramfs tailored especially for your computer
hardware. If you change your machine or partitions or significant hardware, you
might have to boot with the "Rescue" boot entry and execute "dracut
--regenerate-all". If you want your initramfs to be hardware independent,
install the "dracut-nohostonly" rpm package. If you don't want rescue images
at
all (like in virtual machines), install the "dracut-norescue" rpm package.
4:05 a.m.
On 05.09.2013 16:51, Harald Hoyer wrote:
This Fedora release builds an initramfs tailored especially for your
computer
hardware. If you change your machine or partitions or significant hardware, you
might have to boot with the "Rescue" boot entry and execute "dracut
--regenerate-all". If you want your initramfs to be hardware independent,
install the "dracut-nohostonly" rpm package. If you don't want rescue
images at
all (like in virtual machines), install the "dracut-norescue" rpm package.
Package over here, package over there.
It's not so long ago called configuration.
Now if we want to configure something, we install a package.
Can someone package a pizza and send it here.
Oh wait, I forgot about prosciutto.
Install a prosciutto package, please.
poma
4:31 a.m.
On 09/06/2013 11:05 AM, poma wrote:
On 05.09.2013 16:51, Harald Hoyer wrote:
> This Fedora release builds an initramfs tailored especially for your computer
> hardware. If you change your machine or partitions or significant hardware, you
> might have to boot with the "Rescue" boot entry and execute "dracut
> --regenerate-all". If you want your initramfs to be hardware independent,
> install the "dracut-nohostonly" rpm package. If you don't want rescue
images at
> all (like in virtual machines), install the "dracut-norescue" rpm package.
>
Package over here, package over there.
It's not so long ago called configuration.
Now if we want to configure something, we install a package.
Can someone package a pizza and send it here.
Oh wait, I forgot about prosciutto.
Install a prosciutto package, please.
Using package installation as configuration is quite bizarre.
Wasn't there a specific policy that installation and configuration
are two different things?
"You installed httpd, ok, so you have the stuff on your disk, but that
does not mean it will run at next reboot, you have to configure and
activate it explicitly".
--
Roberto Ragusa mail at robertoragusa.it
4:38 a.m.
On 09/06/2013 11:31 AM, Roberto Ragusa wrote:
On 09/06/2013 11:05 AM, poma wrote:
> On 05.09.2013 16:51, Harald Hoyer wrote:
>
>> This Fedora release builds an initramfs tailored especially for your computer
>> hardware. If you change your machine or partitions or significant hardware, you
>> might have to boot with the "Rescue" boot entry and execute
"dracut
>> --regenerate-all". If you want your initramfs to be hardware independent,
>> install the "dracut-nohostonly" rpm package. If you don't want
rescue images at
>> all (like in virtual machines), install the "dracut-norescue" rpm
package.
>>
>
> Package over here, package over there.
> It's not so long ago called configuration.
> Now if we want to configure something, we install a package.
> Can someone package a pizza and send it here.
> Oh wait, I forgot about prosciutto.
> Install a prosciutto package, please.
Using package installation as configuration is quite bizarre.
Wasn't there a specific policy that installation and configuration
are two different things?
"You installed httpd, ok, so you have the stuff on your disk, but that
does not mean it will run at next reboot, you have to configure and
activate it explicitly".
Well, because the initramfs was built in the %posttrans-action of the
installation, pulling in the configuration to build a different kind of
initramfs seemed the easiest way of doing kickstarts for me.
This was done to avoid building the initramfs twice.
8:36 a.m.
On 06.09.2013 11:38, Harald Hoyer wrote:
On 09/06/2013 11:31 AM, Roberto Ragusa wrote:
> On 09/06/2013 11:05 AM, poma wrote:
>> On 05.09.2013 16:51, Harald Hoyer wrote:
>>
>>> This Fedora release builds an initramfs tailored especially for your
computer
>>> hardware. If you change your machine or partitions or significant hardware,
you
>>> might have to boot with the "Rescue" boot entry and execute
"dracut
>>> --regenerate-all". If you want your initramfs to be hardware
independent,
>>> install the "dracut-nohostonly" rpm package. If you don't want
rescue images at
>>> all (like in virtual machines), install the "dracut-norescue" rpm
package.
>>>
>>
>> Package over here, package over there.
>> It's not so long ago called configuration.
>> Now if we want to configure something, we install a package.
>> Can someone package a pizza and send it here.
>> Oh wait, I forgot about prosciutto.
>> Install a prosciutto package, please.
>
> Using package installation as configuration is quite bizarre.
>
> Wasn't there a specific policy that installation and configuration
> are two different things?
> "You installed httpd, ok, so you have the stuff on your disk, but that
> does not mean it will run at next reboot, you have to configure and
> activate it explicitly".
>
Well, because the initramfs was built in the %posttrans-action of the
installation, pulling in the configuration to build a different kind of
initramfs seemed the easiest way of doing kickstarts for me.
If something is good for someone, why not recommend it to the others, right.
Urbi et Orbi.
poma
5:15 a.m.
Harald Hoyer píše v Čt 05. 09. 2013 v 16:51 +0200:
On 09/05/2013 04:10 PM, Vratislav Podzimek wrote:
> Hello, everybody,
> I'd like to know your opinion on one issue we have hit on live
> installations due to the DracutHostOnly feature [1]. Long story short:
> 1) Anaconda installs the kernel package
> 2) installation of the kernel package triggers dracut to generate initrd
> 3) dracut now generates so called "host-only" initrd, which, among the
> other things, means, that it contains only one keymap -- the one that
> was set in /etc/vconsole.conf at the time dracut was triggered to run
> 4) Anaconda configures the installed system based on the values set
> during the installation.
>
> The actual result is that if users type in their LUKS password with a
> keyboard layout different from 'us', let's say 'gb' they cannot
type the
> password again on boot, because the initrd has only the 'us' keymap (set
> by default in the configuration file), even if there is
> 'vconsole.keymap=gb' as a boot option.
>
> There are two basic approaches how to fix this on the installer side:
> 1) write out keyboard configuration before packages are installed
> 2) regenerate the initrd at the end of the installation
>
> Both these solutions are not ideal from my point of view. And even if
> one of them is accepted and applied, there would still be the problem
> with systems, that have an initrd that blocks functionality of boot
> options (maybe there are more than vconsole.keymap, I don't know).
>
> So, is it a right thing to do to generate 3 MB smaller initrd's (the
> summed up size of all keymaps) not supporting some boot options? Does
> HostOnly mean the initrd works only with a specific host or that it
> works only with a specific configuration of a specific host? I
> understand having firmware for hardware that does not exist in the
> system might be useless, but not supporting boot with a different
> configuration options seems to me as a different thing.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=994180
>
host only means, it only works on that machine (kernel modules) with that disk
layout (including language and keymap for disk passwords).
https://fedoraproject.org/wiki/Features/DracutHostOnly#Release_Notes
This Fedora release builds an initramfs tailored especially for your computer
hardware. If you change your machine or partitions or significant hardware, you
might have to boot with the "Rescue" boot entry and execute "dracut
--regenerate-all".
Can this not be done automatically? If the system fails to boot because
of significant hardware changes, it's an obvious option to regenerate
initramfs. I can't image a normal user go to the rescue mode and run
"dracut --regenerate-all". Not that it's difficult to do it, but the
discoverability of the solution is bad.
Jiri
5:45 a.m.
On 09/06/2013 10:15 AM, Jiri Eischmann wrote:
Can this not be done automatically? If the system fails to boot
because
of significant hardware changes, it's an obvious option to regenerate
initramfs. I can't image a normal user go to the rescue mode and run
"dracut --regenerate-all". Not that it's difficult to do it, but the
discoverability of the solution is bad.
This has been discussed in the past and if we are going to head down
that road we need a proper end user friendly UI rescue environment for
the core/baseOS which automatically scans things for problem and
proposes to fix that for the novice end user.
I'm pretty sure nobody is against this but as usual as someone has to do
all that work...
JBG
6:48 a.m.
On 09/06/2013 10:15 AM, Jiri Eischmann wrote:
> Can this not be done automatically? If the system fails to boot because
> of significant hardware changes, it's an obvious option to regenerate
> initramfs. I can't image a normal user go to the rescue mode and run
> "dracut --regenerate-all". Not that it's difficult to do it, but the
> discoverability of the solution is bad.
This has been discussed in the past and if we are going to head down
that road we need a proper end user friendly UI rescue environment for
the core/baseOS which automatically scans things for problem and
proposes to fix that for the novice end user.
I'm pretty sure nobody is against this but as usual as someone has to do
all that work...
It should have been a prerequisite for dracut host-only feature.
7:11 a.m.
On 09/09/2013 11:48 AM, Kamil Paral wrote:
> On 09/06/2013 10:15 AM, Jiri Eischmann wrote:
>> Can this not be done automatically? If the system fails to boot because
>> of significant hardware changes, it's an obvious option to regenerate
>> initramfs. I can't image a normal user go to the rescue mode and run
>> "dracut --regenerate-all". Not that it's difficult to do it, but
the
>> discoverability of the solution is bad.
> This has been discussed in the past and if we are going to head down
> that road we need a proper end user friendly UI rescue environment for
> the core/baseOS which automatically scans things for problem and
> proposes to fix that for the novice end user.
>
> I'm pretty sure nobody is against this but as usual as someone has to do
> all that work...
It should have been a prerequisite for dracut host-only feature.
It's nonsense having an full blown rescue environment as an requirement
for dracut-hostonly feature.
JBG
7:19 a.m.
Am 09.09.2013 14:11, schrieb Jóhann B. Guðmundsson:
On 09/09/2013 11:48 AM, Kamil Paral wrote:
>> On 09/06/2013 10:15 AM, Jiri Eischmann wrote:
>>> Can this not be done automatically? If the system fails to boot because
>>> of significant hardware changes, it's an obvious option to regenerate
>>> initramfs. I can't image a normal user go to the rescue mode and run
>>> "dracut --regenerate-all". Not that it's difficult to do it,
but the
>>> discoverability of the solution is bad.
>> This has been discussed in the past and if we are going to head down
>> that road we need a proper end user friendly UI rescue environment for
>> the core/baseOS which automatically scans things for problem and
>> proposes to fix that for the novice end user.
>>
>> I'm pretty sure nobody is against this but as usual as someone has to do
>> all that work...
> It should have been a prerequisite for dracut host-only feature.
It's nonsense having an full blown rescue environment as an requirement for
dracut-hostonly feature
i think you misread the post - IMHO the intention was that once again
a feature with zero benefit was acknowledged without caseful think about
the negative impact
maybe the "dracut-hostonly" feature was nonsense at all to save how many seconds
at boot?
the ones who like it and knowing what they are doing used it long ago
the ones with less technical background have more potential problems now
11:38 a.m.
On Mon, Sep 9, 2013 at 8:19 AM, Reindl Harald <h.reindl(a)thelounge.net>wrote:
i think you misread the post - IMHO the intention was that once
again
a feature with zero benefit was acknowledged without caseful think about
the negative impact
And I think you once again exaggerate, Harald. Just because the feature
doesn't offer benefits to you does not mean it isn't useful at all. Given
that it's fairly easy to switch between the various modes, I think that
essentially proves that those who made the change thought through the
possible negative impacts, and made it fairly easy for a systems
administrator to choose how they're like their system to work.
To drive the point home to its logical conclusion -- we're never going to
have *one* Fedora configuration that works perfectly for everyone.
Instead, we're going to have some level of configuration to make it as
painless as possible to allow competent administrators to configure their
systems in a manner that works best for them. Is the way you reconfigure
the initrd file ideal? I'd probably argue that it isn't ideal, but works
well enough for now. But could I in all honesty say that the feature has
no benefit, and that the developer(s) who made the change didn't think
about the possible negative impacts? No, I can't.
--
Jared Smith
11:48 a.m.
Am 09.09.2013 18:38, schrieb Jared K. Smith:
On Mon, Sep 9, 2013 at 8:19 AM, Reindl Harald
<h.reindl(a)thelounge.net <mailto:h.reindl@thelounge.net>> wrote:
i think you misread the post - IMHO the intention was that once again
a feature with zero benefit was acknowledged without caseful think about
the negative impact
And I think you once again exaggerate, Harald. Just because the feature doesn't
offer benefits to you does not
mean it isn't useful at all.
ironically i am using HostOnly and used it long before the "feature" was
proposed
so your argumentation is wrong and you should try to realize that i am often
not against things because they are a problem for *me* but because they are
not a wise idea in the big picture and in case of ordinary users
personally i can deal with most things - many don' as well they don't
understand documentations how to solve a problem or in the worst case
have no access to the documentation because the machine don't boot
Given that it's fairly easy to switch between the various modes,
I think that
essentially proves that those who made the change thought through the possible negative
impacts, and made it fairly
easy for a systems administrator to choose how they're like their system to work.
oh yeah, teel this the ordinary user which is not a systems administratot
To drive the point home to its logical conclusion -- we're never
going to have *one* Fedora configuration that
works perfectly for everyone
but we had init-ramdisks which worked for *more* users after whatever chnages
now Fedora switched to a more fragile default - the word "feature" for me
implies a benefit - i can't se a benefit in decisions making a OS setup
more windows-like "oh you changed your hardware, i won#t boot" while
this is a problem for the ordinary user and at the same time the educated
one doe snot need the default to save 1-2 seconds at boot while he is aware
about the impact
9:06 a.m.
On 09/09/2013 11:48 AM, Kamil Paral wrote:
>> On 09/06/2013 10:15 AM, Jiri Eischmann wrote:
>>> Can this not be done automatically? If the system fails to boot because
>>> of significant hardware changes, it's an obvious option to regenerate
>>> initramfs. I can't image a normal user go to the rescue mode and run
>>> "dracut --regenerate-all". Not that it's difficult to do it,
but the
>>> discoverability of the solution is bad.
>> This has been discussed in the past and if we are going to head down
>> that road we need a proper end user friendly UI rescue environment for
>> the core/baseOS which automatically scans things for problem and
>> proposes to fix that for the novice end user.
>>
>> I'm pretty sure nobody is against this but as usual as someone has to do
>> all that work...
> It should have been a prerequisite for dracut host-only feature.
It's nonsense having an full blown rescue environment as an requirement
for dracut-hostonly feature.
JBG
I haven't spoken about "full blown". But this feature caused two things:
a) performance (boot speed) went up
b) robustness went down (change of hardware "breaks" Fedora)
I might be speaking with my QA hat on, but we should really strive hard to keep and
increase the robustness of our system. Before host-only initrd was approved, we should
have had a prerequisite that would eliminate the biggest drawback. Especially for the
general audience the current behavior is a showstopper - they are not able to invoke
'dracut --regenerate-all' after they change their hardware. The implementation is
not that important, something is better than nothing. A few ideas:
a) regenerate initrd automatically on every system rescue boot
b) present a simple ncurses dialog on every system rescue boot, that allows the user to
regenerate initrd ("find new hardware") or continue booting to DE
c) if a standard boot fails, or if we detect a new hardware during that boot,
automatically regenerate initrd and reboot the machine
Sure, those are just rough ideas, full of problematic use cases and whatnot. But some of
them might not be _that_ hard to implement. And any of those would definitely be better
than having nothing. Not to mention that our bright developers' minds would surely
think of something even better.
And that's what we should have had as a prerequisite - having _some_ solution. But we
ended up as always - having a cool feature and saying "RTFM!" to all our general
users who get bitten by it.
2:24 a.m.
On Thu, Sep 05, 2013 at 04:51:14PM +0200, Harald Hoyer wrote:
host only means, it only works on that machine (kernel modules) with
that disk
layout (including language and keymap for disk passwords).
Language and keymap setting are not mentioned in the release notes
section:
https://fedoraproject.org/wiki/Features/DracutHostOnly#Release_Notes
This Fedora release builds an initramfs tailored especially for your computer
hardware. If you change your machine or partitions or significant hardware, you
might have to boot with the "Rescue" boot entry and execute "dracut
--regenerate-all". If you want your initramfs to be hardware independent,
install the "dracut-nohostonly" rpm package. If you don't want rescue
images at
all (like in virtual machines), install the "dracut-norescue" rpm package.
Regards
Till
3885
days inactive
3896
days old
20 comments
11 participants
participants (11)
-
Harald Hoyer -
Jared K. Smith -
Jiri Eischmann -
Jóhann B. Guðmundsson -
Kamil Paral -
Michael Catanzaro -
poma -
Reindl Harald -
Roberto Ragusa -
Till Maas -
Vratislav Podzimek