I do have a hardwarw RAID from Highpoint which allows online expansion of the RAID. I used to have a 3x1TB RAID5 resulting in 2TB net data. This disk did use a traditional MBR partition table.
Prior to expanding the RAID I have converted the partition table to GPT with parted, and then started the expansion with two additional disks resulting to a total of 4GB usable space.
After this operation parted correctly reports the new size (as well as the partitioner in YaST):
parted /dev/sdb
GNU Parted 2.2
Using /dev/sdb
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) p free
Model: Unknown (unknown)
Disk /dev/sdb: 4000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
17.4kB 8258kB 8240kB Free Space
5 8258kB 2000GB 2000GB ext3 Linux/Windows data
2000GB 4000GB 2000GB Free Space
However trying to resize with resize2fs:
resize2fs /dev/sdb5
resize2fs 1.41.11 (14-Mar-2010)
The filesystem is already 488337837 blocks long. Nothing to do!
Found some threads suggesting to rung e2fsck -f on the parition and reboot, but this did not help. I have created a debug version of resize2fs and
found that the call to ioctl BLKGETSIZE64 still returns the old disk size.
Any clues how I could expand the existing partition would be highly apreciated. I am not using LVM and do not want to use it, so expanding by creating a new partition on the remaining space (which works!) and attaching it via LVM is not an option.
“fdisk -l /dev/sdb5” shows nothig at all, which does not surprise me since the disk is using GPT. “fdisk -l” as you suggested shows the partitions of the other, not impacted disk (sda).
as I mentioned, the command you gave me produced no output for sdb, why I tried to specify the device name. However I did retry now and got the expected output. I have no clue why no output was generated on the first atempt for sdb.
So here the output from your command, now with sdb:
# fdisk -l
Disk /dev/sda: 500.0 GB, 500028145664 bytes
255 heads, 63 sectors/track, 60791 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000e04ce
Device Boot Start End Blocks Id System
/dev/sda1 * 2 6528 52428127+ 83 Linux
/dev/sda2 6529 60791 435867547+ f W95 Ext'd (LBA)
/dev/sda5 6529 7572 8385898+ 82 Linux swap / Solaris
/dev/sda6 7573 60791 427481586 83 Linux
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdb: 4000.5 GB, 4000493600768 bytes
255 heads, 63 sectors/track, 486365 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 2 243182 1953351350+ 83 Linux
/dev/sdb2 243183 486366 1953371135+ 83 Linux
/dev/sdb4 1 1 0+ ee GPT
Partition table entries are not in disk order
Well, that is interesting as it shows 2 linux partitions. Note taht at some point I have tried to add a new partition on the new space, delete it and retry the resize. However this partition is definitely deleted by now.
So here the gparted -l in comparison:
#parted -l
Model: Unknown (unknown)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 8225kB 53.7GB 53.7GB primary ext3 boot, type=83
2 53.7GB 500GB 446GB extended lba, type=0f
5 53.7GB 62.3GB 8587MB logical linux-swap(v1) type=82
6 62.3GB 500GB 438GB logical ext3 type=83
Model: Unknown (unknown)
Disk /dev/sdb: 4000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
5 8258kB 2000GB 2000GB ext3 Linux/Windows data
Interesting. I know almost nothing about This Gnu type of partitioning.
IMHO we see here that gparted indeed sees it as partitioned in only one patition (which is numbered 5 ?!) and detects an ext3 fs on it.
But good old fdisk warns us that it sees GPT and that it does not know how to handle, but nevertheless gives us the old partitioning. Now may be we could forget about fdisk because of the GPT, but the fact that fdisk sees the old partitioning may indicate that others also see it and being less sophisticated then fdisk (which at least warns us) just use that as the real partitioning.
But OTH, programs like resize2fs should not be interested in partition tables, they should just use the device special file. And I suppose that when /dev/sdb5 is created by udev, the kernel knows how to manage.
Also I see that (on both disks) fdisks shows that the first partitions starts on address 2 and not as normaly on 1. But the GPT starts on 1. Thus my conclusion would be (being very carefull) that the old partition table says that #5 starts and stops at address 1 and that it contains a GPT, which itsekf says that there is one big partition (there ad=re no addresses in gparted output, but I assume that they will be 2 - 486366).
All just stories, but sometimes contemplating helps.
I read a bit on GPT in GUID Partition Table - Wikipedia, the free encyclopedia. It was a quick glance, but my idea is that the “nornal” partition table should have but one partition (sdb1 in your case) of type 0xEE and it should encompass the hole disk, which is not what you have. Strickt implementation would then protect the disk because it is not sure what is on it.
Maybe you read different, but it is woirthwhile to study it imho.
The partition has n°5 because it was a logical partition before. BTW, I did so many manipulations until now that I think I mixed up the converseion utility. I think I was using gdisk to convert to GPT. The conversion did keep the partition number for compatibility (wehilw I do mount by label anyway).
But good old fdisk warns us that it sees GPT and that it does not know how to handle, but nevertheless gives us the old partitioning.
Well, the partiojning shown is not the old partitioning since it was a logical disk (sda5) and now shows as primary partition. And also the second partition never existed prior to the GPT partition table. So fdisk may siomply be guessing. I will extract the MBR and see if I can find something about the old paritioning
But OTH, programs like resize2fs should not be interested in partition tables, they should just use the device special file. And I suppose that when /dev/sdb5 is created by udev, the kernel knows how to manage.
resize2fs opens /dev/sdb5 and calls ioctl to with function code BLKGETSIZE64, which returns 2GB. But since th eioctl is requested against the partition ot the device I don’t know if 2GB (the partition size) is not simply the expected value here or if it really should return the disk size as resize2fs expects.
I think you posted the above before seeing my other post. The only thing I will remark about the above is that sdb5 would be a primary partition now. When you mean primary partition in the meaning of old partitioning, this can not be true. Primary partitions can only have number 1 - 4 because there only is a two bit field for the number in the partition table. That is the reason why the extended partition and it slogical partitions wre inveneted. The extended allways is a primary (and thus is also in the range 1 - 4) and locical partitions have numbers from 5 upwards (irrespective if all the numbers until 4 are used up)…
As stated in my second above post, imho the old (and still existing) partition table should have but one partition (sdb1) with type ee to satisfy everybody.
Follwing your clue I did change the type of the first partition to ‘ee’ and detele the others including the last GPT one and rebooted the system. Unfortunately now Linux did not recognize the GPT partition table.
Looking at the linux kernel sources I found the ‘gpt’ kernel boot option which prevents the GPT code to check the MBR. Now the system booted. The GPT code checls the MBR to have one GPT partition type (ee) starting at sector 1, which was my trap. As fdisk does not allow to create such a partition I wrote back the previously saved MBR and deleted all partitions but the last one.
Now my fdisk looks like:
Disk /dev/sdb: 4000.5 GB, 4000493600768 bytes
255 heads, 63 sectors/track, 486365 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 1 0+ ee GPT
Not exactely what is specified in the GPT specifications but it is what Linux expects. Also this makes sure that there can be no misinterpretation of the MBR partition table, taking that ione and ignoring the GPT. Since the volume mounts, it must be using the GPT.
However…resize2fs stiil throws the same message at me
Of course there must first be the partition and then you can do something with it like using it for a file sytem. And same for expanding, first a bigger partition, then a increase of the file system size (if the fs type allows that action, which the ext. range does). Or first decrease the file system, then make a smaller partition around it.
First a bigger room, then a bigger carpet!
And in the man page of resize2fs it says:
The size of the filesystem may never be larger than the size of the partition. If size parameter is not specified, it will default to the size of the partition.
And about the partioning. I am not sure that I can understand completely what you write. Also I never used gparted. But imho it mus be psooible to use fdisk to create one partition of type ee using the whole disk. When you say that is not possible and want my opinion then post you fdisk session here.
As said, never used gparted, but it seems unbelievable to me that gparted can not create a GPT with one GPT partition either on the whole disk (thus including the creation of a correct MBR//partition table), or on the prepared ee type partition created above.
I do not quite get the picture. You say you created the partition with parted and then show that, but the QUOTE (not CODE) says that there is a ext3 fs on it. How can that be right after partitioning and before creating an fs?
You say you use gdisk for the backup, but I do not have a gdisk and thus no man page.
I ask because why didn’t you create the new files system (ext3) from the start to fill the partition and then restore the data?
(A subsidary question might be, why ext3 and not ext4 as you are creating a new fs?)
Dirst of, with parted mkpart you can specify teh filesystem, which I did not, so it seems to probe it or default it.
You say you use gdisk for the backup, but I do not have a gdisk and thus no man page.
Reading the remaining of your message, you possibly got this wrong. I used gdisk to backup the GPT, so th epartition table only, as I did not find such a feature in parted.
I ask because why didn’t you create the new files system (ext3) from the start to fill the partition and then restore the data?
Because backing up 1.8TB and restore it takes an awulll lot of time. So I have backed uop the most important stuff only in order to resize the partition.
(A subsidary question might be, why ext3 and not ext4 as you are creating a new fs?)
I am not creating a new fs, just a new partition, required for the resize.
Seems we are talking about different lines here. To make clear what I mean, I will outline below short how I would have done it (a bit theoretical and this is not as you should do it, only for giving you alternative strains of thought).
. Backup all the directories/files (or only the needed ones) to another media (disk, tape, DVD, USB) using tar (I am used to tar and you can compress on the flight, but some forms of cp, or using rsync or using any file backup/restore tool is OK).
. use fdisk to create a new partition table with only one partition (taking all space) and giving it the type ee.
. use whatever you use to create the the GPT partition table (with one GPT partition) on that ee thing.
. use mk2fs to create an ext4 file system on the partition (it will take the whole partition by default).
. restore everything from the backup.
BTW I would never have used a saved GPT partition table. Having problems and thinking that may be due to the fact that either the basic and/or the GPT table are wrong, I would have created everything anew (writing down what I did for future reference).
That is exactely what I wanted to avoid. Taking a full backup and restore it woudl take much to long. So I backed up the vital things and wanted to resize the partition not loosing anything. The backup was only last chance solution as it did not contain all data.
BTW I would never have used a saved GPT partition table. Having problems and thinking that may be due to the fact that either the basic and/or the GPT table are wrong, I would have created everything anew (writing down what I did for future reference).
Well I do not agree with that. At the time of the GPT backup the table was correct and clean toward the specifications. So if ever parted would generate invalid entries in the MBR while editing, editing would not be an option but restoring yes at it does a raw operation. But I never said that this backup was my only source of information Of course I had a copy of the gparted and fdisk information as well. But knowing the GPT code for MBR validation now, generating a protective MBR was not an issue anyway.
Many thanks for pointing me in the right direction. The expansion did complete as well as an additional e2fsck, the new partition with 4TB is mounted and accessible.
I said indeed “Restore everything from the backup.”, but I said earlier: “Backup all the directories/files (or only the needed ones)”. IMHO that means that the backup only contains what you want to restore. But of course when you have a full backup and do not want to restore everything that is a minor change to my scenario. The important thing about my scenario is that I create a complete fresh structure (from basic partitioning to GPT partitioning to file system creation) and then restore whatever. Why should I first create a “small” file system, then restore and then expand???
Nut as long as you are satisfied with what you have now this is all academic.
Of course I had a copy of the gparted and fdisk information as well. But knowing the GPT code for MBR validation now, generating a protective MBR was not an issue anyway.