Re: Bug#681227: Can anyone reproduce #681227: installation-reports: grub-install tries to install to a nonsense string?!
retitle 681227 does not validate free-form input
thanks
On Mon, Jan 07, 2013 at 05:54:03PM +0000, Steven Chamberlain wrote:
> Hi Matthew,
>
> On 07/01/13 17:15, Matthew Vernon wrote:
> >>> Jul 10 16:48:43 in-target: grub-common is already the newest version.
> >>> Jul 10 16:48:43 in-target: 0 upgraded, 0 newly installed, 0 to remove
> >>> and 0 not upgraded.
> >>> Jul 11 07:56:28 grub-installer: info: Installing grub on '/dev/sdb
> >>> w33sxs34rfvbg789iokm·']'
>
> > On 02/01/13 22:49, Steven Chamberlain wrote:
> >> To the original submitter of the bug report: do you have a cat?
> >
> > No. The machine is my work desktop. I do have a QWERTY keyboard
> > [...] I don't know how one might
> > have gotten a middot out of it!
>
> I've just learned that at least with my keyboard layout (gb), AltGr +
> period will type the interpunct/middot, in Xorg or from a Linux
> terminal. Those keys are more or less adjacent too.
>
> > That said, I cannot eliminate the
> > possibility that a cleaner was overzealous or similar, but it seems
> > unlikely...?
>
> I'm convinced this is the explanation. The installer was stuck at a
> GRUB prompt for boot devices overnight; then at 07:56 (usually
> 'accurate', but might not be in the local timezone) GRUB proceeded
> trying to install to:
>
> w33 sxs 34rfvbg ... 789iokm ·']
>
> This seems to fit with down/up sweeps across a QWERTY keyboard with
> one's cleaning cloth, proceeding from the left to right (so I would even
> guess that he/she is right-handed...).
>
> [The split on an ergo keyboard would be between the ...vbg and 789...
> sequences of keystrokes, and the closing square bracket is adjacent to
> the carriage return key].
>
> So I think this can be closed.
Almost.
> What to do with the workaround added by Wouter in grub-installer/1.84?
The workaround tried to eliminate the possibility of invalid data coming
from "somewhere" in the installer. I hadn't noticed the long delay in
the log; I had noticed the possibility of invalid input, but didn't
think you'd be silly enough to enter such a long string and not notice.
Of course, if the installer was running overnight, that changes matters.
So what I think needs to be done to fix this properly is to move the
check from where it is located right now to where we do the db_get for
the installer device. If what's been entered by the user doesn't look
like a hard disk device, we should display an error message and allow
the user to try again.
However, given we're this late in the freeze, and given that we've
already got the workaround in place (which should allow a retry by going
through the main menu), I'm not sure it's appropriate anymore to do this
right now.
I'll leave that decision to the d-i RM.
> It did trigger a couple of regressions initially, but those are fixed
> now in Git.
>
> Silently ignoring a failure seems risky when we know that it should not
> happen. (Someone may want to specify multiple targets, and if one of
> them is typo'd it would be silently skipped in this case).
That's indeed the only case that isn't caught by the current code.
Still, first, this is a highly unusual installation type; and second,
even were it to occur, an easy workaround is to use the installer in
rescue mode and fix the boot set-up -- or fix it from the installed
system.
Again, it's not a perfect situation, but I'm not sure this is RC
anymore.
--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.
Reply to: