On Mon, 2013-03-18 at 20:01 +0000, Steve McIntyre wrote: > Package: rescue-mode > Version: 1.35 > Severity: important > Tags: d-i > > Hi, > > When debugging and trying to fix an amd64 system installed via UEFI > today, I've found quite a major problem. Since we generated wheezy d-i > RC1, there has been a kernel update which modified symbols *without* > bumping ABI. (To be fair, bumping the ABI would have left a similar > issue anyway.) Using the d-i RC1 netinst and running in rescue mode, > it probes and loads all its hardware support correctly. But: it > doesn't load efivars.ko during early system boot. That's not > *necessarily* an issue, but later on, when wanting to run > grub-installer to re-install the bootloader, it tried to load efivars > then. At that point, the efivars.ko it tried to load was the one from > the installed system; that came from a later kernel version than the > currently-running rescue kernel and it failed to load. > > So: to make sure we don't get this issue in future, we should make > sure that rescue-mode loads the right version of efivars.ko to match > its kernel. I don't personally know how to do that, or I'd have a > patch here already! > > As an aside... do we need to think about this in more general terms > for all amd64 systems and attempt to force-load the efivars module at > early boot? Unlike most other hardware-related modules, it's never > going to trigger on udev...
I'll try to implement auto-loading on x86, and make it built-in on ia64. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
