> On Apr 3, 2017, at 11:37 PM, Dale Ghent <[email protected]> wrote: > > > I have SMCI servers that have mangled or all-zero UUIDs as well.
very common with supermicro gear. You'll also see an occasional bogus 00010002-0003-0004-0005-000600070008. The sysinfo code in kernel recognizes some of these as bogus and uses a random number for hostid that is then stored in /etc. For smartos that method doesn't work, for obvious reasons. A few lives back we changed this, but that code isn't a general purpose solution. It should be easy enough to make a more general solution for modern SmartOS -- richard > > 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 >> >> > > ------------------------------------------- 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
