On Linux I can get UUID are stored in some files on system (in example /var/lib/dbus/machine-id, /proc/sys/kernel/random/uuid, /proc/sys/kernel/random/boot_id), can I find similar files on OS X?
You can use uuidgen:
/usr/bin/uuidgen
$ uuidgen
6A786B80-8D52-4344-93D1-37C95F6C803A
Your question seems somewhat confused...
If you want to generate a unique UUID for some reason, use #ergonaut's answer:
uuidgen
70095BA9-B866-42F2-9DE4-606F54EBBA88
If you want to get a unique identifier for a particular CPU/machine, you can use the system_profiler like this:
system_profiler SPHardwareDataType
Output
Hardware:
Hardware Overview:
Model Name: iMac
Model Identifier: iMac12,2
Processor Name: Intel Core i7
Processor Speed: 3.4 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 8 MB
Memory: 16 GB
Boot ROM Version: IM121.0047.B21
SMC Version (system): 1.72f2
Serial Number (system): DGKH80PXDHJW
Hardware UUID: 1025AC04-9F9E-5342-9EF4-206EBAE40BF6
Or, if you want to select one of those values specifically, you can use:
system_profiler SPHardwareDataType | awk '/UUID/ { print $3; }'
1025AC04-9F9E-5342-9EF4-206EBAE40BF6
Or, you can use the MAC address of your primary Ethernet interface like this:
ifconfig en0 | awk '/ether/{print $2}'
3c:07:54:76:38:cd
Related
Is there a way through command line to know what keyboard physical layout a macbook has? I cannot find that specific information in system_profiler. I want to know if the computer has a US, UK, ES, etc keyboard layout.
The aim is to script it, upload it to my MDM so I can run it in all the company's laptops and find out that information.
Thanks!
running the terminal command system_profiler SPSPIDataType
it shows this:
SPI:
Apple Internal Keyboard / Trackpad:
Product ID: 0x0278
Vendor ID: 0x05ac (Apple Inc.)
ST Version: 8.96
MT Version: 4.69
Serial Number: FM7741701QVGN41A5+RNZ
Manufacturer: Apple Inc.
Location ID: 0x01000000
I run it in two different macbooks, one UK, one ES. I was hoping that the Location ID would show something different but that was not the case.
If I do this in Terminal:
defaults read ~/Library/Preferences/com.apple.HIToolbox.plist AppleSelectedInputSources | egrep -w 'KeyboardLayout Name'
I get this:
"KeyboardLayout Name" = *name of my keyboard in readable form*
I think I just found the solution, like this:
ioreg -l | grep KeyboardLanguage | awk '{print substr( $0, 56, 20)}' | tr -d "\" =|"
Thanks,
Federico.
I'm new to the omnisci open source community. I have followed the instruction (https://www.omnisci.com/docs/latest/4_ubuntu-apt-gpu-os-recipe.html) to install the omnisci (open source version) into my ubuntu 18.04LTS
~$ sudo systemctl start omnisci_server
~$ $OMNISCI_PATH/bin/omnisql
Password:
User mapd connected to database maps
omnisql>
I have also install the CUDA driver 10.0
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 415.27 Driver Version: 415.27 CUDA Version: 10.0 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
|
0 TITAN V Off | 00000000:17:00.0 Off | N/A |
| 33% 48C P8 30W / 250W | 421MiB / 12036MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
|
1 GeForce GTX 108... Off | 00000000:65:00.0 Off | N/A |
| 30% 53C P8 20W / 250W | 172MiB / 11178MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
|
2 GeForce GTX 108... Off | 00000000:66:00.0 On | N/A |
| 63% 81C P0 70W / 250W | 829MiB / 11175MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
However, when I run the simple query on the sample dataset, it reports the error:
omnisql> \t
omnisci_states
omnisci_counties
omnisci_countries
nyc_trees_2015_683k
omnisql> select * from omnisci_counties;
Exception: device kernel image is invalid
My friend and I had a discussion on this issue. We believe this is because I have 2 different types GPUs on my machine. I need to specify one type of GPUs when start the omnisql sever, because the query engine of omnisci will confuse to initialize the parameters for two different types of cards on board.
Does anyone have any idea or suggestion?
I just found out by myself. The GPU devices for omnisci sever have to be consistent. You could use multiple cards, but they have to be same type.
For instance, in my case, set up the parameters in omnisci.conf
port = 6274
http-port = 6278
calcite-port = 6279
data = "/var/lib/omnisci/data"
null-div-by-zero = true
num-gpus = 2
start-gpu = 1
When use $sudo systemctl start omnisci_server to start the server, the file omnisci.conf will be automatically loaded.
When using multiple GPUs, they need to be the same model. Per the OmniSci FAQ:
https://www.omnisci.com/docs/latest/7_faq.html#multi-gpus
Does OmniSci support a single server with different GPUs? For example,
can I install OmniSci on one server with two NVIDIA GTX 760 GPUs and
two NVIDIA GTX TITAN GPUs?
OmniSci does not support mixing different
GPU models. Initially, you might not notice many issues with that
configuration because the GPUs are the same generation. However, in
this case you should consider removing the GTX 760 GPUs, or configure
OmniSci to not use them.
To configure OmniSci to use specific GPUs:
Run the nvidia-smi command to see the GPU IDs of the GTX 760s. Most
likely, the GPUs are grouped together by type. Edit the omnisci_server
config file as follows: If the GTX 760 GPUs are 0,1, configure
omnisci_server with the option start-gpu=2 to use the remaining two
TITAN GPUs. If the GTX 760s are 2,3, add the option num-gpus=2 to the
config file. The location of the config file depends on how you
installed OmniSci.
I want to collect only MAC addresses from arp-scan -l, omitting IP addresses and the devices name. How do we do it? I know that these in the middle column are all MAC addresses.
192.168.1.1 bc:98:89:47:20:f8 Fiberhome Telecommunication Technologies Co.,LTD
192.168.1.3 70:18:8b:5e:01:fd Hon Hai Precision Ind. Co.,Ltd.
192.168.1.5 90:e7:c4:da:80:76 HTC Corporation
192.168.1.6 b8:27:eb:b0:4d:25 Raspberry Pi Foundation
I want like this
bc:98:89:47:20:f8
70:18:8b:5e:01:fd
90:e7:c4:da:80:76
b8:27:eb:b0:4d:25
Edit:
arp-scan -l gives the following result
Interface: wlp5s0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.1.1 bc:98:89:47:20:f8 Fiberhome Telecommunication Technologies Co.,LTD
192.168.1.5 90:e7:c4:da:80:76 HTC Corporation
192.168.1.3 70:18:8b:5e:01:fd Hon Hai Precision Ind. Co.,Ltd.
192.168.1.5 90:e7:c4:da:80:76 HTC Corporation (DUP: 2)
192.168.1.6 b8:27:eb:b0:4d:25 Raspberry Pi Foundation
192.168.1.6 b8:27:eb:b0:4d:25 Raspberry Pi Foundation (DUP: 2)
192.168.1.4 80:35:c1:4a:a5:dc (Unknown)
9 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.5: 256 hosts scanned in 3.017 seconds (84.85 hosts/sec). 7 responded
I am assuming that you are using a linux-like shell and awk utility is installed( it is mostly pre-installed )-
arp-scan -l | awk '/.*:.*:.*:.*:.*:.*/{print $2}'
Learn basic Unix shell!
In particular the cut command can be used to extract columns from text. Set the field separator to space (probably default) and select the second field.
Using --plain option of arp-scan can make things easier. It will display plain output showing only responding hosts. The hosts' information are separated by tab, MAC address (2nd column) can be extracted easily through cut, as Anony-Mousse described:
arp-scan -l --plain | cut -f 2
Does anyone know of a way to get U-boot version installed from userspace? There is the fw_printenv command that provides access to U-boot's environment variables, but not the version.
If U-boot is located in mtd0, you can get version info as follows:
root#SUPERWIFI:/proc# strings /dev/mtd0 | grep U-Boot
U-Boot 1.1.4-g1c8343c8-dirty (Feb 28 2014 - 13:56:54)
U-Boot
Now running in RAM - U-Boot at: %08lx
Just an update for this.
In our version of U-Boot we changed the code for main_loop() in main.c to this:
#ifdef CONFIG_VERSION_VARIABLE
char *oldver=getenv("ver");
if(oldver==0 ||strcmp(oldver,version_string))
{
setenv("ver", version_string); /* set version variable */
saveenv();
}
#endif /* CONFIG_VERSION_VARIABLE */
So setenv/saveenv is only called, if needed by an update.
In our firmware we added
/sbin/fw_printenv -n ver > /var/config/u-boot.ver
to make the u-boot version public available.
There's no defined way to do this. Once Linux boots, u-boot is no longer running and it's RAM is reclaimed for Linux's use. Linux doesn't even know about u-boot. Nor does it have to have been booted by u-boot.
If you really want to do this, the only way to do it is to add the u-boot version to the kernel's command line, write code to scan the u-boot image in flash for it's version, or something even nastier.
An alternative solution is to read the version directly from the u-boot binary file (can be even embedded in an image file containing other binaries as well like e.g. the first stage bootloader) with e.g. mmcblk0boot0 as partition (of device mmcblk0) the bootloader resides in:
sudo grep -a --null-data U-Boot /dev/mmcblk0boot0
Site note: Does work not only for Arch Linux but e.g. Ubuntu as well.
In my devices UBoot automatically creates a "ver" environment variable containing its version:
U-Boot > printenv
baudrate=115200
ethact=FEC ETHERNET
ethaddr=24-db-ad-00-00-08
bootdelay=3
bootcmd=bootm fc080000 - fc060000
bootargs=console=ttyCPM0,115200n8 rdinit=/sbin/init
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.03-svn9684 (Mar 08 2010 - 17:08:32)
Environment size: 253/131068 bytes
U-Boot >
I don't use fw_printenv, but I would imagine that this variable gets passed along as well. Maybe you already have something similar in your system?
UPDATE (5/23/2012):
I added fw_printenv to my linux image and can confirm that I do see the "ver" variable:
[root#ST600 /]# fw_printenv
baudrate=115200
ethact=FEC ETHERNET
ethaddr=24-db-ad-00-00-08
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.03-svn9684 (Mar 11 2010 - 09:43:08)
bootcmd=bootm fc080000 - fc060000
bootdelay=3
bootargs=console=ttyCPM0,115200n8 rdinit=/sbin/init panic=10 mem=32m
[root#ST600 /]#
Try to read uboot version this way:
Find uboot partition, eg. for MTD device:
cat /proc/mtd
For /dev/mtd5:
cat /dev/mtd5 | hexdump -C -n 64
You can't rely on fw_printenv if you want to know u-boot version.
fw_printenv just looks for the printenv partition and dumps its data. So it's OK for normal variables, but it's not OK for the "ver" variable, which is dynamic, and whose value is initialized by u-boot when it boots. The value of this variable doesn't remain after u-boot exit, except if you manually save it to environment.
For example, on my board, if I print the "ver" variable from u-boot prompt:
U-Boot > printenv ver
ver=U-Boot 2009.11-00393-g5ca9497-dirty (Nov 26 2012 - 11:08:44)
This is the real version of u-boot, coming from u-boot itself.
Now, if I boot my board and use fw_printenv:
el#board # fw_printenv | grep ver=
ver=U-Boot 2009.11-00323-gbcc6e0e (Sep 21 2012 - 11:07:19)
As you can see, it's different. Because it happens that I have a "ver" variable defined in my environment. And it doesn't match the real u-boot version.
Of course, I could go back to u-boot, use "saveenv" to update the "ver" value in the environment. Then the two values would match. But then, I should always update the environment after changing u-boot.
So, my conclusion is that using fw_printenv to get u-boot version is definitely not a good idea.
If u-boot is residing in an MTD partition then this will work:
U_BOOT_VER=$(for part in `grep u-boot-[01] /proc/mtd | cut -f 1 -d ':'`; do strings /dev/${part} | grep "^U-Boot.*("; break; done)
I'm looking to differentiate between Core Solo/Duo and Core 2 Duo processors for 64-bit support.
On a Core 2 Duo, then `sysctl hw.cpu64bit_capable` gives 1, as desired, but on a 32-bit processor, it throws an error, saying:
second level name cpu64bit_capable in hw.cpu64bit_capable is invalid
What's the best way to detect a 64-bit processor?
Thanks.
You can still use your sysctl command by looking at the command's return value.
$ irb
>> system("sysctl hw.cpu64bit_capable > /dev/null 2>&1")
=> true
On 32 bit CPU it should return false.
Alternatively, depending what you're really looking for, you can test for 64 bit EFI with ioreg, though I think your CPU could still be 64 bit with a 32 bit EFI.
On a 64 bit EFI machine, you'd get this:
$ irb
>> system("ioreg -l -p IODeviceTree | grep firmware-abi | grep -q EFI64")
=> true
On a machine lacking 64 bit EFI, you'd get false.