Recovering/Restoring Boot Partition

[Chris Murphy]

On Jan 29, 2014, at 12:07 PM, Don Levey <fedora-list at the-leveys.us> wrote:

> On 1/29/2014 13:59, Chris Murphy wrote:
>> 
>> On Jan 29, 2014, at 11:41 AM, Don Levey <fedora-list at the-leveys.us>
>> wrote:
>> 
>>> A short while ago, during a power cut, my desktop machine failed.
>>> A power-up displayed symptoms consistent with a missing /boot
>>> partition; attempting to boot under the rescue CD seemed to confirm
>>> this when it did not mount the /boot partition.
>>> 
>>> ...
>> 
>> I'm wondering why /boot and not rootfs, and why it's not mounting.
>> Normally /boot isn't being written to at all except when kernels are
>> being installed, and /boot on ext4 or XFS should recover with a
>> normal mount at boot without even requiring fsck.
>> 
> Chris, thank you for responding!
> 
> I was wondering something similar; perhaps there is physical damage?

This should give a quick idea:
smartctl -x /dev/sdX

This will take longer but fully reads the entire surface of the drive and some other tests:

smartctl -t long /dev/sdX

I suggest backups before doing this, in case the drive is sorta working but maybe about to die. The idea is to walk away and leave it alone, until at least the time the command suggests has passed. Then run smartctl -x again. Thing is, most of what we're interested in is always being collected. There are only a handful of attributes that aren't updated except during self test.

If you get a command not found, yum install smartmontools. You do not need to do any of this in the chroot, and it doesn't matter if any volumes are mounted or not - but the less the disk is used for other purposes, the faster the self-test will complete.


> One small fact I forgot to mention: this is a dual-boot machine (WinXP).
> The Windows side comes up without a problem.
> 
>> Anyway, if you're for sure convinced it's corrupt then reformat the
>> partition. Use blkid to get the new volume UUID to insert into
>> /etc/fstab so it gets mounted when you next boot. And then mount
>> root, boot, (boot/efi if this is a UEFI machine), and use: mount -B
>> /dev /mnt/dev    #where /mnt is where rootfs is mounted mount -B
>> /proc /mnt/proc mount -B /sys /mnt/sys chroot /mnt yum reinstall
>> kernel     #grubby will probably complain due to lack of grub.cfg 
>> grub2-install /dev/sdX grub2-mkconfig -o /boot/grub2/grub.cfg
>> ...
> 
> I assume I'm reformatting using mkfs; I *think* I understand the rest.

mkfs.ext4


> But now another question arises:
> Since the (previous) /boot partition was fairly small, is there any
> reason not to just abandon it, remove /boot from fstab, and install the
> kernel into the /boot subdirectory of /?

As long as / isn't on LVM or raid5, I usually recommend this anyway. I find separate /boot annoying, and a side effect of boot fragility. For some time now, grub2 can find contents of /boot on pretty much anything: LVM, Btrfs, XFS, raid, LUKS.  But because of bugs and the ease of "cheating" by just using a plain ext4 /boot, the easy path is what's typically done to the degree that now in Fedora 20's installer, /boot can't be on LVM (or Btrfs for that matter).

(Part of the limitations of LVM is that there's a thinp variant, and also it has its own raid0-6 implementation that GRUB2 doesn't support as far as I know. And also LVM working depends on dracut, udev, its own libraries… unlike e.g. Btrfs which is completely implemented in the kernel).


Chris Murphy