This question may seem duplicate but as mine, but it isn't. As there is no any error message in my case.

I was searching for how to install Adobe Reader in Ubuntu and I follow the instructions of accepted answer in this question.

It was taking too much time as it was installing so many packages, as (see comments in that answer.). It suddenly shows option of As you are removing phpmyadmin, Do you want to remove your databases too (Not exactly these words). I click on no, and just noticed that it was not only phpmyadmin, but it also removed my php5, pythen, perl and other packages. Then i saw someone's comment that it is actually reinstalling those packages. So I let it complete. After completion, I was not able to start my apache server, as it said that root directory /path/to/root/directory is not exist. I though all would become fixed after I reboot my system. And when I rebooted my Ubuntu, it stuck at boot logo and capslock begin to blink continously. I have luck that I have dual boot and I did my urgent work from windows 10. After little googling I come to know that it is called Kernel Panic when your capslock blinks. I didn't find anything useful regarding this, as in my case it is at boot time. I read this too but in my case it is not showing any error message. It just stuck at boot time.

How can I recover my Ubuntu without losing my data in Ubuntu drive.

I'm using KDE.

  • 1
    The answer to that Adobe question is scary. – Organic Marble Mar 4 '17 at 13:09
  • The question is just about only get Ubuntu back without loosing the data, Kernel Panic is just the reason of issue. @ElderGeek – Siraj Alam Mar 4 '17 at 14:06
  • @OrganicMarble So is there any way to remove it and get back my OS in previous form? – Siraj Alam Mar 4 '17 at 14:06
  • 1
    If I found myself in this situation, I would reinstall the OS, then reload my backups. But there may be a more elegant fix. – Organic Marble Mar 4 '17 at 14:08
  • Kernel panic might have been triggered by a new kernel. How many kernel versions do you have installed now? Can you try an older one? – Andrea Lazzarotto Mar 4 '17 at 23:03

The bad news is that some of your data may already by irretrievably lost. The good news is you may be able to recover some if not all of what remains. It's quite likely that you will have to reinstall your OS and server software however:

The first thing to do is insure that you don't lose any more data by taking a forensic copy of the drive. I described this process in some detail in this answer. By using this method we can work on the forensic copy (whether on a spare drive by mounting the device) or on an image by mounting the image via the loopback device. Then we can take a number of steps to attempt recovery of the missing data ranging from running the appropriate fsck to using other data recovery tools such as testdisk

If the attempt to image results in errors you can try again using ddrescue

If you don't have current backups, I cannot stress the importance of this step enough.

Once we have the copy we begin with an analysis of the layout of the partitions.

I prefer to use either parted or fdisk for this step. I have no doubt that there are other approaches.

sudo fdisk -l DeviceOrFile


sudo parted DeviceOrFile followed by the commands

unit selecting B and then print

will do the trick where DeviceOrFile is the device or image file that contains our forensic image.

The latter will be better if working on a multi-partition image, the first provides enough info for working with a physical drive.

Lets check the file system.

For a device just fsck /dev/sdXy where /dev/sdXy is the device parition whose file system we wish to check.

For an image file we first need to setup the loop device.

$ sudo losetup -o 1048576 /dev/loop0 Stover14.04.img 
$ fsck /dev/loop0

If somehow we've made thing worse we still have the original drive and we can start over, however that's not the expected result.

Our next step will be to mount the partition that contains the (possibly repaired filesystem) data we require. How we go about this depends on whether our copy is on a physical device or contained in an image file.

For a device we mount the partition we want normally although we may wish to include the ro option to avoid inadvertent writes to the device as explained below.

For an image file:

We need to ascertain if we have a loop device available to mount to:

$ sudo losetup -f
[sudo] password for me: 

If for some odd reason we don't have a loop device we need to create one

we will require the numbers obtained with the parted approach mentioned above. Let's say for example we have a partition table like this:

$ sudo parted /dev/sda
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit                                                             
Unit?  [compact]? B                                                       
(parted) print                                                            
Model: ATA TOSHIBA THNSNH12 (scsi)
Disk /dev/sda: 128035676160B
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start         End            Size           Type     File system  Flags
 1      1048576B      13317963775B   13316915200B   primary  ext4
 2      13317963776B  128034963967B  114717000192B  primary  ext4         boot

The number in the start column is important as we will use it in the offset of the following mount command.

You'll note that I've previously created the directory /mnt/boot-sav/sda1 I'll assume you know how to do this or can find that information by consulting man mkdir (hint: -p might be required)

sudo mount -o loop,ro,offset=1048576 Stover14.04.img /mnt/boot-sav/sda1

the -o indicates that options will follow separated by commas. loop indicates that we are mounting to the loop device ro indicates the mount will be read-only to allow us to poke around looking for files without making any changes to the image. the offset parameter indicates the byte position of the beginning of the file system on the partition in question that we are mounting which completes the options I am using.

All this is followed by the name of the image file and the path to mount to.

At this point we can see if we can locate our missing data by perusing from the mount point or utilizing data recovery tools such as testdisk directly on the file system or loop device depending on the tool and your forensic copy approach.





Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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