Details
-
Bug
-
Resolution: Not a Bug
-
Critical
-
None
-
7.6
-
None
-
XSI-282
Description
All the hosts in our pool have an MSDOS style partition on /dev/sda (from factory) with a Dell diagnostics partition on /dev/sda1. We noticed that they all lack /var/log, /boot and swap dedicated partitions.
See output of parted:
Model: ATA TOSHIBA DT01ACA1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 32.3kB 41.1MB 41.1MB primary fat16 diag
3 4336MB 23.7GB 19.3GB primary ext3
2 23.7GB 43.0GB 19.3GB primary ext3 boot
4 44.1GB 1000GB 956GB primary lvm
I have no logs of the initial installation, but I've got those of a fresh reinstallation on one of the hosts. The partition scheme was unchanged by the clean installation.
Here's what seems to be the relevant part in the installation logs (/var/log/installer/install-log):
INFO [2019-02-12 15:53:31] ran ['/sbin/sfdisk', '-LluS', '/dev/sda']; rc 0 STANDARD OUT: Disk /dev/sda: 121601 cylinders, 255 heads, 63 sectors/track Units: sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sda1 63 80324 80262 de Dell Utility /dev/sda2 * 46217669 83966404 37748736 83 Linux /dev/sda3 8468933 46217668 37748736 83 Linux /dev/sda4 86063557 1953520064 1867456508 8e Linux LVM INFO [2019-02-12 15:53:31] ran ['/sbin/sfdisk', '-Ld', '/dev/sda']; rc 0 STANDARD OUT: # partition table of /dev/sda unit: sectors /dev/sda1 : start= 63, size= 80262, Id=de /dev/sda2 : start= 46217669, size= 37748736, Id=83, bootable /dev/sda3 : start= 8468933, size= 37748736, Id=83 /dev/sda4 : start= 86063557, size=1867456508, Id=8e INFO [2019-02-12 15:53:31] Input to sfdisk: unit: sectors /dev/sda1 : start=63, size=80262, Id=de /dev/sda2 : start=46217669, size=37748736, Id=83 /dev/sda3 : start=8468933, size=37748736, Id=83 /dev/sda4 : start=86063557, size=1867456508, Id=8e /dev/sda5 : start=0, size=0, Id=0 /dev/sda6 : start=80325, size=8388608, Id=83 /dev/sda7 : start=83966405, size=2097152, Id=82 INFO [2019-02-12 15:53:31] sfdisk command: /sbin/sfdisk -LuS --no-reread -f /dev/sda INFO [2019-02-12 15:53:31] ran ['/sbin/udevadm', 'settle', '--timeout=30']; rc 0 INFO [2019-02-12 15:53:32] Output from sfdisk: Disk /dev/sda: 121601 cylinders, 255 heads, 63 sectors/track Old situation: Units: sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sda1 63 80324 80262 de Dell Utility /dev/sda2 * 46217669 83966404 37748736 83 Linux /dev/sda3 8468933 46217668 37748736 83 Linux /dev/sda4 86063557 1953520064 1867456508 8e Linux LVM New situation: Units: sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sda1 63 80324 80262 de Dell Utility /dev/sda2 46217669 83966404 37748736 83 Linux /dev/sda3 8468933 46217668 37748736 83 Linux /dev/sda4 86063557 1953520064 1867456508 8e Linux LVM Warning: no primary partition is marked bootable (active) This does not matter for LILO, but the DOS MBR will not boot this disk. Successfully wrote the new partition table Re-reading the partition table ... If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).)
As you can see, the installer intends to add partitions sda5 to sda7, but it looks like it is ignored. It may be because of the definition of sda5:
/dev/sda5 : start=0, size=0, Id=0
I see two problems here:
- The partition creation failure in itself.
- The fact that the installer goes on afterwards as if it were normal. It should check that the new situation is consistent with what was expected.
This bug has also been confirmed by a user of XCP-ng with different hardware (also Dell, though): https://github.com/xcp-ng/xcp/issues/149#issuecomment-468297481