Bug 1038413
| Summary: | fedup stage2 keymap will always be US again for F20-F21 due to anaconda not writing vconsole.keymap kernel parameter any more (#1035316) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
| Component: | fedup | Assignee: | Will Woods <wwoods> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | germano.massullo, harald, kparal, mcatanzaro+wrong-account-do-not-cc, mfabian, petersen, robatino, tflink, wwoods |
| Target Milestone: | --- | Keywords: | i18n |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | AcceptedBlocker | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-11-05 02:31:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1043124 | ||
|
Description
Adam Williamson
2013-12-05 05:14:28 UTC
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 > fixed. 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: https://github.com/wgwoods/fedup/commit/c2cc421 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. https://admin.fedoraproject.org/updates/fedup-0.9.0-1.fc21 fedup-0.9.0-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedup-0.9.0-1.fc20 fedup-0.9.0-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fedup-0.9.0-1.fc19 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. https://admin.fedoraproject.org/updates/fedup-0.9.0-2.fc19 fedup-0.9.0-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/fedup-0.9.0-2.fc21 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. |