The ones currently still running SmartOS:
- A1SAi-2550F (X10 IIRC) -> gives all 0
- X9DRi-LN4F+ (X9) -> seems to be the mac, never noticed before
[root@core ~]# smbios | grep -i uuid
UUID: 00000000-0000-0000-0000-002590f15506
[root@core ~]# dladm show-phys -m
LINK SLOT ADDRESS INUSE CLIENT
igb0 primary a0:36:9f:6e:ba:6a yes igb0
igb1 primary 0:25:90:f1:55:6 yes trunk0-igb1
igb2 primary 0:25:90:f1:55:6 yes trunk0-igb2
igb3 primary 0:25:90:f1:55:6 yes trunk0-igb3
igb4 primary 0:25:90:f1:55:6 yes trunk0-igb4
---
~ sjorge
On 2017-04-04 08:37, Dale Ghent wrote:
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
-------------------------------------------
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
