In https://bugzilla.redhat.com/show_bug.cgi?id=1035316 , we decided to stop writing vconsole.keymap=(user's layout) to grub2.cfg again, because it's no longer needed for the original purpose, and doing it was preventing you changing the layout post-install cleanly.
However, after working on https://bugzilla.redhat.com/show_bug.cgi?id=881624 for the last two days, I think that unless we compensate, this change will unfortunately break that *again*, for yet another different reason.
upgrade.img, being a generic initramfs, does not include a vconsole.conf that reflects the configuration of the system being upgraded. Obviously, we can't read vconsole.conf from the installed system before decrypting it if it's encrypted. But fedup uses new-kernel-pkg to set up its grub2.cfg line, so as long as anaconda's writing 'vconsole.keymap' to grub2.cfg (and the user doesn't remove it), fedup's boot entry will get it too. So when we boot to fedup stage2, we do know what the user's chosen layout is (or at least, the one they chose when first installing the system...) because it's on the cmdline. Whew.
Now we're not going to write that any more, though, I think fedup stage2 will have no keyboard layout configuration to read from anywhere.
The only way I can think of to deal with this would be for fedup to somehow get the configuration into the stage2 environment somehow: either modify the initramfs, or read it from vconsole.conf and write it into grub.cfg. But maybe there's a possibility I missed.
As we took this as a blocker for F20, nominating it as an F21 Beta blocker pre-emptively.
well, shoot, I didn't create the F21 blocker trackers yet...
The plan for future fedup stuff is to have a facility for grabbing files from the local system and cramming them into the initramfs before reboot.
This facility would want to do exactly what dracut does when it pulls system files into the initramfs it's building. Which suggests that stuff should be factored out of dracut (or at least made available outside of dracut).
This would also be needed in the case of, say, 3rd party storage modules - you're going to need some way to get your module crammed into the upgrade.img if you want upgrade.img to be able to mount the root device.
Aside about "stage2": Fedup only uses one image, so there's no stage1/stage2 split like anaconda. There *is* a split between:
1) the part that sets up the system ("fedup", "fedup-cli", "download tool")
2) the part that actually does the upgrade ("fedup-dracut", "upgrade.img"),
which (confusingly) has *three* stages:
a) initramfs finds, maybe unlocks, and mounts root
b) inside the root device, we set up all the system's mounts
c) back in initramfs, with the disks all mounted, we run the upgrade
So "stage2" is kind of ambiguous, but I assume you mean 2a) - upgrade.img trying to mount root.
OK. So, do we need an RFE on dracut (probably upstream) to factor that out? Or were you planning on submitting a patch or something?
In the scenario where that doesn't get done in time for F21, can we consider something which checks via localed or reading vconsole.conf what the keyboard layout is, and writing it into the kernel parameters? This shouldn't be too hard, as new-kernel-pkg has a parameter for it: "--kernel-args=args" . So the bare bones would just be to read 'KEYMAP=' out of vconsole.conf or ask localed for the VC keymap (it has a python interface IIRC, or you can grep localectl output, I guess), and pass the value found (if anything) to --kernel-args rd.vconsole.keymap= or --kernel-args vconsole.keymap= in fedup's new-kernel-pkg call, I think.
If there's already a vconsole.keymap parameter in the cmdline...I guess we shouldn't write any additional parameter, to be consistent with what would be the normal case in such a configuration...
On the aside: thanks, I wasn't sure what the terminology was. Indeed, by 'stage2' I meant your '2a)'.
oh, hum, now I look at it, --kernel-args might not be 'add these args' but 'only use these args', which wouldn't be what we want. I see a '--remove-args' but not a '--add-args' or anything. Still, I haven't tested, just reading the manpage.
The dracut package of https://bugzilla.redhat.com/show_bug.cgi?id=881624#c64 _does_ include vconsole.conf in the generic initramfs as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=881624#c60
Not really relevant here. Upgrades use an initramfs built by releng via pungi. It is not built on the host being upgraded. If the upgrade initramfs environment needs to know something about the host configuration, fedup has to provide that information to it somehow, which is what we talked about in c#2.
I believe Michael Catanzaro may be hitting this now: https://bugzilla.redhat.com/show_bug.cgi?id=881624#c71 .
*** Bug 1091615 has been marked as a duplicate of this bug. ***
I can confirm Adam's theory. When booting the "Upgrade System" entry while attempting to upgrade from F20 to rawhide using Fedup, I am able to decrypt my disk if and only if I manually specify vconsole.keymap on the kernel command line.
nominating as an F21 Beta blocker, criterion "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed.", https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Upgrade_requirements
This is a partial violation affecting cases where a storage volume is encrypted using a password that is entered differently on the systemwide configured keyboard layout than it is on the US English layout.
Note the last incarnation of https://bugzilla.redhat.com/show_bug.cgi?id=881624 was accepted as an F20 Final blocker.
So, what file(s) are needed to make this work?
For this particular case, /etc/vconsole.conf . I suppose it's possible the upgrade environment may also benefit from having the correct /etc/locale.conf available, though I can't immediately see how it'd be significant (locale-dependent behaviour in package scripts?)
I can boot my newly-installed F21 as long as I pick my keyboard layout before typing my encryption password... so this seems to have somehow been fixed.
(In reply to Michael Catanzaro from comment #13)
> I can boot my newly-installed F21 as long as I pick my keyboard layout
> before typing my encryption password... so this seems to have somehow been
Ignore me; I wasn't using fedup....
Discussed at 2014-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-03/f21-blocker-review.2014-10-03-15.58.log.txt . Accepted as a blocker as proposed in c#10, though once fedup is fixed for other bugs, we should verify it's broken 'as expected'.
Discussed at 2014-10-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-08/f21-blocker-review.2014-10-08-15.58.log.txt . We're still waiting on fedup fixes to test this one.
This should be fixed by commit c2cc421 in fedup:
Thanks, Will. I'll test it once we have a fix for the udev issue.
fedup-0.9.0-1.fc21 has been submitted as an update for Fedora 21.
fedup-0.9.0-1.fc20 has been submitted as an update for Fedora 20.
fedup-0.9.0-1.fc19 has been submitted as an update for Fedora 19.
This is fixed with fedup-0.9.0-1.fc20.
fedup-0.9.0-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
fedup-0.9.0-2.fc19 has been submitted as an update for Fedora 19.
fedup-0.9.0-2.fc21 has been submitted as an update for Fedora 21.
The update is stable for 19 and 20 already, Will can push it stable for 21 soon enough.
fedup-0.9.0-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
fedup-0.9.0-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.