If I have this correct, openSUSE partitioning is done by parted, weather it is on BIOS and MSDOS or UEFI and GPT.
My question is, Why, when UEFI and GPT are used, queries on the partition table seem to be preferred from gdisk
I noticed on at least one occasion on these forums, gdisk output being specifically requested over parted output, with parted (or its output) referred to as being buggy.
I wonder in what specific way(s) it’s buggy, I,ve seen mention of parted issues here GPT fdisk Tutorial referring to parted up to a certain version number, are those issues still current?
On the openFATE request for gptfdisk I see this comment
YaST2 disk configuration is based on libparted which supports both MBR and GPT. If it fails to correctly partition disk during installation this is a bug which has to be fixed, not worked around by providing low level disk partitioning tool. Do you have bug number?
I’m not suggesting that any bugs in parted are as serious as that, But it would be nice to know what issues currently exist.
It can be said that openSUSE 12.2 does do what is right to install onto a GPT formatted disk on a UEFI enabled PC in efi boot mode from the Hybrid openSUSE DVD. What openSUSE does not allow by its self is real custom partitioning on a GPT disk. While you can add more partitions, trying to say build a dual boot setup with Windows manually, if you knew what to do is just not there. That is why we requested the gptfdisk utility be included so all possible setups could be created if you wanted to do so and knew how to do it. Again, openSUSE does just what is required to boot from a GPT disk automatically when the efi mode is selected, but truly custom partitioning can only be done using the gptfdisk utilities.
Any custom partitioning should be easily achievable through the partitioning tool used by the installer, if that can’t be achieved it should be fixed.
So, that’s one of the reasons I’m interested in where parted falls down.
Can you specify where the openSUSE installer or parted failed to succeed in your situation?
By the way, I make all changes to partitions etc, before install, and probably always will, but the installer should, if it’s going to partition the disk, offer the proper options and do the job correctly.
The specific feature missing is the ability to create a partition type by entering its partition number type in order to create different partitions such as ESP ones. You are of course welcome to create an openFATE on the issue, but using the gptfdisk feature will work for most that have the knowledge to use it while the Partitioner design may prevent those that do not understand from totally messing up their system by creating custom partitions types outside of the standard types we all normally use. I don’t see using two different tools in this case as a big problem as long as its there when you need it.
The specific feature missing is the ability to create a partition type by entering its partition number type in order to create different partitions such as ESP ones.
Is your case unique, is it not likely that others will run into the same problem?
the Partitioner design may prevent those that do not understand from totally messing up their system by creating custom partitions types outside of the standard types we all normally use.
Are we creating a new Ubuntu, with minimal GUI options for users that have minimal thought processing ability? … Ok, perhaps that comment is a touch over the top.
But in what way will creating (in unallocated space) “custom partition types” cause “totally messing up their system”, It may become temporarily unbootable at worst.
I don’t see using two different tools in this case as a big problem as long as its there when you need it.
I also think it’s not, if it only needs to be called on in rare circumstances,
You are of course welcome to create an openFATE on the issue,
I’ll be happy to know what the limitations of parted and the YaST2 partitioner issues are, perhaps something may come up that does warrant an openFATE request.
I just suggest you take a look at the files included with gptfdisk including these terminal based commands:
/usr/sbin/cgdisk
/usr/sbin/gdisk
/usr/sbin/sgdisk
You can compare what they do to what you recall of the openSUSE Partitioner GUI. They can do just about anything but are considerable less user friendly. They would be more attuned to a disk setup that might have disk problems preventing a Desktop GUI from loading as their requirements fit in the normal emergency mode you get when a partition does not load. As GPT disks become more common, ESP creation may even move to some automated method in the Partitioner, who knows where all of that stuff is headed in the future? Since GPT disks can contain many partitions, one might indeed use a 4 TeraByte Hard drive load up and boot from all of your favorite Linux distributions, it is possible.
I just suggest you take a look at the files included with gptfdisk including these terminal based commands:
I have already looked at those commands their abilities, I accept that they are more capable than parted, which is used by the installer.
And hopefully some of the most needed features will eventually be added to parted, for now my Question remains the same, what is considered buggy about parted?
As I have come to understand what is required to install on a GPT disk, I would not refer to it as being buggy, but missing some very basic low level functions required for manual manipulations of a GPT disk for a purpose other than a single boot of openSUSE from that disk. I must also admit I will be more concerned with its operation in our next openSUSE version 12.3 as opposed to going back in time and helping 12.2 any more.
As a general rule, tools based on GNU Parted—and particularly GUI tools such as GParted or the Palimpsest Disk Utility—are the easiest to use; however, GPT fdisk (and particularly gdisk) provides access to more GPT features. Thus, you might want to use GParted or other GUI tools to set up your disks but use GPT fdisk to fine-tune your configuration or repair damage to a GPT disk.
As I have come to understand what is required to install on a GPT disk, I would not refer to it as being buggy, but missing some very basic low level functions required for manual manipulations of a GPT disk for a purpose other than a single boot of openSUSE from that disk.
Ok, not buggy, just inadequate?
. I must also admit I will be more concerned with its operation in our next openSUSE version 12.3 as opposed to going back in time and helping 12.2 any more.
And I thought 12.2 was the current version!
As a general rule, tools based on GNU Parted—and particularly GUI tools such as GParted or the Palimpsest Disk Utility—are the easiest to use; however, GPT fdisk (and particularly gdisk) provides access to more GPT features. Thus, you might want to use GParted or other GUI tools to set up your disks but use GPT fdisk to fine-tune your configuration or repair damage to a GPT disk.
Well, I won’t be arguing with Rod Smith!
So I’m guessing parted output when requested is reliable, not buggy?
I think a UI that new users can understand and use effectively, and that allows them to setup the system as they would like it, is what we would all like to see.
But that, if it happens it will be some time in the future.
Well I guess that (while not a total beginner) I would certainly like a UI to use. The problem I have is that I don’t fully understand the impact of UEFI on OS installations (maybe I’d better get reading).
I have KDE 4.9.5 on my 12.2 desktop box which seems to have come with gptfdisk installed as standard. The only problem is, I can’t get it to run. But in any case, I rely on Parted Magic to set up partitions before I install stuff and haven’t had any problems with openSuSe installations on my UEFI MoBo. While that happy situation obtains, I guess I’ll just mosey along and hope you guys can sort it all out.
