I have SMCI servers that have mangled or all-zero UUIDs as well. By "mangled", SMCI has made the extraordinarily poor choice on several of their X10 platforms to set the first 4 fields to 0 and the last 48 bits to the MAC address of one of the on-board ethernet PHYs, in an apparent "good enough" approach to UUID generation at the factory:
[daleg@xenon]~$ smbios | grep -i uuid UUID: 00000000-0000-0000-0000-0cc47a09b5f2 [daleg@xenon]~$ dladm show-phys -m LINK SLOT ADDRESS INUSE CLIENT igb1 primary c:c4:7a:9:b5:f3 no -- igb0 primary c:c4:7a:9:b5:f2 yes igb0 igb3 primary c:c4:7a:9:b5:f5 no -- igb2 primary c:c4:7a:9:b5:f4 no -- [daleg@devohat]~$ smbios | grep -i uuid UUID: 00000000-0000-0000-0000-0cc47a7b58d8 [daleg@devohat]~$ dladm show-phys -m LINK SLOT ADDRESS INUSE CLIENT igb0 primary c:c4:7a:7b:58:d8 yes igb0 igb1 primary c:c4:7a:7b:58:d9 no -- ixgbe0 primary c:c4:7a:7b:5c:be yes ixgbe0 ixgbe1 primary c:c4:7a:7b:5c:bf yes ixgbe1 How widespread this practice is throughout their product line? I'm not sure. It might work from a practical standpoint insofar as it's a UUID that can be used to identify a particular piece of iron, but it does seem extraordinarily sloppy to not bother with filling out the first 80 bits which comprise the first 4 fields, thus reducing a 128bit UUID to a 48bit one. It also means that these really aren't UUIDs in spirit, because one could predict the UUID of a given box based only on observed or even guessed MAC addresses. /dale > On Apr 4, 2017, at 2:01 AM, Jorge Schrauwen <[email protected]> wrote: > > It's usually a bit and miss to be honest. I only have one of the machines I > run smartos on report a UUID that is not all 0. > Most of them are SuperMicro too, I guess it is more of a OEM BIOS verder > specific thing, I think they were all AMI. > > > > > On 2017-04-03 23:42, Robert Mustacchi wrote: >> On 4/3/17 0:22 , 강경원 wrote: >>> Hello. >>> We are testing SDC with same SMBIOS uuid servers. >> We recommend that you talk to your hardware vendor and have them provide >> tooling to fix the server's UUID. If they have the same UUID, they've >> not properly implemented the SMBIOS spec (though it's far from the first >> time we've heard of this). >>> So we tried to modify images's sysinfo script to test and after modifing the >>> sysinfo, the fake uuid can be created successfully and can be setup. >>> But when we try to reboot the node, below error message is shown and >>> rebooting >>> is not working. >>> The only thing that we can do is ipmi power reset. >>> How can we avoid the errors? >>> svc.startd: Killing user processes. >>> WARNING: Error writing ufs log state >>> WARNING: ufs log for /usr changed state to Error >>> WARNING: Please umount(1M) /usr and run fsck(1M) >> Given what little information we have to work on, I'd suggest you >> review >> your procedure for building and modifying the live image for how you >> updated sysinfo to your custom version. Without knowing what you've >> done >> or not done or how you've done it, it's hard to suggest actionable >> steps >> to take. >> Robert > >
signature.asc
Description: Message signed with OpenPGP
------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
