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 up
Duplicate USR-A partition label after 1122.2.0 > 1122.3.0 update #1628
First seen on KVM and reproduced in VirtualBox 5.0.26 r108824
To have the
After updating the
Systemd starts throwing these errors:
Start with a 1122.2.0 system
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.
also on digital ocean:
also on aws:
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.
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 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.