Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upDuplicate USR-A partition label after 1122.2.0 > 1122.3.0 update #1628
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jumanjiman
Oct 21, 2016
also on digital ocean:
core@coreos-2gb-nyc1-01 ~ $ sudo blkid
/dev/vda9: LABEL="ROOT" UUID="af53899e-c105-4d3b-8df0-e6702ceebf51" TYPE="ext4" PARTLABEL="ROOT" PARTUUID="8ba0b56e-4f8b-4353-92bb-40ebab275dd9"
/dev/vda1: SEC_TYPE="msdos" LABEL="EFI-SYSTEM" UUID="A21F-3BD3" TYPE="vfat" PARTLABEL="EFI-SYSTEM" PARTUUID="2013ab12-720a-4bb3-8964-9371c9120753"
/dev/vda2: PARTLABEL="BIOS-BOOT" PARTUUID="3114d3e7-2546-4705-9a3c-dbd2b84e0376"
/dev/vda3: LABEL="USR-A" UUID="5ee351e8-5b3e-4d88-afef-ab3e7bd9d222" SEC_TYPE="ext2" TYPE="ext4" PARTLABEL="USR-A" PARTUUID="7130c94a-213a-4e5a-8e26-6cce9662f132"
/dev/vda4: LABEL="USR-A" UUID="49f1b399-5af4-4836-8db2-6e112ed28701" SEC_TYPE="ext2" TYPE="ext4" PARTLABEL="USR-B" PARTUUID="e03dd35c-7c2d-4a47-b3fe-27f15780a57c"
/dev/vda6: LABEL="OEM" UUID="698df2df-9d80-4bbf-af46-4926cd4bb7ea" TYPE="ext4" PARTLABEL="OEM" PARTUUID="f1d996f1-3613-46b0-9893-4d2852300b45"
/dev/vda7: PARTLABEL="OEM-CONFIG" PARTUUID="7bb6cc92-64c3-4ee2-b601-ea4f45c80550"
jumanjiman
commented
Oct 21, 2016
|
also on digital ocean: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
takhyon
Oct 21, 2016
also on aws:
core@ip-192-168-254-21 ~ $ sudo blkid
/dev/xvda9: LABEL="ROOT" UUID="42724924-e503-4742-8f51-001657ac8284" UUID_SUB="bc33bdc1-613c-462c-a31c-eb941dfb51fe" TYPE="btrfs" PARTLABEL="ROOT" PARTUUID="34101eb0-e409-49d2-9dbe-92084ff15046"
/dev/xvdb: UUID="8b9157f0-336d-46db-bccf-7a3659d38fb2" SEC_TYPE="ext2" TYPE="ext3"
/dev/xvda1: SEC_TYPE="msdos" LABEL="EFI-SYSTEM" UUID="BDFE-81B5" TYPE="vfat" PARTLABEL="EFI-SYSTEM" PARTUUID="5c878c07-59b6-4d1f-aad1-58f4e4e1db83"
/dev/xvda2: PARTLABEL="BOOT-B" PARTUUID="4080a1e6-2d8b-47bb-b5b9-ede5b5112589"
/dev/xvda3: LABEL="USR-A" UUID="5ee351e8-5b3e-4d88-afef-ab3e7bd9d222" SEC_TYPE="ext2" TYPE="ext4" PARTLABEL="USR-A" PARTUUID="7130c94a-213a-4e5a-8e26-6cce9662f132"
/dev/xvda4: LABEL="USR-A" UUID="49f1b399-5af4-4836-8db2-6e112ed28701" SEC_TYPE="ext2" TYPE="ext4" PARTLABEL="USR-B" PARTUUID="e03dd35c-7c2d-4a47-b3fe-27f15780a57c"
/dev/xvda6: LABEL="OEM" UUID="d16789d6-53e6-4ec5-823b-4683b880bf75" TYPE="ext4" PARTLABEL="OEM" PARTUUID="728d08fb-f273-49a5-a901-a57a46ba99f1"
takhyon
commented
Oct 21, 2016
|
also on aws: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
crawford
Oct 21, 2016
Member
While annoying, this shouldn't lead to any loss in functionality. For what it's worth, my machine has been complaining about the same thing for a while now:
Jul 03 01:56:01 apollo systemd[1]: dev-disk-by\x2dlabel-USR\x2dA.device: Dev dev-disk-by\x2dlabel-USR\x2dA.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:06.0/virtio3/block/vda/vda4 and /sys/devices/pci0000:00/0000:00:06.0/virtio3/block/vda/vda3
Having briefly thought about it, I wouldn't be surprised if this behavior has always been present. We don't do much manipulation to the update payload before it is written to disk. Since we don't know at the time we generate the payload whether it will go into A or B, we can't accurately label the filesystem; so it gets USR-A. The partlabels and partuuids, on the other hand, will be accurate, since they are unaffected by updates.
|
While annoying, this shouldn't lead to any loss in functionality. For what it's worth, my machine has been complaining about the same thing for a while now: Having briefly thought about it, I wouldn't be surprised if this behavior has always been present. We don't do much manipulation to the update payload before it is written to disk. Since we don't know at the time we generate the payload whether it will go into A or B, we can't accurately label the filesystem; so it gets USR-A. The partlabels and partuuids, on the other hand, will be accurate, since they are unaffected by updates. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
crawford
Oct 21, 2016
Member
As I suspected, this has been around for a long time:
$ cat /etc/os-release
NAME=CoreOS
ID=coreos
VERSION=444.5.0
VERSION_ID=444.5.0
BUILD_ID=
PRETTY_NAME="CoreOS 444.5.0"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"
$ sudo blkid
/dev/xvda9: LABEL="ROOT" UUID="c7d88fef-6335-4162-8ddf-7a3513fdeb15" UUID_SUB="e630eab6-7c54-4d18-b139-310a10f9c3e6" TYPE="btrfs" PARTLABEL="ROOT" PARTUUID="d52885de-9f00-4b5f-a30a-4f49160fee39"
/dev/xvda1: SEC_TYPE="msdos" LABEL="EFI-SYSTEM" UUID="631E-274A" TYPE="vfat" PARTLABEL="EFI-SYSTEM" PARTUUID="e5cbfa22-2443-4ad7-afa3-a8f604bdafd7"
/dev/xvda2: PARTLABEL="BOOT-B" PARTUUID="e54b4ce8-4ce5-413d-87dc-a56a0ef44035"
/dev/xvda3: LABEL="USR-A" UUID="f1234c7c-9878-4519-9331-9d8931a0f751" SEC_TYPE="ext2" TYPE="ext4" PARTLABEL="USR-A" PARTUUID="7130c94a-213a-4e5a-8e26-6cce9662f132"
/dev/xvda4: LABEL="USR-A" UUID="4616fbcf-44f2-4104-abac-0241acad152e" SEC_TYPE="ext2" TYPE="ext4" PARTLABEL="USR-B" PARTUUID="e03dd35c-7c2d-4a47-b3fe-27f15780a57c"
/dev/xvda6: LABEL="OEM" UUID="fa264e5a-d571-4139-af7f-b27c5e9805bd" TYPE="ext4" PARTLABEL="OEM" PARTUUID="b788d9a1-0d34-4553-a94f-ea9b68774eac"
/dev/xvda7: PARTLABEL="OEM-CONFIG" PARTUUID="608b2fac-7fcb-43b7-bbad-6a91f60cdcc1"
I suspect it's only now just being noticed because of the warning systemd added to the logs.
|
As I suspected, this has been around for a long time: I suspect it's only now just being noticed because of the warning systemd added to the logs. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marineam
Dec 1, 2016
This is something I broke very early on, originally in ChromeOS the root (our /usr) partition filesystem has no label at all. In rewriting some of that code to adapt from root to our /usr scheme I lost that special case and just let the filesystem always get labeled with the partition label. At the time it didn't raise a warning/error and we always use partition labels, not filesystem labels, so I wasn't concerned about the issue at the time.
marineam
commented
Dec 1, 2016
|
This is something I broke very early on, originally in ChromeOS the root (our /usr) partition filesystem has no label at all. In rewriting some of that code to adapt from root to our /usr scheme I lost that special case and just let the filesystem always get labeled with the partition label. At the time it didn't raise a warning/error and we always use partition labels, not filesystem labels, so I wasn't concerned about the issue at the time. |
johan-adriaans commentedOct 21, 2016
•
edited
Edited 1 time
-
johan-adriaans
edited Oct 21, 2016 (most recent)
Issue Report
Bug
CoreOS Version
Environment
First seen on KVM and reproduced in VirtualBox 5.0.26 r108824
Expected Behavior
To have the
blkidoutput show a USR-A and a USR-B label. Just like thecgpt showoutput.Actual Behavior
After updating the
blkidcommand shows 2 USR-A labels.Systemd starts throwing these errors:
Reproduction Steps
Start with a 1122.2.0 system
Other Information
Note that i have a swap file connected to /dev/loop0
Here is the update log itself
And finally, 2 of my (workers, so np there) servers failed to restart after this automatic update. After a hard system reset they came back up without any abnormal errors: Here is the log for one of them.