Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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)
update-grub

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

https://help.ubuntu.com/community/Grub2/Installing#via_ChRoot
Reinstall latest linux kernel on Ubuntu 10.04

share|improve this answer
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 '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

You must log in to answer this question.

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