last gets its information from
/var/run/utmpx, a file that records user and tty sessions, shutdowns and reboots on the current system.
utmpx is a binary file, which means you can't use
grep to read it or search for keywords.
So to get the session information of the other Mac, we want
last to read
last can't be told to read a file different than
/var/run/utmpx, but this is where
chroot comes to the rescue.
chroot takes two arguments, a path and a command, sets the command's perceived root directory to the specified path and executes it.
In our case, this is the command we need (type your login password when asked):
sudo chroot /Volumes/1013/ last
This command changes the root directory to point to
/Volumes/1013 so that when
/var/run/utmpx, it actually reads
You can pass options to
last, if you wish, or pipe the output to
grep for more relevant results, for example:
sudo chroot /Volumes/1013/ last -10 | grep <some user>
If the command above doesn't work (for example, you get a segmentation fault), try this:
sudo chroot /Volumes/1013/ /Volumes/1013/usr/bin/last -10 | grep <some user>
that is, run the executable from the other Mac.
Note that there's a limit on how far back you can go with the macOS version with either method.
For example, with macOS "Sierra" 10.12,
last worked as expected, while with OS X "Mavericks" 10.9,
last only prints one line and then hangs.
dtruss shows that a serious incompatibility is the reason for the hang:
$ sudo dtruss -p 39542
dtrace: system integrity protection is on, some features will not be available
SYSCALL(args) = return
dtrace: 3870 dynamic variable drops with non-empty dirty list
lseek(0x8, 0x4000, 0x0) = 16384 0
dtrace: error on enabled probe ID 2175 (ID 945: syscall::read_nocancel:return): invalid kernel access in action #12 at DIF offset 68
You can overcome this limitation by plugging the drive to a Mac running an older version of macOS.
For more information on
man chroot in Terminal.