add a sanity check that checks if it runs as root

[m1-debian] / doc / notes.txt

diff --git a/doc/notes.txt b/doc/notes.txt
index 5e773f98ac36a02a6078db098fbd84d48cf3b061..e2b2d8b6ed751b7b19e7153bf747f0afbd4f7f08 100644 (file)
--- a/doc/notes.txt
+++ b/doc/notes.txt
@@ -135,3 +135,53 @@ echo 1 > /sys/module/hid_apple/parameters/swap_opt_cmd
 cloud-initramfs-growroot
 16:00 < Glanzmann> So applying a new uuid to the rootfs needs to be done in the initrd.
 tune2fs -U random /dev/whatever
 cloud-initramfs-growroot
 16:00 < Glanzmann> So applying a new uuid to the rootfs needs to be done in the initrd.
 tune2fs -U random /dev/whatever

+
+07:54 < VinDuv> So I’ve been looking at how macOS installation from USB works on M1 Macs and I think it might be interesting for the Asashi installer. The way it works is that there’s a hidden plist file on the USB drive that references a macOS
+                application on the drive; if this file is present, the USB drive will show up in the power-button-held boot menu, and when selected, it will run the application. It doesn’t seem to care about file signature
+07:54 < VinDuv> (it works even if the app is just a shell script) and it looks like it’s in 1TR mode.
+07:56 < VinDuv> So the installation workflow from 1TR could be “plug in a USB stick, hold the power button, select Install Asahi” instead of having to manually open the terminal and run curl | sh. The installer doesn’t even need to be graphical since
+                it’s possible for the launched shell script to start the recovery environment’s Terminal and giving it an arbitrary command to run.
+07:59 < VinDuv> This is also not limited to external USB drives; it also works if the files are in an APFS volume in internal storage, which I guess might be useful to have a Asahi Recovery boot option in the boot menu or something.
+
+---- .IAPhysicalMedia ---------------------------------------------------------
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+       <key>AppName</key>
+       <string>Some App.app</string>
+       <key>ProductBuildVersion</key>
+       <string>00A191</string>
+       <key>ProductVersion</key>
+       <string>12.2.1</string>
+</dict>
+</plist>
+
+---- Some App.app/Contents/Info.plist -----------------------------------------
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+       <key>CFBundleDisplayName</key>
+       <string>Some App</string>
+       <key>CFBundleExecutable</key>
+       <string>SomeApp</string>
+</dict>
+</plist>
+
+---- Some App.app/Contents/Resources/<lang code>.lproj/InfoPlist.strings ------
+"CFBundleDisplayName" = "Some App";
+
+---- Some App.app/Contents/MacOS/SomeApp (executable) -------------------------
+#!/bin/bash
+exec /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal "${0%/*}/../Resources/myscript.command"
+
+---- Some App.app/Contents/Resources/myscript.command -------------------------
+#!/bin/sh
+
+echo "Hello, world!"
+exec /bin/bash
+
+
+19:14 <VinDuv> marcan: I have done a bit more testing with the .IAPhysicalMedia file and it looks like ProductBuildVersion can be any value including blank. ProductVersion seems to be checked against the minimal macOS version supported by the Mac; on my mini the icon shows up in the boot menu only if it’s >= 11.3.
+19:15 <VinDuv> Maybe it should be set to a higher value for forward compatibility with future Macs that will require 13.0? I’ve tested setting it to 99 and it works.