How to restore a system after accidentally removing all kernels?

Boot into a live CD (or live USB), mount some systems, chroot into it and install the kernel. After a successful installation of the kernel, unmount the filesystems.

  1. Open Terminal
  2. Mount the Ubuntu partition: sudo mount /dev/sdXY /mnt
  3. Mount some special partitions:

    sudo mount --bind /dev /mnt/dev
    sudo mount --bind /proc /mnt/proc
    sudo mount --bind /sys /mnt/sys
    
  4. (optional) When you are connected to a network, use the DNS servers from your Live environment (otherwise host names can possibly not be resolved):

    cp /etc/resolv.conf /mnt/etc/resolv.conf
    
  5. Chroot into the /mnt: sudo chroot /mnt
  6. Install the Linux kernel: apt-get install linux-image-generic (no sudo required as you are root after a chroot)
  7. After a successful installation of the kernel, get out the chroot and unmount some filesystems:

    exit
    sudo umount /mnt/sys
    sudo umount /mnt/proc
    sudo umount /mnt/dev
    sudo umount /mnt
    
  8. Reboot and remove CD or USB: sudo reboot

This expanded procedure accounts for most of the complications that could occur, including problems connecting to the Internet in the chroot, not knowing which kernel package to install (before Ubuntu 12.10, it will not always be linux-image-generic), not knowing at the outset which partition or even which physical drive contains the / filesystem, and having a separate /boot partition.

I have not written this with reference to any of the other procedures here, though you will notice some similarities. I did base it, loosely, on the procedure here (though those instructions are for something quite different, I have adapted them extensively, and only some commands, not prose, are copied).

You removed all the kernel packages, and Ubuntu cannot boot without a kernel installed. So the solution is to boot from a live CD/DVD/USB, chroot into the installed system, and install a kernel in it.

  1. Boot from an Ubuntu live CD/DVD or live USB flash drive.

  2. Select Try Ubuntu (not Install Ubuntu).

  3. When the desktop comes up, make sure you are connected to the Internet. If you are not, connect to the Internet. One way to see if you are connected to the Internet is to open a web browser. You can even follow the rest of the instructions by bringing this Ask Ubuntu answer up in your web browser, in the live CD/DVD/USB system. I strongly recommend doing that.

  4. Open a Terminal window with Ctrl+Alt+T.

  5. In the Terminal window, run this command to list your partitions:

     sudo parted -l
    

    You'll see something like this (but it won't be exactly like this):

    Model: VMware, VMware Virtual S (scsi)
    Disk /dev/sda: 21.5GB
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    
    Number  Start   End     Size    Type      File system     Flags
     1      1049kB  20.4GB  20.4GB  primary   ext4            boot
     2      20.4GB  21.5GB  1072MB  extended
     5      20.4GB  21.5GB  1072MB  logical   linux-swap(v1)
    
    
    Warning: Unable to open /dev/sr0 read-write (Read-only file system).  /dev/sr0
    has been opened read-only.
    Error: Can't have a partition outside the disk!
    
  6. Examine the output you got, to determine the device name of the partition that contains the / filesystem of the Ubuntu system that is installed on the hard drive (that you are repairing).

    • If you only have one ext4 partition, that's the one.

    • If you have more than one ext4 partition, it's probably the first one. However, if the first one is very small--less than a gigabyte--then that might be a separate /boot partition (remember that one too).

      Please note that whether or not boot is listed under Flags has very little to do with whether or not a partition is a separate /boot partition. My system, whose information is listed above, does not have a separate /boot partition.

    • The device name for the partition starts with the device name for the physical drive, stated immediately after Disk in the second line. Then just add the partition number to the end of that. So, the device name for the partition that contains my / filesystem is /dev/sda1. Here are the two lines where I found that information:

      Disk /dev/sda: 21.5GB
       1      1049kB  20.4GB  20.4GB  primary   ext4            boot
    • If you have more than one physical drive, you'll get more than one listing like what is shown above. But unless you have another Unix-like system installed, you probably will only have one drive that contains ext4 partitions, at least without having created them intentionally on another drive. If you do have multiple drives with ext4 partitions, then the ext4 partition that contains your / filesystem is probably on a drive that also contains a linux-swap partition.

    • It's possible that your Ubuntu system's / filesystem is on a partition of type other than ext4. When this happens, it's almost always ext3, and almost always on a quite old system. It's very uncommon for this to be the case, unless you intentionally set things up this way yourself.

    Remember the device name of the partition that contained your / filesystem (or write it down). If it's different from /dev/sda1, then you'll replace /dev/sda1 with it in the steps below.

    (If it looked like you have a separate /boot partition, remember the device name for that, too.)

  7. Mount the / filesystem to /mnt, and mount its /dev filesystem:

    sudo mount /dev/sda1 /mnt
    sudo mount --bind /dev /mnt/dev
  8. Check if the broken Ubuntu system you're repairing has a separate /boot partition which must be mounted separately. (If you are sure it does not, you can skip this.)

    To check, run:

    ls /mnt/boot
    

    If there is output (like grub memtest86+.bin memtest86+_multiboot.bin, but not necessarily exactly that), then the broken system's /boot is on the same partition as its / and you don't have to mount anything to access it.

    But if there is no output, then you will have to mount the /boot filesystem:

    sudo mount BOOT-PARTITION /mnt/boot

    Replace BOOT-PARTITION with the device name of the /boot partition (see step 6 above).

  9. chroot into the broken system, mount the remaining important virtual filesystems, and set some important environment variables:

    sudo chroot /mnt
    mount -t proc none /proc
    mount -t sysfs none /sys
    mount -t devpts none /dev/pts
    export HOME=/root
    export LC_ALL=C
    
  10. Determine if Internet access works from within the chroot by pinging some reliable host that is known to respond normally to pings:

    ping -c 5 www.google.com
    

    You should see something like this:

    PING www.l.google.com (74.125.131.147) 56(84) bytes of data.
    64 bytes from vc-in-f147.1e100.net (74.125.131.147): icmp_req=1 ttl=44 time=61.3 ms
    64 bytes from vc-in-f147.1e100.net (74.125.131.147): icmp_req=2 ttl=44 time=62.3 ms
    64 bytes from vc-in-f147.1e100.net (74.125.131.147): icmp_req=3 ttl=44 time=61.8 ms
    64 bytes from vc-in-f147.1e100.net (74.125.131.147): icmp_req=4 ttl=44 time=63.8 ms
    64 bytes from vc-in-f147.1e100.net (74.125.131.147): icmp_req=5 ttl=44 time=66.6 ms
    
    --- www.l.google.com ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 4006ms
    rtt min/avg/max/mdev = 61.367/63.212/66.608/1.897 ms
    
    • If it looks mostly like that, and the number before % packet loss is less than 100, then the Internet connection in the chroot is working:

      5 packets transmitted, 5 received, 0% packet loss, time 4006ms

      It's working, so you can skip step 11.

    • If it looks mostly like that, and the number before % packet loss is 100, the connection needs troubleshooting. Make sure the connection on the live CD system (for example, through a web browser, or by running the same command in a separate, non-chrooted Terminal tab/window) works. Make sure you're typing the command correctly. Use www.google.com if you haven't been.

    • If the output doesn't look like the above at all, but instead says ping: unknown host www.google.com, then networking isn't working yet in the chroot.

  11. Set up networking in the chroot. Skip this step unless you got an unknown host error in step 10 above.

    To set up networking, back up the broken system's hosts file, and copy over the live CD system's hosts and resolv.conf files. (You don't have to back up the broken system's version of resolv.conf, as that file is automatically regenerated on-the-fly.)

    Open a new Terminal tab (Ctrl+Shift+T) or, if you prefer, a new Terminal window (Ctrl+Shift+N, or just Ctrl+Alt+T). Run these commands in it:

    sudo cp /mnt/etc/hosts /mnt/etc/hosts.old
    sudo cp /etc/hosts /mnt/etc/hosts
    sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
    exit
    

    (The exit command at the end closes the new tab/window.)

    Repeat step 10 above to make sure Internet access works now from within the chroot. It should.

  12. Figure out which kernel package should be installed. Usually, this will be linux-image-generic. But not always.

    If you're not sure which to install, it will depend partly on which Ubuntu release you have installed, and partly on other information. If you are not sure which Ubuntu release you have installed, find out by running this command (in the chroot, not in a separate Terminal window/tab):

    lsb_release -r
    
    • On Ubuntu 12.10 (the next Ubuntu release, currently in development), it always will be linux-image-generic. (See this, this, and this.)

    • On Ubuntu 12.04 LTS, likely possibilities are linux-image-generic and linux-image-generic-pae. (Unlike previous versions, 12.04 no longer has separate server and desktop kernels.)

      • If the installed Ubuntu system (that you are fixing) is the 64-bit version, use linux-image-generic. (linux-image-generic-pae only applies to 32-bit systems.)

        It's possible to have a 32-bit Ubuntu system installed on a 32-bit or 64-bit computer. Furthermore, you might be using a 32-bit or 64-bit live CD to fix a 32-bit installed system. So if you don't know whether the installed Ubuntu system is 32-bit or 64-bit, check by running this command (in the chroot, not in a separate Terminal window/tab):

        dpkg-architecture -qDEB_HOST_ARCH_BITS
        

        The output will be either 32 or 64.

        (Please note that uname -m is not a correct way to find this information, because even when run in the chroot, that will tell you the architecture of the running kernel, which is the live CD system's kernel and not the installed (broken) system's kernel.)

      • If the installed Ubuntu system (that you are fixing) is the 32-bit version, the best kernel to use will depend on how much RAM you have. I recommend:

        • linux-image-generic if you have less than 3 GB of RAM
        • linux-image-generic-pae if you have 3 GB of RAM or more.

        (This is how Ubuntu's installer chooses which one to set up, ever since the installer gained the ability to install PAE kernels. See the resolution to this bug. If you want to learn what PAE is, see this Wikipedia article. If you want to learn about PAE in Ubuntu, see this Ubuntu wiki page.)

        If you don't know how much RAM you have, run this command to find out:

        grep MemTotal /proc/meminfo
        

        That is listed in kilobytes. To convert to gigabytes, divide by 1,048,576 (10242).

        • 3 gigs = 3,145,728 kB
    • On Ubuntu releases before 12.04, likely possibilities are linux-image-generic, linux-image-generic-pae, and linux-image-server.

      • If you're running an Ubuntu Server system, use linux-image-server.
      • Otherwise, follow the advice above for 12.04 systems.
  13. This is the moment you've been waiting for! Install a kernel in the broken system.

    (Like before, except where explicitly indicated otherwise, these commands are run in the chroot, not in a separate Terminal window/tab.)

    apt-get update
    apt-get -y install linux-image-generic

    Replace linux-image-generic with whatever other kernel package you decided to install in step 12 above, if different.

  14. If you had to perform step 11 to set up networking in the chroot, restore the old hosts file. If you skipped step 11, skip this step too.

    To restore it, run this command:

    cp /etc/hosts.old /etc/hosts
    
  15. Unmount filesystems, exiting out of the chroot:

    umount /proc || umount -lf /proc
    umount /sys /dev/pts
    exit
    sudo umount /mnt/dev /mnt
    
  16. Shut down the live CD/DVD/USB system, removing the live CD/DVD or USB flash drive. Boot into the system installed on the hard drive, that you just repaired. You've installed a kernel package in it (and as part of the installation, the kernel it provides will be added back to the GRUB2 boot menu). If everything worked correctly, your system should boot without problems. (I think it's possible that it will take a little longer to boot than usual, this time.)

DISCLAIMER: I did not test the above procedure on every possible Ubuntu system, so it is possible there is a mistake in it that I have not identified.

In the future, I recommend always trying to keep two kernels installed. It's good to have two in case one of them stops working for any reason (you can select the other in the GRUB2 boot menu). Plus, if you intend to keep two kernels and you accidentally uninstall one more than you meant to and reboot, you still have one left to boot from.

Tags:

Kernel