Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
In either case, I would definitely make sure to have a back up everything else important, especially /home. – supercheetah Jul 1 '13 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 '13 at 18:33
up vote 0 down vote accepted

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-generic

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

share|improve this answer
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 '13 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 '13 at 19:41
Yes this is right, I don't why I have just wrote apt-get install ... Sry. – Diblo Dk Jul 2 '13 at 19:47
FWIW, I ran grub-install without the --recheck option, and that seemed to repopulate the /boot/grub directory with all the grub2 modules, images, and lists. update-grub (called during the kernel reinstall) then added the grub.cfg. The MBR wasn't touched, so I wasn't worried about that. – petiepooo Jul 2 '13 at 19:47
Ooh yes, that's right :) I had forgotten that it is the grub-install that makes the /boot/grub - Thanks :) – Diblo Dk Jul 2 '13 at 19:49

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.

share|improve this answer
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 '13 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 '13 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 '13 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 '13 at 18:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.