I was running a long-running partition resize with gparted on my "main" (root? but not boot) partition when something happened. The syslog reports that "gpartedbin invoked oom-killer" (which is strange since I was not running anything except gparted, but anyway...). How do I get my system into a stable state?

Some details:

  • I was (and still am) running Ubuntu 14.04 off a USB drive in order to run gparted at least somewhat safely.
  • However, I normally boot Ubuntu 14.04 from the 'boot' partition of the "main" SSD hard disk.
  • The operation that was interrupted (after running for several hours) was to remove a gibibyte from front of the "main" partition (on the same SSD drive as the normal boot partition and the swap partition).
  • My top priority is to make sure the system is in a stable and consistent state, even when I reboot without the external USB. Second priority is to restore the state of installed drivers (in particular the NVidia driver, which is not the open-source version).
  • I did not create a backup since I don't care about any of the data I have on this computer. But reinstalling pip, numpy, tensorflow, etc. would be a minor hassle.
  • When I run gparted, it appears (so far as I can tell) exactly as before I started the resize/move operation. Here's the output of print in the parted prompt:

    (parted) print                                                            
    Model: ATA PNY CS1311 240GB (scsi)
    Disk /dev/sda: 240GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Number  Start   End     Size    File system     Name  Flags
     1      1049kB  3146kB  2097kB                        bios_grub
     2      3146kB  203MB   200MB   ext4
     3      203MB   10.2GB  10.0GB  linux-swap(v1)
     4      10.2GB  239GB   229GB   ext4
     5      239GB   240GB   1074MB  ext4

The partition I tried to resize was /dev/sda4. * I tried running sudo fdisk -l and it mainly complained that fdisk doesn't support GPT.

I can provide additional information as requested.

How do I proceed?

  • FWIW, I think oom-killer is invoked to kill Out Of Memory processes. You'd almost certainly have saved time by backing up the partition, deleting it, and recreating it with the space before, then restoring -- even had the resize gone correctly. – Zeiss Ikon Jul 31 '17 at 14:19
  • Given that my attempt to back up the disk also caused an OOM after running for several hours, I'm not convinced that would have helped. (I mean, it would have saved me my current dilemma, but it would not have made anything that worked go faster.) – Charles Staats Aug 2 '17 at 2:39

Your best options, in order, are:

  1. Restore data from a backup.
  2. Use fsck on the partition. This is very unlikely to work, but it's much easier than the next option. Note, however, that there's a significant chance that fsck will make matters worse, so if the partition holds important data, I recommend doing a low-level backup (with dd to another physical device) before proceeding with step #3.
  3. Use PhotoRec to try to recover individual files. This is likely to be a long and tedious process and will not recover the system to bootability; you'd use it only to recover your personal data.
  4. Re-install.

Resizing partitions carries a small risk of disastrous consequences. When these operations go bad, they usually go very bad, as you've discovered. Backing up before resizing a partition is advisable.

  • I'd upvote this four times (once for each option) if I could. – Zeiss Ikon Jul 31 '17 at 13:33
  • @ZeissIkon +1 from me so we are on 2 now ;) Except for: "Backing up before resizing a partition is advisable". Backups are not a luxury. I'd say "mandatory and not advisable". – Rinzwind Jul 31 '17 at 13:50
  • So to clarify: Since 1 is not an option, chances are I'll need to reinstall everything to recover the system to bootability? How would I know if fsck happened to work, at least in terms of restoring bootability? (Keeping in mind I would not in any case be booting from the affected partition; it "only" holds the file system.) – Charles Staats Jul 31 '17 at 15:08
  • 2
    How would you know if fsck works? You run it, then you try to boot. (Of course, it might repair the filesystem but leave the system unbootable, in which case Boot Repair might finish the job.) – Rod Smith Aug 1 '17 at 13:04

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.