I accidentally overwrote the /boot filesystem on a running Ubuntu host where the root fs and swap are LVs, and the kernel, initramfs, etc. are under /boot with grub modules and config under /boot/grub.

How would one go about recreating all the files needed to successfully boot?

# mkfs.ext2 /dev/sda1
# mount /dev/sda1 /boot
# apt-get install --reinstall linux-image-`uname -r` linux-image memtest86+
# mkdir /boot/grub
# grub-install /dev/sda

That seems to have recreated most everything, bit is that enough? I don't want to chance a reboot without some assurance it will complete.

For the paranoid, this may also be a way of creating a backup boot partition on a flash drive if, for example, your boot partition isn't mirrored but root is.

  • In either case, I would definitely make sure to have a back up everything else important, especially /home. Jul 1, 2013 at 17:55
  • I haven't rebooted yet, but I think I found one more step: Look up the old UID for /boot in /etc/fstab and set the new fs to it with tune2fs -U <UUID> (or print it with blkid -o value -s UUID /dev/sda1 and edit /etc/fstab). Without that, I suspect it would still boot, but you'd have to mount /boot manually as the UUIDs wouldn't match.
    – petiepooo
    Jul 2, 2013 at 18:33

2 Answers 2


If you have a working system, you can just skip part 1 to 5.

  1. Boot up a Ubuntu live-cd macthing the version you are using.

  2. Mount your normal system partition. X is the drive letter. Y is the partition number:
    sudo mount /dev/sdXY /mnt

  3. Only if you have a separate boot partition (where sdYY is the /boot partition designation):
    sudo mount /dev/sdYY /mnt/boot

  4. Mount the critical virtual filesystems.
    for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done

  5. Chroot into your normal system device:
    sudo chroot /mnt

  6. Reinstall GRUB 2 (substitute the correct device with sda, sdb, etc. Do not specify a partition number):
    grub-install --recheck /dev/sdX

  7. Install ubuntu kernel (Internet is required)
    apt-get install --reinstall linux-image-$(uname -r)

  8. Recreate the GRUB 2 menu file (grub.cfg)

  9. Exit chroot:
    CTRL-D on keyboard
    sudo reboot

Reinstall latest linux kernel on Ubuntu 10.04

  • 1
    As mentioned in the question, I do have a working system, so steps 1-5 weren't necessary. Step 6 would fail, as linux-generic was still installed. The link you gave, while useful, described a situation where linux-generic was uninstalled. Since mine was still installed according to dpkg, but the files were just deleted, I had to give apt-get the --reinstall option for the specific kernels.It looks as if the steps I outlined in my question hit the same points as your answer, except that the grub-install should be before the kernel reinstall (or a separate call to update-grub).
    – petiepooo
    Jul 2, 2013 at 17:54
  • The grub-install --recheck is just to be sur that MBR is in a working condition; I do not think the order matters, it handles only the MBR. update-grub is to rebuild grub.cfg with the "new" kernel. But I'm glad to see that you have got it to work. :)
    – Diblo Dk
    Jul 2, 2013 at 19:41
  • Yes this is right, I don't why I have just wrote apt-get install ... Sry.
    – Diblo Dk
    Jul 2, 2013 at 19:47
  • 1
    I would like to complete Diblo Dk answer; if you have separated /boot partition, you have to change the matching entry in the /etc/fstab before reboot.
    – Leahkim
    Dec 23, 2015 at 7:48
  • 1
    I write this as remainder for my self, that maybe helps others. In my virtual machines the /dev/sdYY points to the efi partition, and /boot is just a normal directory. Remember to sudo mount /dev/sdYY /mnt/boot/efi not /mnt/boot Jul 13, 2023 at 12:37

I suggest using those fine backups you have made and restore them.

If no backups (bad answer)...your easiest route might be a reinstall.

If you have not destroyed the filesystem metadata, even after a reboot you can go in and use a Linux rescue mode boot to get to the information. Your process looks ok but I can provide no guarantees, have you compared the contents of your resulting /boot file with another running system? That might be interesting to be sure you have everything.

  • You missed the point entirely. The goal is to not reinstall. The system is still up and running. Sorry if that was not clear to you.
    – petiepooo
    Jul 2, 2013 at 17:58
  • Apparently not able to reboot....your options are nearly non-existent in fixing a broken running system while it is running. Thus I provided the reasonable and prudent alternative. Personally, I'd not trust a system fixed in such a manner for production purposes.
    – mdpc
    Jul 2, 2013 at 18:04
  • Why not trust it? That's one of the greatest strengths of UNIX and UNIX-like systems such as Linux; it's modularity and robustness. If reinstalling a couple of packages and running a standard update script is enough to restore a specific directory, then I'd say it's proven its production readiness.
    – petiepooo
    Jul 2, 2013 at 18:17
  • the only remaining question is whether or not the initramfs contains everything the original one did. I believe all additions are corralled in a specific directory on the root fs so they can be added when update-initramfs is called, and I see in the logs that was called when I reinstalled the kernel. Ultimately, if it reboots successfully once, I'm guessing there's' no reason to distrust it at all, but I want to have an alternate up and running before I test a reboot.
    – petiepooo
    Jul 2, 2013 at 18:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .