Re: how to resume GRUB2 upgrade apparently blocked by /boot filesystem type=ext2?

[Tom Roche]

[footnotes follow .sig]

Thanks all for your responses. My problem seems to be solved--I'm now booting 
the newer kernel from the latest package update--but I had some experiences 
that may be of interest to OP.

Tom Roche[3]
>>> summary: a recent package update/upgrade on a Debian box installed 
>>> kernel-related packages (including GRUB packages), then failed to install 
>>> GRUB. How to recover?

>>> details:

>>> As detailed here[1], I have an otherwise-up-to-date Debian box on which I 
>>> unwisely put filesystem type=ext2 on the `/boot` partition:

>>>     $ mount | grep -e '^/dev/'
>>>     /dev/sda3 on /boot type ext2 ...
>>>     ...

>>> That appears to block upgrade of GRUB2: when I recently ran `sudo apt-get 
>>> dist-upgrade`, it successfully installed several kernel-related packages, 
>>> but then

>>>     Setting up grub-common (2.02~beta2-22+deb8u1) ...
>>>     Setting up grub2-common (2.02~beta2-22+deb8u1) ...
>>>     Setting up grub-pc-bin (2.02~beta2-22+deb8u1) ...
>>>     Setting up grub-pc (2.02~beta2-22+deb8u1) ...
>>>     Installing for i386-pc platform.
>>>     Installation finished. No error reported.

Jordan Uggla[4]
>> Note here that grub-install has run correctly once, presumably because "sudo 
>> grub-install /dev/sda" was run, which is correct. Grub's boot sector should 
>> always be installed to the MBR (device /dev/sda) not to any partition (like 
>> /dev/sda3). Because it has run successfully once, you probably will have no 
>> problem booting again

No major/blocking problems, though

1. `fstransform`[2] did not update `/etc/fstab`[5]. (Note this box is pre-{EFI, 
GPT}.) I would have thought that would be more problematic, and I did get 
boottime errors (as noted)), but booted nevertheless.

2. I got an odd message (detailed here[6]) until I ran `sudo dpkg-reconfigure 
grub-pc` (detailed below).

So apparently there is a division of labor between GRUB and `fstab` that I 
don't know about.

>>>     Installing for i386-pc platform.
>>>     grub-install: warning: File system `ext2' doesn't support embedding.
>>>     grub-install: warning: Embedding is not possible.  GRUB can only be 
>>> installed in this setup by using blocklists.  However, blocklists are 
>>> UNRELIABLE and their use is discouraged..

>>> At about this point, my console went to character-mode-graphics to present 
>>> a dialog with title=`Configuring grub-pc` and body telling me that `GRUB 
>>> failed to install`:

>>>     Do you want to continue anyway? If you do, your computer may not start 
>>> up properly.
>>>     Writing GRUB to boot device failed - continue?

>>> I hit button=No. At this point, I have 3 questions based on 2 assumptions. 
>>> The assumptions are

>>> 1. I won't be able to boot my new kernel until I enable whatever does the 
>>> post-package-install actions to complete successfully (and not put up 
>>> another `Configuring grub-pc` dialog).

>>> 2. As part of that enablement, I should first update my {`/dev/sda3`, 
>>> `/boot`} from filesystem type=ext2 to something else.

>> Definitely not.

>> There is no filesystem for which it really makes sense to install grub's 
>> boot sector to a partition,

Just to be clear:

1. I'm quite sure I never told GRUB to do anything non-default. I don't know 
why `grub-install` above wanted to install to {`/dev/sda3`, `/boot`} (though I 
suspect it might have something to do with the OEM Windows install), but I'm 
rather sure I never told `grub-install` to do that.

>> with ext3 and ext4 you will get an identical error.

2. Before I got your reply, I updated {`/dev/sda3`, `/boot`} to ext4 as 
detailed here[7]. Dunno if that made a difference; OTOH I got no embedding 
error when I ran `sudo dpkg-reconfigure grub-pc` (below).

>>> Does that seem reasonable, or am I misunderstanding the situation? 
>>> Presuming my assumptions are correct (and please stop reading now and tell 
>>> me if they are not!), my questions are

>>> 1. To what filesystem type should I update my {`/dev/sda3`, `/boot`}? I'm 
>>> guessing ext4; please let me know if there's a better option.

>>> 2. What's the {easiest, most reliable, least disruptive} way to convert my 
>>> `/boot`'s filesystem, on Debian? `fstransform`[2]?

FWIW, `fstransform` worked well (except for not editing `fstab`[5]) though it 
may not have been necessary.

>>> 3. How to resume the GRUB2 install (after I upgrade `/boot`'s filesystem) 
>>> on Debian? Note that the GRUB2 *packages* (`grub-common`, `grub-pc`, 
>>> `grub-pc-bin`, `grub2-common`) are already installed per both `apt-get` and 
>>> `aptitude`. So is there a way to recreate the package-install 
>>> post-setting-up actions? Or should I remove the packages and reinstall them?

>> What you should do is run "sudo dpkg-reconfigure grub-pc --frontend=text" (I 
>> use --frontend=text here because I find it less confusing that the curses 
>> interface)

Thanks for the tip. I don't find the curses TUI confusing, but I *do* prefer a 
"normal" console interface from which I can scrape text into a file: e.g., 
this[8].

>> and when prompted for install devices choose only "/dev/sda"

That I did[8], and all seems well after rebooting.

Thanks all, Tom Roche <address@hidden>

[1]: http://unix.stackexchange.com/a/259712/38638
[2]: https://packages.debian.org/search?keywords=fstransform
[3]: http://lists.gnu.org/archive/html/help-grub/2016-02/msg00016.html
[4]: http://lists.gnu.org/archive/html/help-grub/2016-02/msg00019.html
[5]: https://github.com/cosmos72/fstransform/issues/5
[6]: https://github.com/cosmos72/fstransform/issues/6
[7]: https://bitbucket.org/snippets/tlroche/eyXRq
[8]: https://bitbucket.org/snippets/tlroche/E8rAx