0

When I manage a VPS, I used fdisk to adjust partitions. But when I reboot, the server complained that the block count 2780624 exceeds size of device (2441472 blocks) and entered emergency mode.

I have backed up the partition but the emergency mode did not have a fdisk command for restoring partitions.

Currently, I could either enter the emergency terminal or before it enter the grub terminal via VNC. In the emergency mode, available commands include: /bin commands screenshot, /sbin commands screenshot

It's my first time dealing with such issue, so if you need any further information, I would provide it asap.

Edit:

  • The system is CentOS 7.
  • I have backed up the privious partition. Partition screenshot
  • No tools fdisk, gpart, cfdisk, sfdisk available.
  • What I concern most is retrieving some important data in the disk.

Edit: I found that the server snapshot can be captured and downloaded. Is it easier to restore data locally?

obfish
  • 103
  • 3

3 Answers3

0

Even using fdisk you will need the partition layout that you had before. As you did not specify the linux distribution you use, we can only guess: some possibilities are:

There probably exist others I don't know about. Beside: fdisk usually is in /sbin, so it should be available. Did you check your PATH environment?

And if your VPS provider does not offer a rescue environment with proper tools, you should consider changing the provider ...

VerboEse
  • 11
  • 2
0

Based on the information posted, I can't make up a way forward, in case your problem is really the partition table.

You could bring up network (ip an dhclient are there) but there is no tool to get something from the web or another server.

Still I doubt that fdisk shown on your screenshot is what is saved, as the blocks indicate that sda2 should be within the disk limits (except you shrunk your disk somehow). In order to dig deeper on that it would be helpful to see the dmesg & mount output. Typically / is mounted during initrd stage on /sysroot when CentOS is booting, and with chroot inside the initrd it is often possible to use utilities in the root disk for recovery purposes. Still this way forward, would require beeing able to mount the root partition.

As long as the partition start sectors in the partition table are correct it could be possible.

hargut
  • 3,908
  • 7
  • 10
  • Let me clarify, the fdisk screenshot is the **previous** partition table. I shrinked the size of sda2 and add a new partition sda3 after editing with `fdisk`. However, the system failed weirdly while loading sda2 with error `block count 2780624 exceeds size of device (2441472 blocks)` which is much smaller than the previous working partition blocks. – obfish Aug 10 '18 at 00:43
  • Sounds like you missed to shrink the filesystem as well. Which filesystem are you using on root (sda2)? – hargut Aug 11 '18 at 09:24
  • fixed with fdisk the snapshot locally. Do agree that without handy tools, recovering is really a pain. – obfish Aug 11 '18 at 15:26
0

If it is really important to recover that data, a way forward could also be to use vi as hex editor and fix the partition table with it. This will not be easy, and requires to (fully) understand the binary format of the MBR & its partition table section.

hargut
  • 3,908
  • 7
  • 10
  • Thanks for your suggestion! But is it possible to use vim to edit mbr directly? As I search, some posts use `dd (dd if=/dev/sda of=/mbr bs=512 count=1)` command first then editing the dumped file with vi. What is most annoying is even `dd` command doesn't exist in the emergency system. I do want to give hex editing mbr a try, but could you give some hint where to start from? – obfish Aug 10 '18 at 00:38
  • Try restoring locally from the snapshot you found. I expect that to be easier. The tools needed should be: kpartx and mount. In case the snapshot has the broken partition table you can try to restore it with fdisk or testdisk. – hargut Aug 10 '18 at 03:13
  • No dd is a pain, as directly using vi on the `/dev/sda` will most likely fail. AFAIK vi will try to load the full file, which is hard on a full disk. – hargut Aug 10 '18 at 03:18