macOS-Tipps: Linux-System von Mac aus vorbereiten

Symptom: Nach dem Imaging vom Mac startet Linux, aber privilegierte Werkzeuge wie sudo verweigern den Dienst.

Tipp: Das mitgelieferte macOS-rsync (oft BSD-/openrsync-Variante) überträgt setuid-/setgid-Bits auf ext4 nicht zuverlässig. Nach dem Kopieren im Quell-Image Dateien mit gesetzten Bits ermitteln und die Modi auf dem Ziel explizit wiederherstellen – bevor der erste Login erwartet wird.

# Im Quell-Image setuid/setgid finden
find /mnt/src -xdev \( -perm -4000 -o -perm -2000 \) -type f -printf '%m %p\n'

# Auf dem Ziel beispielhaft wiederherstellen
chmod 4755 /mnt/root/usr/bin/sudo
chown root:root /mnt/root/usr/bin/sudo

Symptom: „exec format error“ in Login-Skripten, leere XML-Fehler in MIME-Tools oder „Directory not empty“ bei Paketaufräumen.

Tipp: Beim Schreiben von macOS auf Linux entstehen häufig ._*- und Spotlight-/Trash- Artefakte. Beim Kopieren Metadaten deaktivieren, solche Muster ausschließen und danach bereinigen. Zusätzlich im ersten Boot-Setup defensiv nachräumen.

export COPYFILE_DISABLE=1
rsync -aH \
  --exclude='._*' --exclude='.DS_Store' \
  --exclude='.Spotlight-V100' --exclude='.fseventsd' \
  --exclude='.Trashes' --exclude='.TemporaryItems' \
  /mnt/src/ /mnt/root/

find /mnt/root -xdev -name '._*' -delete
find /mnt/root -xdev -name '.DS_Store' -delete

Symptom: Kopieren „läuft“, ändert aber nichts oder bricht mit Schreibfehlern ab.

Tipp: Für schreibbaren ext4-Zugriff unter macOS braucht es typischerweise einen dedizierten Treiber. Vor großen Kopierläufen mit einer Testdatei prüfen, ob der Mount wirklich schreibbar ist. Abgelaufene Trials melden oft stillen Nur-Lese-Modus – dann hart abbrechen statt weiterzukopieren.

# Nach dem Mount: Schreibbarkeit prüfen (Mountpunkt anpassen)
touch /Volumes/ROOT/.write-test && rm /Volumes/ROOT/.write-test && echo "RW OK"

# Wenn der Test fehlschlägt: nicht weiterkopieren
mount | grep -E 'ROOT|ext4' || true

Symptom: Prüfung läuft, danach bleibt das Volume trotzdem schreibgeschützt.

Tipp: Manche macOS-fsck-Läufe reparieren Inodes, setzen aber den „sauber“-Zustand nicht dauerhaft. Dann hilft oft nur Neuformatieren der betroffenen Partition und erneutes Aufspielen – nicht endlos mit Low-Level-Editoren „flicken“.

# Nur prüfen (Gerät anpassen), kein Blind-Reparatur-Loop
e2fsck -n /dev/diskXsY

# Bei dauerhaft „dirty“: Partition neu formatieren statt endlos flicken
# mkfs.ext4 -F -L ROOT /dev/diskXsY

Symptom: Kernel findet Root nicht; Meldung zu fehlender Partitionskennung.

Tipp: Von macOS aus ermittelte Partitionskennungen weichen oft von dem ab, was Linux erwartet (fehlende führende Nullen, andere UUID-Quellen). Für Mac-gebaute Images Dateisystem-UUID bzw. klare Labels bevorzugen; Partitionskennungen nur nutzen, wenn sie unter Linux verifiziert wurden.

# Unter Linux gelesene Kennungen sind für Boot-Zeilen zuverlässiger
blkid -o export /dev/sdXN

# Bevorzugt Dateisystem-UUID / Label nutzen, z. B.:
# root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Symptom: Einzelbefehle scheitern still oder Verzeichnisse entstehen nicht.

Tipp: Werkzeuge für ungemountete ext4-Volumes verhalten sich unter macOS empfindlich: Befehle gebündelt übergeben, Partition vorher aushängen, Dateimodi als vollständigen Modus setzen. Virtuelle Mountpunkte (proc, sys, dev, run, tmp), die beim Kopieren ausgeschlossen wurden, müssen vor dem Boot wieder existieren.

# Partition vorher aushängen, dann Verzeichnisse anlegen
diskutil unmount /dev/diskXsY 2>/dev/null || true
debugfs -w /dev/diskXsY <<'EOF'
mkdir /proc
mkdir /sys
mkdir /dev
mkdir /run
mkdir /tmp
quit
EOF

Symptom: Nach dem ersten Start ist das geplante Layout verändert oder der Boot instabil.

Tipp: Viele Board-Images bringen Dienste mit, die Root automatisch auf die volle Gerätegröße aufblasen. Bei eigener GPT-Aufteilung diese Resize-/First-Boot-Dienste vor dem ersten Start deaktivieren (Maskierung, Wants bereinigen, Cloud-Init-Resize abschalten).

# Im gemounteten Rootfs Auto-Resize/First-Boot maskieren
ROOT=/mnt/root
for u in \
  systemd-growfs@root.service \
  rpi-resize.service \
  rpi-firstboot.service
do
  mkdir -p "$ROOT/etc/systemd/system"
  ln -sfn /dev/null "$ROOT/etc/systemd/system/$u"
done

mkdir -p "$ROOT/etc/cloud/cloud.cfg.d"
printf '%s\n' 'growpart:' '  mode: false' 'resize_rootfs: false' \
  > "$ROOT/etc/cloud/cloud.cfg.d/99-disable-growpart.cfg"

Symptom: Login möglich, aber Schreibzugriff im Home scheitert.

Tipp: Vorab angelegte Home-Verzeichnisse bleiben oft root-owned. Nach dem Anlegen der User-Konten Besitz und Rechte passend setzen und fehlende Standarddateien aus dem System-Skeleton nachziehen.

# Benutzer/Pfad anpassen; typisch UID/GID 1000
USER=meinuser
HOME_DIR=/mnt/root/home/$USER
chown -R 1000:1000 "$HOME_DIR"
chmod 750 "$HOME_DIR"
cp -n /mnt/root/etc/skel/.bashrc "$HOME_DIR/" 2>/dev/null || true
cp -n /mnt/root/etc/skel/.profile "$HOME_DIR/" 2>/dev/null || true

Symptom: Paketquellen, Installer-Skripte oder Zertifikatsausstellung scheitern unmittelbar nach dem ersten Boot.

Tipp: Geräte ohne Echtzeituhr starten oft mit der Build-Zeit des Images. Weicht die Uhr stark ab, gelten Serverzertifikate als ungültig. Zeitzone und Zeitsync vor allen TLS-abhängigen Schritten setzen.

# Auf dem Zielsystem als Erstes mit Netz
sudo timedatectl set-timezone Europe/Berlin
sudo timedatectl set-ntp true
timedatectl status
date -u

Symptom: HTTPS-Clients finden den lokalen Vertrauensspeicher nicht; Folgeschritte wirken „kaputt“, obwohl das Netz steht.

Tipp: Beim Imaging den Vertrauensspeicher nicht aussparen. Nach dem ersten Boot prüfen, ob das CA-Bundle vorhanden und gültig ist; bei Bedarf das Paket für CA-Zertifikate neu installieren und den Store neu erzeugen.

# Bundle prüfen
test -s /etc/ssl/certs/ca-certificates.crt && \
  grep -q 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt && echo OK

# Bei Bedarf neu erzeugen (Debian/Ubuntu)
sudo apt-get install --reinstall -y ca-certificates
sudo update-ca-certificates -f

Symptom: Die Zertifizierungsstelle kann die Domain nicht bestätigen.

Tipp: Für HTTP-01 muss der Validierungspfad aus dem Internet ohne Login erreichbar sein, DNS muss auf den richtigen Host zeigen, und der Zugang darf nicht hinter CGNAT ohne öffentliche Erreichbarkeit stecken. Bei wiederholten Fehlversuchen Rate-Limits beachten und Tests ggf. gegen eine Staging-Umgebung fahren.

# Domain anpassen – Erreichbarkeit für HTTP-01 prüfen
DOMAIN=example.com
dig +short "$DOMAIN" A
curl -fsSI "http://$DOMAIN/.well-known/acme-challenge/ping" | head -n 8 || true

# Tests besser gegen Staging
# sudo certbot certonly --dry-run --webroot -w /var/www/html -d "$DOMAIN"