-1

I have a USB thumb-drive where I've installed a Live/Bootable linux system. It works fine! The partitions are:

  • sdb1 (boot) (unknown) 3gb
  • (unallocated 2gb)
  • sdb2 (persistence ext4) 22gb
  • (unallocated 4gb)

I boot with a 2nd thumb-drive so that I'm free to edit my 1st one.

I successfully used gparted to move/resize sdb2. Why can't I do the same for sdb1? I've tried clearing/setting its "boot/hidden" flags. I've tried mounting/unmounting it. But sdb1 never seems to unghost its "move/resize" gparted menu.

(I'm NOT trying to edit the drive I booted with.)

Is there a better way?

  • Do you mean that you can't make sdb1 grow to 5 GB? Or do you mean that once sdb1 has been extended to 5 GB, you don't see any change when you boot? – xhienne Jan 18 '17 at 22:30
  • Are you trying to edit the partition from which you have booted? – DopeGhoti Jan 18 '17 at 22:31
  • The move/resize menu itself is ghosted on sdb1, so I can't even attempt to use it. (Also, I'm NOT trying to edit the drive I booted with.) Does my problem have something to do with gparted calling sdb1 "unknown"? It works fine, but I don't know why it's using some "unknown" filesystem. – Lisa Lisa Jan 19 '17 at 1:42
  • 1
    Can you give us (in the question) the output of fdisk -l /dev/sdb? – xhienne Jan 19 '17 at 2:30
  • You might try sudo blkid /dev/sdb1 to learn the type of file system in the partition. If it isn't one that GParted knows about (see GParted Features then that would explain why the contents of the partition are listed as unknown. – Curtis Gedak Jan 19 '17 at 23:10
1

Possible causes:

  • Missing resize/move utils. gparted needs the correct utility installed before it can resize the file system of /dev/sdb1. If the correct utility is not installed, it won't resize. What the correct utility is depends on the file system. See the "View>File System Support" menu for a table showing what gparted has installed.

  • Containing EBR full. If the partition table on /dev/sdb is an msdos MBR with an extended boot record (say, /dev/sdb3) that contains /dev/sdb1, then the contained partition /dev/sdb1 can be no larger than it's container /dev/sdb3. In which case, enlarging /dev/sdb1 first requires enlarging /dev/sdb3.

  • EBR member mounted. If /dev/sdb1 or any other partition it shares within a containing extended partition is mounted, it can't be resized until it or any other such contained partition is unmounted.

  • Blocked by a bordering EBR. If /dev/sdb1 is not contained in an extended partition, but borders one, (with empty space inside), /dev/sdb1 cannot cross that border. To enlarge /dev/sdb1 would first require shrinking and moving away the bordering extended partition, so that /dev/sdb1 was left with room to grow into.

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.