http://bugzilla.suse.com/show_bug.cgi?id=984302
http://bugzilla.suse.com/show_bug.cgi?id=984302#c13
--- Comment #13 from Stefan Hundhammer ---
OK, that really appear to be the correct logs.
Those logs show the previous disk layout.
The "blkid" output we collected here (reformatted for better readability)
reads:
2016-07-01 10:04:20 <1> (none)(2994) [libstorage] SystemCmd.cc(execute):134
SystemCmd Executing:
"BLKID_SKIP_CHECK_MDRAID=1 /sbin/blkid -c /dev/null"
/dev/sda1: LABEL="EFI"
UUID="70D6-1701"
TYPE="vfat"
PARTLABEL="EFI System Partition"
PARTUUID="9b7a0c4a-87ee-427a-8ef3-2a4dbde4361c"
/dev/sda2: LABEL="mac"
UUID="ee8eda53-731d-31c1-aeab-ae7e62faaeca"
TYPE="hfsplus"
PARTLABEL="mac"
PARTUUID="35885ccf-aa7c-4471-8646-5e130fedd072"
/dev/sda3: PARTLABEL="WIN"
PARTUUID="51ee0ed6-8691-45a3-a938-a9915781a3de"
/dev/sda4: LABEL="Untitled 3"
TYPE="ext4"
UUID="9674aa17-2229-42bc-84e5-19496a524cc8"
PARTLABEL="Untitled 3"
PARTUUID="070509e1-97db-4335-a069-bd7a5a0a3618"
Notice that /dev/sda3 which seemed to contain Windows before the Linux
installation only has "PARTLABEL" and "PARTUUID" set, no TYPE, no LABEL, no
UUID.
In the disk_sda.info the section about /dev/sda3 looks like this:
<partition>
<name>sda3</name>
<device>/dev/sda3</device>
215536640
<major>8</major>
<minor>3</minor>
<numeric>true</numeric>
<number>3</number>
<region>
<start>15931</start>
<length>26835</length>
</region>
primary
131
</partition>
In contrast, /dev/sda2, the Mac partition, looks like this:
<partition>
<name>sda2</name>
<device>/dev/sda2</device>
127636720
<major>8</major>
<minor>2</minor>
<numeric>true</numeric>
<number>2</number>
hfsplus
ee8eda53-731d-31c1-aeab-ae7e62faaeca
mac
uuid
<region>
<start>25</start>
<length>15891</length>
</region>
primary
258
</partition>
Notice the "partition_id" 131 (0x83) for /dev/sda3 which is "Linux native".
Again, /dev/sda3 does not have "fs_type" (filesystem type), "fs_label" or
"fs_uuid" - which means that no filesystem was detected on that partition. This
might have to do with the partition ID 0x83.
The problem with this is that GPT disks don't use those partition IDs like
0x83; rather, they use long hex IDs that are much more unique:
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
But "parted" translates those to the old-style partition IDs known from MS-DOS
type disks.
A Linux partition reported as 0x83 (131) might be any of those:
- Linux filesystem data 0FC63DAF-8483-4772-8E79-3D69D8477DE4
- RAID partition A19D880F-05FC-4D3B-A006-743F0F84911E
- Root partition (x86) 44479540-F297-41B2-9AF7-D131D5F0458A
- Root partition (x86-64) 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709
- Root partition (32-bit ARM) 69DAD710-2CE4-4E3C-B16C-21A1D49ABED3
- Root partition (64-bit) B921B045-1DF0-41C3-AF44-4C6F280D3FAE
- LVM partition E6D6D379-F507-44C2-A23C-238F2A3DF928
- /home partition 933AC7E1-2EB4-4F13-B844-0E14E2AEF915
- /srv partition 3B8F8425-20E0-4F3B-907F-1A25A76F98E8
- Reserved 8DA63339-0007-60C0-C436-083AC8230908
So even the starting scenario is somewhat suspicious; something seems to be
wrong here.
For a Windows partition, the tool creating it should have used any of those:
- Microsoft Reserved Partition E3C9E316-0B5C-4DB8-817D-F92DF00215AE
- Basic data partition EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
- LDM meta data partition 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3
- LDM data partition AF9B60A0-1431-4F62-BC68-3311714A69AD
- Windows Recovery Environment DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
- IBM GPFS partition 37AFFC90-EF7D-4E96-91C3-2D7AE055B174
- Storage Spaces partition E75CAF8F-F680-4CEE-AFA3-B001E56EFC2D
But "parted" detected that partition as something Linux-like, so it appears it
detected any of the Linux partition IDs predefined by the GPT standard. But
since "parted" does not show those long IDs, we can only guess.
BTW those IDs are unrelated to the PARTITION_IDs reported by "blkid".
--
You are receiving this mail because:
You are on the CC list for the bug.