Red Hat Bugzilla – Bug 214962
kickstart's 'firstboot --reconfig' broken
Last modified: 2007-11-30 17:11:48 EST
I'm using a kickstart based setup here. In the kickstart file I have
mentioned the option 'firstboot --reconfig', so that the end user
can adjust the settings to his/her own wishes at the first boot.
After completing a installation of FC6 with this option, the
firstboot program is launched (as expected). However when reaching
the license-page, an error occurs. Instead of showing the
license-page, the network configuration page is shown. When I try
to click 'Next' on that page I keep gettings errors that I didn't
agree to the license so I can't go on. This makes it unable for
the user to complete the installation.
Here's some more information:
This issue only happens when you use the 'Back' button once during the firstboot
Please attach the error message to this bug report. If you are getting a
/tmp/firstboot-crash.log file, please attach it as well.
Here is a more clear description on how to reproduce this issue:
When you start firstboot in reconfig mode you get to choose your
language. If you pick any language other than the one active and
press next you will see the network settings page. If you try to
press next there you will get a message that you need to agree to
the license before you can continue, but that isn't possible as
the license page isn't visible on the screen.
This still happens in rawhide.
I think I've found the cause of this behaviour.
In the function clearNotebook in the file firstbootWindow.py
removes items from the notebook in the wrong order.
Attached patch solves this problem.
If this patch is to be applied, will it also be pushed back into FC6 updates?
Created attachment 148881 [details]
Patch which fixes the described behaviour
I actually just applied a separate patch that fixes the same issue in a
different way. That will be in the next build of firstboot, after I sort a
couple other things out. I'm not sure how much sense an updated firstboot
package makes since the only time you ever run firstboot is right after
anaconda's finished and there's not really any way to get the updated package
installed. OF course you could grab it in a kickstart file, but if you do a
kickstart install then you're probably not going to run firstboot.
Well, the kickstart file I'm using makes direct use of the updates repo, so
if a new version of firstboot could be pushed into the updates repo it will
automatically be included in new installations.
The environment in which my kickstart script is used is in a school where
each student can borrow a removable harddrive which is pre-installed with
Linux to perform network-related exercises on. I've enabled firstboot
by default there so the student can perform global configuration and
get noticed of the fact that it is recommended to create a normal user
when Linux gets booted for the first time.
Would it be possible for you to test firstboot-1.4.31 from the development tree
and see if that fixes your issue? Generally when I make updates for Fedora, I
like to just pull in the latest from devel to keep everything in sync but it
looks like there have been a lot of changes between the FC-6 version and the
I could probably make a firstboot update for just this issue. However, are you
averse to holding off on having the update until F7 comes out, or do you not
want to roll it out right away?
I'll test it tomorrow and give you some feedback on it.
If this definitely solves the problem I'm going to apply it
to our removable harddrive installations asap cause a lot of
students (dutch is our native language) are encountering this bug.
Unfortunately the latest rawhide build of firstboot doesn't fix my problem.
The program runs as expected (when changing the default language at the first
screen), but when you are done with the last page you get to see the welcome
screen again..from which you can't go on further. When you try to press
the 'next' button there nothing happens.
But your patch still fixes it?
No, after further testing I found out that my patch also doesn't fully solve the
problem. I'm going to mark it as obsolete.
I used 'yum --enablerepo=development update firstboot' to get the latest release
of firstboot. Should system-config-language be updated too?
system-config-language will be pulled in as an update if the newer firstboot
requires a newer version.
I've added a bit of a hack to firstboot to make this work, though it's becoming
more and more apparent that the current state of this code is rather poor and
maintaining it is becoming a chore. This fix will be in the next build of
Unfortunately firstboot --reconfig is still broken in F7. I haven't tested F7 +
firstboot/system-config* from rawhide yet, but will do so later today.
To summarize the problem :
We are using kickstart scripts to install F7. After the installation we want to
offer the students (=user) the possibility to change the default root password,
create a normal user account and change the language of the Linux installation.
The normal version of firstboot doesn't offer all three these options, so we
have used 'firstboot --reconfig' in our kickstart scripts.
When firstboot is launched I get to see the language selection screen. The
default language (as specified by the kickstart script) is 'English (USA)'. Most
of our students are dutch, so I select the option 'Dutch (Netherlands)' and
click on 'Forward'.
The language is now changed to dutch (as expected) and I get to see the
'Welcome' screen. At this point I click the 'Forward' button and get to see the
'License' screen. Nothing to do here,so I click the 'Forward' button again. The
'Keyboard' screen shows up. I leave this at the default (V.S. English) and click
At this point I get to see the 'Root password' screen. The top text field is
enabled, but the second text field (confirm root password) remains disabled.
This screen isn't translated, it's all in English, while I chose for the Dutch
language earlier in the firstboot process. If I press the 'Forward' button, a
label with the text 'The two fields did not match. Please try again' shows. The
second text field still remains disabled. Only if I leave the first text field
empty, I can continue the firstboot process.
From here on the firstboot process works without problems, but the root password
problem is very annoying.
Re-assigning to system-config-rootpassword as I think the cause of the problem
is in that package
User email@example.com's account has been closed
Erik: I believe this is the same issue as bug #259741. I'll commit the patch
into rawhide shortly. Also, would it be of any use for you to push an updated
*** This bug has been marked as a duplicate of 259741 ***