---
title: Wechsel Boot von HDD On Off
description: Bootfähigkeit der HDD wechseln zwischen on und off auf dem Raspberry PI5
published: true
date: 2026-02-01T17:44:47.642Z
tags: 
editor: markdown
dateCreated: 2026-02-01T17:25:50.416Z
---

# Raspberry‑Pi‑Bootpartition deaktivieren/aktivieren
Natürlich, Dirk — ich packe dir jetzt **alles vollständig, sauber strukturiert und dokumentiert** in **einem einzigen Paket**, damit du nie wieder etwas zusammensuchen musst.

Du bekommst:

1. **Eine vollständige Markdown‑Dokumentation**  
2. **Eine Tabelle mit allen Dateien und Befehlen**  
3. **Zwei fertige Skripte (Disable & Enable)**  
4. **Erklärungen, warum das alles so funktioniert**

Alles ist reversibel, sicher und exakt auf deine Raspberry‑Pi‑Bootpartition zugeschnitten.

---

# 📘 **Komplette Dokumentation: Raspberry‑Pi‑Bootpartition deaktivieren/aktivieren**

## 🧠 Hintergrund

Der Raspberry Pi bootet **nicht** über Boot‑Flags, MBR‑Flags oder GPT‑Attribute.  
Er bootet **ausschließlich über Dateinamen** auf der Boot‑Partition (FAT32).

Wenn Dateien wie:

- `start4.elf`
- `kernel8.img`
- `config.txt`
- `cmdline.txt`
- `bootcode.bin`

vorhanden sind, erkennt die Firmware die Partition als **bootfähig**.

👉 **Wenn du diese Dateien umbenennst, wird die Platte unbootbar — vollständig reversibel.**

---

# 📁 **Liste aller bootrelevanten Dateien**

Diese Dateien/Ordner müssen umbenannt werden, wenn die Partition *maximal* deaktiviert werden soll:

- Firmware‑Loader (`start*.elf`, `bootcode.bin`)
- Kernel (`kernel*.img`)
- Initramfs (`initramfs*`)
- Konfiguration (`config.txt`, `cmdline.txt`, `issue.txt`)
- GPU‑Firmware (`fixup*.dat`, `fixup4*.dat`)
- Device‑Tree‑Blobs (`bcm*.dtb`)
- Overlays‑Ordner (`overlays/`)

---

# 📑 **Markdown‑Tabelle: Deaktivieren & Aktivieren**

```markdown
| Datei / Muster           | Deaktivieren (umbenennen)                          | Aktivieren (zurückbenennen)                         |
|--------------------------|-----------------------------------------------------|------------------------------------------------------|
| bootcode.bin             | mv bootcode.bin bootcode.bin.disabled              | mv bootcode.bin.disabled bootcode.bin               |
| start*.elf               | for f in start*.elf; do mv "$f" "$f.disabled"; done | for f in start*.elf.disabled; do mv "$f" "${f%.disabled}"; done |
| start4*.elf              | for f in start4*.elf; do mv "$f" "$f.disabled"; done | for f in start4*.elf.disabled; do mv "$f" "${f%.disabled}"; done |
| kernel*.img              | for f in kernel*.img; do mv "$f" "$f.disabled"; done | for f in kernel*.img.disabled; do mv "$f" "${f%.disabled}"; done |
| initramfs*               | for f in initramfs*; do mv "$f" "$f.disabled"; done | for f in initramfs*.disabled; do mv "$f" "${f%.disabled}"; done |
| config.txt               | mv config.txt config.txt.disabled                  | mv config.txt.disabled config.txt                   |
| cmdline.txt              | mv cmdline.txt cmdline.txt.disabled                | mv cmdline.txt.disabled cmdline.txt                 |
| issue.txt                | mv issue.txt issue.txt.disabled                    | mv issue.txt.disabled issue.txt                     |
| fixup*.dat               | for f in fixup*.dat; do mv "$f" "$f.disabled"; done | for f in fixup*.dat.disabled; do mv "$f" "${f%.disabled}"; done |
| fixup4*.dat              | for f in fixup4*.dat; do mv "$f" "$f.disabled"; done | for f in fixup4*.dat.disabled; do mv "$f" "${f%.disabled}"; done |
| bcm*.dtb                 | for f in bcm*.dtb; do mv "$f" "$f.disabled"; done   | for f in bcm*.dtb.disabled; do mv "$f" "${f%.disabled}"; done |
| overlays/                | mv overlays overlays.disabled                       | mv overlays.disabled overlays                       |
```

---

# 🛠️ **Script 1: disable_boot.sh**  
**→ macht die HDD vollständig unbootbar**

```bash
#!/bin/bash
# Deaktiviert alle Raspberry-Pi-Bootdateien durch Umbenennung

mv bootcode.bin bootcode.bin.disabled 2>/dev/null

for f in start*.elf; do mv "$f" "$f.disabled" 2>/dev/null; done
for f in start4*.elf; do mv "$f" "$f.disabled" 2>/dev/null; done

for f in kernel*.img; do mv "$f" "$f.disabled" 2>/dev/null; done
for f in initramfs*; do mv "$f" "$f.disabled" 2>/dev/null; done

mv config.txt config.txt.disabled 2>/dev/null
mv cmdline.txt cmdline.txt.disabled 2>/dev/null
mv issue.txt issue.txt.disabled 2>/dev/null

for f in fixup*.dat; do mv "$f" "$f.disabled" 2>/dev/null; done
for f in fixup4*.dat; do mv "$f" "$f.disabled" 2>/dev/null; done

for f in bcm*.dtb; do mv "$f" "$f.disabled" 2>/dev/null; done

mv overlays overlays.disabled 2>/dev/null

echo "Bootpartition wurde deaktiviert."
```

---

# 🔄 **Script 2: enable_boot.sh**  
**→ stellt alles wieder her**

```bash
#!/bin/bash
# Aktiviert alle Raspberry-Pi-Bootdateien durch Rückbenennung

mv bootcode.bin.disabled bootcode.bin 2>/dev/null

for f in start*.elf.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
for f in start4*.elf.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done

for f in kernel*.img.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
for f in initramfs*.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done

mv config.txt.disabled config.txt 2>/dev/null
mv cmdline.txt.disabled cmdline.txt 2>/dev/null
mv issue.txt.disabled issue.txt 2>/dev/null

for f in fixup*.dat.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
for f in fixup4*.dat.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done

for f in bcm*.dtb.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done

mv overlays.disabled overlays 2>/dev/null

echo "Bootpartition wurde wieder aktiviert."
```

---

# 🧩 **Warum funktioniert das?**

- Der Raspberry Pi sucht beim Booten nach **konkreten Dateinamen**.  
- Wenn diese fehlen oder anders heißen → **Partition wird ignoriert**.  
- Durch `.disabled` bleibt alles erhalten und ist jederzeit rückgängig machbar.  
- Die Schleifen (`for f in …`) stellen sicher, dass **jede Datei einzeln** umbenannt wird.

---
Dirk, das Verhalten ist absolut logisch – und du hast nichts falsch gemacht.  
Der Grund, warum `chmod +x *.sh` **nicht** funktioniert hat, liegt an **Dateirechten und Besitzern**, nicht am Befehl selbst.

Ich zeige dir kurz und klar, was passiert ist.

---

# 🔍 Warum `chmod +x *.sh` NICHT funktioniert hat

Du bist als **root** unterwegs (`sudo -i`), aber die Dateien gehören:

```
piadmin piadmin
```

Das ist **kein Problem** – root darf alles.  
Der eigentliche Grund ist:

### 👉 Die Boot‑Partition ist FAT32  
Und FAT32 unterstützt **keine Unix‑Dateirechte**.

Das bedeutet:

- Es gibt **kein x‑Bit**
- Es gibt **keine echten Besitzer**
- Es gibt **keine chmod‑Rechte**
- Alles, was du siehst (`-rw-r--r--`), ist nur **simuliert**

### Deshalb:
`chmod +x *.sh` läuft **ohne Fehler**, aber es **ändert nichts**, weil FAT32 das x‑Bit nicht speichern kann.

---

# 🧠 Wie führst du die Skripte trotzdem aus?

Ganz einfach:  
Du musst sie **explizit** mit der Shell starten:

```
bash disable_boot.sh
```

oder

```
sh disable_boot.sh
```

oder

```
/bin/bash disable_boot.sh
```

Das funktioniert IMMER, auch ohne x‑Bit.

---

# 💡 Wenn du die Skripte wirklich ausführbar machen willst

Dann musst du sie auf ein Dateisystem kopieren, das Unix‑Rechte unterstützt, z. B.:

- ext4
- btrfs
- xfs

Beispiel:

```
cp disable_boot.sh /home/piadmin/
cp enable_boot.sh /home/piadmin/
cd /home/piadmin
chmod +x *.sh
```

Dann kannst du sie normal starten:

```
./disable_boot.sh
```

---

# 🧩 Kurzfassung

| Ursache | Erklärung |
|--------|-----------|
| FAT32‑Partition | unterstützt keine chmod‑Rechte |
| x‑Bit kann nicht gesetzt werden | deshalb bleibt `-rw-r--r--` |
| Skripte laufen trotzdem | aber nur über `bash script.sh` |

---

Wenn du willst, kann ich dir auch ein kleines Wrapper‑Script bauen, das die Boot‑Partition automatisch mountet und die Skripte dort ausführt.