Bug 1038413 - fedup stage2 keymap will always be US again for F20-F21 due to anaconda not writing vconsole.keymap kernel parameter any more (#1035316)
Summary: fedup stage2 keymap will always be US again for F20-F21 due to anaconda not w...
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 20
Hardware: All
OS: All
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
: 1091615 (view as bug list)
Depends On:
Blocks: F21BetaBlocker
TreeView+ depends on / blocked
Reported: 2013-12-05 05:14 UTC by Adam Williamson
Modified: 2014-11-10 06:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-11-05 02:31:02 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Williamson 2013-12-05 05:14:28 UTC
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.

Comment 1 Adam Williamson 2013-12-05 05:15:29 UTC
well, shoot, I didn't create the F21 blocker trackers yet...

Comment 2 Will Woods 2013-12-05 18:55:38 UTC
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.

Comment 3 Adam Williamson 2013-12-05 19:13:10 UTC
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)'.

Comment 4 Adam Williamson 2013-12-05 19:14:57 UTC
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.

Comment 5 Harald Hoyer 2013-12-10 12:20:41 UTC
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

Comment 6 Adam Williamson 2013-12-10 16:36:25 UTC
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.

Comment 7 Adam Williamson 2014-04-28 15:00:42 UTC
I believe Michael Catanzaro may be hitting this now: https://bugzilla.redhat.com/show_bug.cgi?id=881624#c71 .

Comment 8 Michael Catanzaro 2014-04-28 22:16:56 UTC
*** Bug 1091615 has been marked as a duplicate of this bug. ***

Comment 9 Michael Catanzaro 2014-05-05 00:56:14 UTC
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.

Comment 10 Adam Williamson 2014-05-05 15:40:10 UTC
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.

Comment 11 Will Woods 2014-05-06 13:57:44 UTC
So, what file(s) are needed to make this work?

Comment 12 Adam Williamson 2014-05-06 15:28:57 UTC
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?)

Comment 13 Michael Catanzaro 2014-09-13 02:40:50 UTC
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.

Comment 14 Michael Catanzaro 2014-09-23 21:02:02 UTC
(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....

Comment 15 Adam Williamson 2014-10-03 16:18:41 UTC
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'.

Comment 16 Adam Williamson 2014-10-08 17:01:36 UTC
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.

Comment 17 Will Woods 2014-10-13 17:50:27 UTC
This should be fixed by commit c2cc421 in fedup: 

Comment 18 Adam Williamson 2014-10-15 21:13:07 UTC
Thanks, Will. I'll test it once we have a fix for the udev issue.

Comment 19 Fedora Update System 2014-10-29 21:10:24 UTC
fedup-0.9.0-1.fc21 has been submitted as an update for Fedora 21.

Comment 20 Fedora Update System 2014-10-29 21:11:40 UTC
fedup-0.9.0-1.fc20 has been submitted as an update for Fedora 20.

Comment 21 Fedora Update System 2014-10-29 21:12:41 UTC
fedup-0.9.0-1.fc19 has been submitted as an update for Fedora 19.

Comment 22 Kamil Páral 2014-10-30 09:08:40 UTC
This is fixed with fedup-0.9.0-1.fc20.

Comment 23 Fedora Update System 2014-11-01 01:40:02 UTC
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.

Comment 24 Fedora Update System 2014-11-03 18:05:32 UTC
fedup-0.9.0-2.fc19 has been submitted as an update for Fedora 19.

Comment 25 Fedora Update System 2014-11-03 18:05:49 UTC
fedup-0.9.0-2.fc21 has been submitted as an update for Fedora 21.

Comment 26 Adam Williamson 2014-11-05 02:31:02 UTC
The update is stable for 19 and 20 already, Will can push it stable for 21 soon enough.

Comment 27 Fedora Update System 2014-11-05 03:57:25 UTC
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.

Comment 28 Fedora Update System 2014-11-10 06:02:48 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.