I need to get UUID value on 10.4 but the command seems not to be supported here.
ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, "\""); printf("%s\n", line[4]); }'
Above command is working fine on 10.5. Is this not supported on 10.4?
Also I am trying to fetch UUID using below code on 10.4, which is also not working:
void vlm_getSystemUUID_MAC(char * uuid, int bufSize)
{
io_registry_entry_t ioRegistryRoot = IORegistryEntryFromPath(kIOMasterPortDefault, "IOService:/");
CFStringRef uuidCf = (CFStringRef) IORegistryEntryCreateCFProperty(ioRegistryRoot, CFSTR(kIOPlatformUUIDKey), kCFAllocatorDefault, 0);
IOObjectRelease(ioRegistryRoot);
CFStringGetCString(uuidCf, uuid, bufSize, kCFStringEncodingMacRoman);
CFRelease(uuidCf);
}
And the above code executes well on 10.5.
Any help would be appreciated.
I believe that the IOPlatformUUID was first added to Mac OS X 10.5 Leopard, and wasn't available in previous versions (someone please correct me if I'm wrong). This blog post hints that this change was added in 10.5.
To ID a Mac running Mac OS X 10.4 and earlier, you'll have to use either the IOPlatformSerialNumber and/or built-in MAC address. See this for details and caveats: http://developer.apple.com/library/mac/#technotes/tn1103/_index.html
Related
I use the simple sys_call_table rewrite to
log all execve calls in a system.
When moving to Ubuntu 16.10 with a 4.8 kernel this
mechanism suddenly stopped to work. In 16.04 with
a 4.6 kernel it was working.
1: write_cr0 (read_cr0 () & (~ 0x10000));
2: original_execve = (void *)syscall_table[__NR_execve];
3: syscall_table[__NR_execve] = (unsigned long)&new_execve;
4: write_cr0 (read_cr0 () | 0x10000);
The page fault already happens when reading the old entry, that is line 2.
To retrive the sys_call_table address I use:
sudo cat /boot/System.map-`uname -r` | grep -e '\ssys_call_table' | awk '{ print $1}' )"
Code is from: https://github.com/eiselekd/shinterposer/tree/master/mod
Does anyone know what happened? Maybe some
protection mechanism has been introduced?
There seem to be Address Space Layout Randomization (kASLR) on the syscall table taking
place by default in the 4.8 kernel. When declaring the sys_call_table symbol as exported and linking against it directly from a module the address for sys_call_table is changing for each boot.
The address from /boot/System.map-xxx is useless.
To disable kaslr in ubuntu 16.10 kernel 4.8 one can add
nokaslr
to the kernel command line.
I'm finally able to get the device path ("/dev/rdisk1") - called devname here - after a search but POSIX open() fails with -1. Is this a permission issue? The camera is mounted and can be read normally via /Volumes but I need to access via /dev to control the camera via USB tether.
/* Found PENTAX DIGITAL_CAMERA */
snprintf(pslr.devname, sizeof(pslr.devname), "%s", devpath);
pslr.devname[sizeof(pslr.devname)-1] = '\0';
printf("pslr.devname %s\n", pslr.devname);
pslr.fd = open(pslr.devname, O_RDWR);
if (pslr.fd == -1) {
return NULL;
}
PS: after the discussion below I changed the permissions with sudo chmod command and then tried open but it still fails. I must be missing a step.
I checked with apple support and they say I cannot use posix functions to control a USB device in OS X.
On OS X El Capitan, my log file system.log feels with hundreds of the following lines at times
03/07/2016 11:52:17.000 kernel[0]: hfs_clonefile: cluster_read failed - 34
but there is no indication of the process where this happens. Apart from that, Disk Utility could not find any fault with the file system. But I would still like to know what is going on and it seems to me that dtrace should be perfectly suited to find out that faulty process but I am stuck. I know of the function return probe but it seems to require the PID, e.g.
dtrace -n 'pidXXXX::hfs_clonefile:return { printf("ret: %d", arg1); }'
Is there a way to tell dtrace to probe all processes? And then how would I print the process name?
You can try something like this (I don't have access to an OS X machine to test it)
#!/usr/sbin/dtrace -s
# pragma D option quiet
fbt::hfs_clonefile:return
/ args[ 1 ] != 0 /
{
printf( "\n========\nprocess: %s, pid: %d, ret value: %d\n", execname, pid, args[ 1 ] );
/* get kernel and user-space stacks */
stack( 20 );
ustack( 20 );
}
For the fbt probes, args[ 1 ] is the value returned by the function.
The dTrace script will print out the process name, pid, and return value from hfs_clonefile() whenever the return value is not zero. It also adds the kernel and user space stack traces. That should be more than enough data for you to find the source of the errors.
Assuming it works on OS X, anyway.
You can use the syscall provider rather than the pid provider to do this sort of thing. Something like:
sudo dtrace -n 'syscall::hfs_clonefile*:return /errno != 0/ { printf("ret: %d\n", errno); }'
The above command is a minor variant of what's used within the built-in DTrace-based errinfo utility. You can view /usr/bin/errinfo in any editor to see how it works.
However, there's no hfs_clonefile syscall, as least as far as DTrace is concerned, on my El Capitan (10.11.5) system:
$ sudo dtrace -l -n 'syscall::hfs*:'
ID PROVIDER MODULE FUNCTION NAME
dtrace: failed to match syscall::hfs*:: No probe matches description
Also, unfortunately the syscall provider is prevented from tracing system processes by the System Integrity Protection feature introduced with El Capitan (macOS 10.11). So, you will have to disable SIP which makes your system less secure.
On Mac OS X 10.6.8, some C code that calls readdir_r() sometimes gets an I/O error 5 (EIO) returned. I've seen this just a few times, always on external USB drives. Each time I've seen it, if I immediately cd to the parent direction and do an ls, I appear to see all the files. And, if I re-run the C program that saw the error, it will run fine.
On some platforms, when one gets an error like EIO, there's something else you can call that gives you much more detailed error information (e.g., hperrmsg on MPE/iX, which accesses the per-process error stack). Is there something similar on OS X?
I guess I'm assuming that the error is false
i = readdir_r (dirp, &dire, &dire_ptr);
save_errno = errno;
if (i)
{
if (i == EACCES)
...
else
{
my_perror (save_errno, "readdir_r failed: ");
espout4 ("readdir_r returned %s; errno = %s, dire_ptr = %s; parent = %s\n",
num64 (i), num64 (save_errno), fmt_p (dire_ptr), parent_dir);
espout1 (" (ERROR: readdir_r failed here, errno %s)\n", num64 (save_errno));
}
}
Update, a week later...
I've determined that the combo of the Macally case (model G-S350SU)
and the Western Digital drive was causing sporadic problems. I noticed that the WD SATA connector didn't mate tightly with the Macally socket. Using a Seagate drive with the case was fine, and using the WD drive in a different case was fine.
Of course, I'd still like to be able to get better / more detailed error information in my programs :)
If it matters, I am using Mac OS X, but I believe this would apply across OSs. If the answer is different per OS, I would be interested in learning about that as well.
Let's say that I open a terminal window, enable a few probes, and start collecting data with DTrace.
From a different terminal window, can I ask DTrace what probes have been enabled? If so, how?
I got the following information from Adam Leventhal on a DTrace mailing list. First, he provided this script, which works on Solaris
#!/usr/sbin/dtrace -s
#pragma D option quiet
int i;
tick-100
/i >= `dtrace_nprobes/
{
exit(0);
}
tick-100
{ printf("%4d %10s %20s %20s %10s %s\n", i,
stringof(`dtrace_probes[i]->dtpr_provider->dtpv_name),
stringof(`dtrace_probes[i]->dtpr_mod),
stringof(`dtrace_probes[i]->dtpr_func),
stringof(`dtrace_probes[i]->dtpr_name),
`dtrace_probes[i]->dtpr_ecb != NULL ? "enabled" : "disabled");
i++
}
Unfortunately, the same kernel variables are not available on Mac OS X due to a bug.