When doing my installations I use the expert partitioning option so I can choose
my own partitioning scheme. When setting up the partitions I specify Linux filesystem
(code 8300) or Linux swap (code 8200). For the file systems I’m using XFS or EXT4.
Everything seems straight forward and the installation process goes smoothly. But
when I boot up my new OpenSuse Leap 42.2 installation and look at the partitions
with gdisk or parted they are all of type “Microsoft basic data” (code 0700). I’ve done the
installation on 2 desktop computers using GUID partitons- one with a legacy BIOS and a
BIOS boot partition (code EF02) and the other with a UEFI BIOS and an EFI System
partition (code EF00). The same thing happens on both. The BIOS boot partition and
the EFI system partition show up correctly but the others show up as Windows type
partitions. Why is this happening?
Question: do the systems run OK? They would definitely not from MS filesystems.
Can you show the output here?
Are you sure ( using gdisk is for GPT partitioned disks ) the legacy BIOS system doesn’t have MBR partitioning, so needs usage of fdisk instead of gdisk.
So, please show:
sudo fdisk -l
Confusion here.
He is not talking about MS filesystems, but about the partition type in the partition table.
In a MBR partition table, the installer uses x’82’ (for swap) and x’83’ (for file systems).
In GPT the installer uses x’0700’ for both. That is explained as ‘Microsoft basic data’ by fdisk and as ‘primary’ by gdisk.
When asking gdisk for the list of partition types, that list has amongst others:
x’8200’ Linux swap
x’8300’ Linux filesystem
Like the OP I wondered why these two are not used.
As a general rule (from MBR times) I always explained that “it is only a byte of data and does not really do much by itself”, but I always added “there are programs/applications that do use them so you better set them as correct as you can”. That is obviously not the case here.
So for the primary question:
Why is this happening?
I have no answer, but I am curious.
In any case, like Knurpht says, this seems to be the case on all openSUSE installations on GPT disks and does not seem to have negative effects at all.
Both of these installations have worked well from the beginning. I have since gone
into the installation with the UEFI bios and the EFI system partition and used gdisk
to change all the 0700 partitions to the appropriate Linux type (8200, 8300 and 8302)
and have incurred no problems doing so.
hcv - If I understand you correctly you seem to be saying there is nothing I could have
done differently in the installations to get 8200 and 8300 type partitions. This is just the
way Leap 42.2 does things. So everything I’ve done so far appears to be the correct
procedure: If choosing the expert (do your own thing) partitioning option, specify the sizes,
mount points, type code and file system types. Accept the 0700 type codes it forces upon
you. Then after starting up the new installation use a tool like gdisk to change the partition
codes to the desired values.
Any comments?
Another option: The installation DVD has an option for “Rescuing a Linux system”. I f you
start this up you get a shell prompt which gives you access to gdisk and parted. At this point
you should be able to create the desired partitions before doing the actual installation.
GPT partitioning allows for descriptive partition names (gdisk c: change name). e.g.:
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 625142448 sectors, 298.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5A35...
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 625142414
Partitions will be aligned on 2048-sector boundaries
Total free space is 510208621 sectors (243.3 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 657407 320.0 MiB EF00 gb32 EFI System (ESP)
2 657408 5375999 2.3 GiB 8200 gb32 P02 Swapper
3 5376000 10078207 2.2 GiB 8300 gb32 P03 /usr/local
4 10078208 23185407 6.3 GiB 8300 gb32 P04 /home
5 23185408 55953407 15.6 GiB 8300 gb32 P05 /pub
6 55953408 70699007 7.0 GiB 8300 gb32 osTW P06
7 70699008 85444607 7.0 GiB 8300 gb32 os150 P07
8 85444608 100190207 7.0 GiB 8300 gb32 Debian Linux 9...
9 100190208 114935807 7.0 GiB 8300 gb32 os423 P09
What I wanted to say:
- that I experienced that the installer makes them 0700, but I did not try vehemently (like you seem to have done) to set them “correct”;
- as almost nobody of the population here (and those that use openSUSE, but are not members here) even knows these fields exist in partitioning, let alone what value they should have, I assume that 0700 is used all over the installations without any negative effects reported here;
- that I was also a bit confused, but did not follow on my confusion with any action;
- the only way I know to get further information about why this was chosen is creating a bug report, with will be a bit strange, because we have no real problems to report.
In the meantime you report that forcefully setting the correct values does not seem to have any negative consequences. But I doubt many will follow you when they experience no problems that can be corrected with this.
So, what do you think? Should we try to walk the way of a bug report? It might be both an interesting and/or frustrating experience . 
Interesting for those that want to manage their system with more detail, but it was not the question. The question is why the installer does not set the (what we think) correct values in GPT where it did so already for years (at least more then 10), and still does, in MBR partitioning.
My belief is that a secondary question was implied by the OP’s frustration, and also that it might be worth a FATE to allow GPT names to be set from the YaST2 partitioner. Note that the type codes displayed in my previous post are a consequence of having partitioned in advance using a non-FOSS tool that was explicitly directed to set the indicated types. The names shown were applied using the same tool only after having installed TW.
Rather than filing a bug that might prove frustrating, it might be worth simply asking Josef Reidinger and/or the yast2-devel mailing list about native partitions acquiring type 0700 during YaST2 partitioning.
Well, I won’t stop you. Sounds like an interesting extension of YaST’s partition features.