New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to start "Generate new UUID for disk" after PXE boot with install to disk #1091

Closed
cons0l3 opened this Issue Jan 23, 2016 · 9 comments

Comments

@cons0l3

cons0l3 commented Jan 23, 2016

Dear all,

after sucessfully booting into Coreos (alpha (935.0.0), beta (899.5.0) or stable (835.11.0)) via PXE, I install with coreos-install -d /dev/sda -c local-coreos-config.yml.

The installed OCZ-AGILITY3 SSD gets partitioned into sda1..4, sda6..7 and sda9. Perfect.

During the first initial boot, I receive an
Failed to Generate new UUID for disk... 0-0000-0000-0000-000000001. It does not matter which channel I have used. PXE is not an issue, as the same occurs after booting via USB or CD-ROM.

The boot process finds the devices OCZ-AGILITY3 USR-A and ROOT and successfully checks the file system. It will reach target "Local File Systems". All partitions and file systems have
valid UUIDs. Are the UUIDs generated during startup again?

And from here it goes south and ends up in an emergency shell.

Attached you find the rdsosreport.txt recovered after fumbling around with ways to get it of the system:
rdsosreport.txt

Any hints or ideas are welcome.

Cheers
Carsten

@vcaputo

This comment has been minimized.

vcaputo commented Jan 25, 2016

[    1.607990] localhost kernel: Alternate GPT is invalid, using primary GPT.
[    1.608414] localhost kernel:  sda: sda1 sda2 sda3 sda4 sda6 sda7 sda9
[    1.609278] localhost kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk
[    1.375989] localhost systemd[1]: Found device OCZ-AGILITY3.
[    1.390338] localhost systemd[1]: Starting Generate new UUID for disk GPT dev/disk/by-diskuuid/00000000-0000-0000-0000-000000000001...
[    1.392119] localhost sgdisk[398]: ^GCaution: invalid backup GPT header, but valid main header; regenerating
[    1.392248] localhost sgdisk[398]: backup header from main header.
[    1.392504] localhost sgdisk[398]: Invalid partition data!

hmm, thanks for the report, we'll need to repro this and figure out why sgdisk is getting this error.

@akaihola

This comment has been minimized.

akaihola commented Feb 3, 2016

I'm getting this on a brand new Kingston 240GB SSD after doing coreos-install from an ISO image:

[    3.421678] localhost kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.448017] localhost kernel: ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[    3.448023] localhost kernel: ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[    3.456373] localhost kernel: ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[    3.471146] localhost kernel: ata5.00: ATA-8: KINGSTON SV300S37A240G, 605ABBF2, max UDMA/133
[    3.478444] localhost kernel: ata5.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[    3.491626] localhost kernel: ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[    3.491632] localhost kernel: ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[    3.500008] localhost kernel: ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[    3.514845] localhost kernel: ata5.00: configured for UDMA/133
[    3.519800] localhost kernel: scsi 4:0:0:0: Direct-Access     ATA      KINGSTON SV300S3 BBF2 PQ: 0 ANSI: 5
[    3.532106] localhost kernel: sd 4:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/223 GiB)
[    3.540081] localhost kernel: sd 4:0:0:0: [sda] Write Protect is off
[    3.545317] localhost kernel: sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    3.545335] localhost kernel: sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.555380] localhost kernel: clocksource: Switched to clocksource tsc
[    3.556067] localhost kernel: Alternate GPT is invalid, using primary GPT.
[    3.556075] localhost kernel:  sda: sda1 sda2 sda3 sda4 sda6 sda7 sda9
[    3.556421] localhost kernel: sd 4:0:0:0: [sda] Attached SCSI disk
[    3.274528] localhost systemd[1]: Found device KINGSTON_SV300S37A240G.
[    3.275167] localhost systemd[1]: Starting Generate new UUID for disk GPT dev/disk/by-diskuuid/00000000-0000-0000-0000-000000000001...
[    3.278935] localhost sgdisk[372]: ^GCaution: invalid backup GPT header, but valid main header; regenerating
[    3.279056] localhost sgdisk[372]: backup header from main header.
[    3.282606] localhost sgdisk[372]: Invalid partition data!
[    3.282874] localhost systemd[1]: disk-uuid@dev-disk-by\x2ddiskuuid-00000000\x2d0000\x2d0000\x2d0000\x2d000000000001.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
[    3.282972] localhost systemd[1]: Failed to start Generate new UUID for disk GPT dev/disk/by-diskuuid/00000000-0000-0000-0000-000000000001.
[    3.284190] localhost systemd[1]: Dependency failed for Initrd Default Target.
[    3.284807] localhost systemd[1]: initrd.target: Job initrd.target/start failed with result 'dependency'.
[    3.284910] localhost systemd[1]: initrd.target: Triggering OnFailure= dependencies.
[    3.284942] localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=disk-uuid@dev-disk-by\x2ddiskuuid-00000000\x2d0000\x2d0000\x2d0000\x2d000000000001 comm="systemd" exe="/usr/lib64/systemd/systemd" hostname=? addr=? terminal=? res=failed'
[    3.285048] localhost systemd[1]: disk-uuid@dev-disk-by\x2ddiskuuid-00000000\x2d0000\x2d0000\x2d0000\x2d000000000001.service: Unit entered failed state.
[    3.285138] localhost systemd[1]: disk-uuid@dev-disk-by\x2ddiskuuid-00000000\x2d0000\x2d0000\x2d0000\x2d000000000001.service: Failed with result 'exit-code'.

I tried installs with both stable and beta.

@akaihola

This comment has been minimized.

akaihola commented Feb 3, 2016

I also found the discussion coreos-install: backup gpt table is not at the end of the disk && partitions? in the CoreOS Dev group. It looks like that could be related, since I get the same warning message after installing.

@akaihola

This comment has been minimized.

akaihola commented Feb 3, 2016

I eventually got CoreOS to boot:

  • do a beta install from a USB stick
  • finish installation by running parted once and selecting "Fix"
  • select USR-A instead of default when booting from the hard disk
  • create /usr/share/oem/grub.cfg containing just set default=USR-A to make it the default
@heqian

This comment has been minimized.

heqian commented Feb 12, 2016

I have the same issue with 835.12.0. Previously, I installed a Ubuntu 15.10 on the computer. Does it have anything to with the GPT? I'm not sure.

I fixed it by run parted as suggested by @akaihola and rm all the partitions listed by print. I also erase the MBR and partition table by dd if=/dev/zero of=/dev/sda bs=512 count=1.

@MaksymBilenko

This comment has been minimized.

MaksymBilenko commented Mar 14, 2016

@heqian I had the same issue, But I was installing after Windows 7. Your suggestion fixed issue for me, Thank you!
Maybe make sense to add dd if=/dev/zero of=/dev/sda bs=512 count=1 to the coreos-install script?
Cheers

@jabyrd3

This comment has been minimized.

jabyrd3 commented Mar 20, 2016

parted -> print -> fix -> boot into usr a worked for me. Thanks!

@crawford crawford added this to the CoreOS 1011.0.0 milestone Apr 1, 2016

@crawford crawford self-assigned this Apr 6, 2016

@crawford

This comment has been minimized.

Member

crawford commented Apr 6, 2016

I can repro this in the qemu image with the following:

sudo dd if=/dev/urandom of=/dev/vda bs=512 count=1 seek=$(($(sudo blockdev --getsz /dev/vda) - 1))
sudo sgdisk --disk-guid=R /dev/vda

Despite sgdisk insisting that it's "regenerating backup header from main header", it doesn't actually regenerate the backup header.

@crawford

This comment has been minimized.

Member

crawford commented Apr 6, 2016

Here is a boot with the above patch:

Apr 06 03:04:52 localhost systemd[1]: Found device /dev/disk/by-diskuuid/00000000-0000-0000-0000-000000000001.
Apr 06 03:04:52 localhost systemd[1]: Starting Generate new UUID for disk GPT dev/disk/by-diskuuid/00000000-0000-0000-0000-000000000001...
Apr 06 03:04:52 localhost systemd[1]: Found device /dev/disk/by-label/ROOT.
Apr 06 03:04:52 localhost cgpt[356]: Secondary Header is updated.
...
Apr 06 03:04:53 localhost sgdisk[359]: The operation has completed successfully.

cgpt repairs the secondary header and then lets sgdisk randomize the disk GUID.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment