2

I am on grub rescue mode, and the avalible command just ls, the search, search.file not there.

I already found my partition which use ext2, that is hd0 msdos6.

When i do ls, it consist of tmp/ root/ var/ dev/ proc/ run/ sys/

What we are looking to normal boot is root also boot right?

But where is the boot/ ? I don't even know why the grub is broken right now.

I am already aware that it can be fixed by another linux like boot seq dick , but i am hesitant to do that. Because i need to borrow someone pc to install it on a thumb drive first.

2 Answers 2

1

Yes you need to rely on iso-tools like boot repair disk.

And i recommend use rufus over unetbootin in this case.

Just to prevent additional annoyance.

Specific if you had dual boot, the tools might restore the windows ( if any) over linux.

To prevent that you can click the advanced optios then mbr options tab. Then select the proper partition you want. Selection wrong partition also cause a boot failure. So please becareful.

You can utilize the ship-in gparted to help you find correct partition

1

When i do ls, it consist of tmp/ root/ var/ dev/ proc/ run/ sys/

This indeed looks like a root filesystem, but:

  • /bin should be a directory on the root filesystem (or a symlink to /usr/bin in some new distributions) but it's missing
  • there should be /boot either as a mount point for the /boot filesystem or just as a regular directory, but it's missing
  • /dev is a mount point for the RAM-based /dev filesystem, it's there
  • /etc should always be a directory on the root filesystem, it's missing
  • if there is not a separate /home partition, then /home should also be a regular directory; also missing
  • /lib should be similar to /bin, also missing
  • /media and /mnt should be basically empty directories to be used as mount points for removable media and sysadmin operations, these are missing
  • /proc is a mount point for /proc virtual filesystem, it's there
  • /root is there
  • /run is a mount point for a RAM-based tmpfs dedicated for PID files and other run-time state, it's there
  • /sbin should be similar to /bin, it's missing
  • /sys is a mount point for the sysfs virtual filesystem, it's there
  • /tmp is often a mount point for a RAM-based tmpfs
  • /usr should in modern systems be a regular directory on the root filesystem, but it's missing
  • /var might be a regular directory or a mount point, it's there

Uh Oh... this looks like a result of sudo rm -rf / or similar. If that's true, then a missing i386-pc/normal.mod is going to be the least of your worries.

Most of the things that are still there on your root partition are directories that are used as mount points for other filesystems when the system is normally running. The few remaining normal directories are all towards the end of the alphabetic sorting order.

Active mount points cannot be removed by rm -rf without unmounting them first, which might explain most of the directories that are still there.

The others (basically just /root and /var) might have been saved just by pure luck: the system may have crashed as essential system libraries in /lib and /usr/lib (and/or the rm command itself) were deleted, before the deletion of /root and /var had time to complete.

I'm sorry to say that this looks like a system that is somewhere between "severely damaged" and "completely destroyed", assuming that you've identified the partition correctly.

You might want to boot from a live Linux media and mount all the partitions (read-only at first!) to see if any important files have been spared from destruction. and recover everything you can to a different disk. If you want to try and recover deleted files, do not write anything to this partition and do not run fsck until you've exhausted all recovery possibilities (including, but not limited to scanning the partition contents with PhotoRec) and are ready to give up hope of rescuing any further data.

1

You must log in to answer this question.

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