Hallo zusammen Ich möchte auf meinem Board mit selbstgebautem Linux Kernel und eigenem U-Boot gerne ein debian oder ubuntu rootfs starten. Dazu habe ich mir ein rootfs von hier gezogen: https://github.com/jubinson/debian-rootfs (armhf) https://www.dropbox.com/s/6uqm7kxg327aex7/armhf-rootfs-20170310T075755Z.tar.gz?dl=1 Auf die Karte entpakt, meinen kernel und dtb dazu getan. Dann noch alle Ordner und dateien mit chown 0:0 durch Root in besitz genommen. Nun gestartet.... https://nopaste.xyz/?6787e8e7e4b85871#8zFGs6JXjNvKRDKasf6swgEaTVdH65hjJ/svZVSr+7M= Leider gehts dann nicht mehr weiter nach failed to mount... Also mal ein anderes rootfs gezogen. Jenes von NXP für ein entsprechendes EVAL-Board. Auch hier wieder das gleiche prozedere wie oben. Gestartet und... https://nopaste.xyz/?def4b1a13f11dc4c#gK8ssTMZV+AF03zawLL/qwpFsFoC8RabmvrejDOgJqY= Zuerst auch lange nichts, doch nach ca. 2 Minuten dann doch noch ein Loginpromt. Leider hat letzteres rootfs "nur" busybox. Gerne hätte ich aptitude etc. Deshalb ein ubunutu oder debian rootfs. Hat jemand eine Idee, wie ich dem Board auf die Sprünge helfen kann? Muss ich evtl. noch eine Option im Kernel aktivieren? Danke!
[proc] [ 3.858832] Freeing unused kernel memory: 1024K [ 3.864485] Run /sbin/init as init process INIT: version 2.88 booting mount: only root can mount proc on /proc [/proc] Also init wird schonmal gestartet, das ist gut. Ich hab mal ins tar gesehen, das sieht eigentlich recht gut aus. Was mir noch aufgefallen ist, es gibt keine /etc/fstab, ich weiss aber nicht, ob diese bei systemd systemen noch nötig ist. Die Probleme fangen aber sowieso schon vorher an. Holger K. schrieb: > Dann noch alle Ordner und dateien mit chown 0:0 durch Root in besitz > genommen. Das ist eine sehr schlechte Idee. Das macht so ziemlich alles kaputt, das nicht als root läuft, und entfernt zusätzlich noch alle suid und sgid bits, was den Fehler "mount: only root can mount proc". Obwohl, eigentlich sollte das selbst dann nicht assieren. [proc] mount: wrong fs type, bad option, bad superblock on tmpfs, [/proc] Stelle sicher, dass du tmpfs und devtmpfs und proc im linux kernel aktiviert hast. Ich weiss nichtmehr, wie genau die Optionen in menuconfig heissen. Ich neme an du hast momenta nur eine Partition mit dem Rootfs? Ist diese ext{2,4} oder fat32? Von letzterem würde ich abraten, weil keine das keine unix berechtigungen, keine symlinks, etc. unterstüzt. Wenn es trotzdem unter Windows nutzbar sein muss, würde ich udf versuchen.
Oh, und noch was, ich bootstrappe meine systeme ja immer gerne selbst. Du kannst auf dem PC auch in das rootfs chrooten wenn es eine andere Architektur hat, das Verfahren hat nur 2 schritte mehr. Ich bin noch nicht dazu gekommen, das mit deinem rootfs auszuprobieren, aber so sollte es gehen:
1 | apt-get install qemu-user-static binfmt-misc |
2 | cp "$(which qemu-armhf-static)" "/path/to/rootfs/$(which qemu-armhf-static)" |
3 | chroot /path/to/rootfs/ |
So kann man auch manuell mit debootstrap für andere architekturen bootstrappen (btw. die second stage.). Erst normal mit "debootstrap --foreign --arch=armhf ..." normal die erste stage, dann im chroot die zweite "chroot /path/to/rootfs/ /debootstrap/debootstrap" (wieder nach dem kopieren von qemu-armhf-static). Eventuell kannst du so von im system etwas weiteranalysieren, weitere sachen installieren, etc.. So ähnlich kann man das übrigens auch libvirt-lxc container mit anderer architektur laufen lassen. Jedoch kann es bei seccomp verwendenden Anwendungen zu problemen kommen.
Edit: "chroot /path/to/rootfs/ /debootstrap/debootstrap --second-stage", nicht "chroot /path/to/rootfs/ /debootstrap/debootstrap".
Vielen Dank für deine Antwort. Also... DPA schrieb: > Das ist eine sehr schlechte Idee. Das macht so ziemlich alles kaputt, > das nicht als root läuft, und entfernt zusätzlich noch alle suid und > sgid bits, was den Fehler "mount: only root can mount proc". Obwohl, > eigentlich sollte das selbst dann nicht assieren. Dann entpacke ich das tar also einfach so, wie es ist? Und lasse das ganze unberührt? Hat es keinen Einfluss darauf mit welchem Benutzer ich das Tar auf die Karte entpacke? DPA schrieb: > Stelle sicher, dass du tmpfs und devtmpfs und proc im linux kernel > aktiviert hast. Ich weiss nichtmehr, wie genau die Optionen in > menuconfig heissen. Gut, schaue ich gleich mal nach... DPA schrieb: > Ich neme an du hast momenta nur eine Partition mit dem Rootfs? Richtig. DPA schrieb: > ext{2,4} oder fat32? Von letzterem würde ich abraten, weil keine das > keine unix berechtigungen, keine symlinks, etc. unterstüzt. Wenn es > trotzdem unter Windows nutzbar sein muss, würde ich udf versuchen. Ich benutze ext2. Das kopieren der Daten auf die Karte mache ich von einem Linux-Notebook aus. Also keine VM. DPA schrieb: > Oh, und noch was, ich bootstrappe meine systeme ja immer gerne > Eventuell kannst du so von im system etwas weiteranalysieren, weitere > sachen installieren, etc.. Danke für den Tipp. Werde ich mir anschauen. Aber habe ich das grundsätzlich schon richtig verstanden, dass das rootfs in gewissem masse unabhängig vom Kernel ist, solange der Kernel die Funktionen, welche die Anwendungen im rootFS benötigen, unterstützt? Oder anderst gefragt. Mein vorhaben, ein für armhf gebuildetes rootfs (ohne Kernel) zu kopieren, ist grundsätzlich nicht falsch?
Holger K. schrieb: > Hat es keinen Einfluss darauf mit welchem Benutzer ich das Tar auf die > Karte entpacke? Das sollte als root gemacht werden. Andernfalls können die Benutzer und rechte teils nicht gesetzt werden. Alternativ könnte man auch einige capabilities setzten, aber mit denen wäre es dann sowieso wieder trivial root zu werden. Es ohne root rechte zu entpacken und dennoch die Berechtigungen richtig gesetzt zu haben währe nur mit einigen relativ komplizierten Tricks mit user namespaces und fuse möglich. Holger K. schrieb: > Aber habe ich das grundsätzlich schon richtig verstanden, dass das > rootfs in gewissem masse unabhängig vom Kernel ist, solange der Kernel > die Funktionen, welche die Anwendungen im rootFS benötigen, unterstützt? Ja, das stimmt.
Holger K. schrieb: > Oder anderst gefragt. Mein vorhaben, ein für armhf gebuildetes rootfs > (ohne Kernel) zu kopieren, ist grundsätzlich nicht falsch? Ja, das sollte kein Problem sein.
DPA schrieb: > Das sollte als root gemacht werden. Andernfalls können die Benutzer und > rechte teils nicht gesetzt werden. Alternativ könnte man auch einige > capabilities setzten, aber mit denen wäre es dann sowieso wieder trivial > root zu werden. Super. Ja, habs bisher als root entpackt. Ich dachte, damit wird der Besitzer jeder Datei automatisch zu root. Aber das ist vermutlich nur bei Windows so... tmpfs war im kernel deaktiviert. Ein "proc" habe ich noch nicht gefunden... Merkwürdig finde ich aber diese Zeile:
1 | mount: only root can mount proc on /proc |
Kommt die eventuell daher, da ich alles mit root als owner gesetzt habe und daher /proc nur noch von root benutzt werden kann? Oder bedeutet dies etwas anderes?
Holger K. schrieb: > Kommt die eventuell daher, da ich alles mit root als owner gesetzt habe > und daher /proc nur noch von root benutzt werden kann? > > Oder bedeutet dies etwas anderes? Auch wenn /proc root:root gehört, was durchaus normal ist, ist der mode normalerweise so gesetzt, das jeder lesend darauf zugreifen kann. Ein chown von /proc zu root:root ist also kein Problem. Ich weiss nicht, wie genau systemd systeme so ganz am Anfang des boot prozess vorgehen, ich kann hier nur spekulieren. In der regel kann der "mount" syscall aber immer nur als root ausgeführt werden. Der kernel startet den init prozess, in diesem fall Systemd, auch als root. Vermutlich wechselt systemd oder etwas, was davon aufgerufen wird, zu einem anderen user, und vermutlich ruft das dann weitere Anwendungen und später irgendwann mount auf. Vermutlich braucht irgend ein Programm dabei das suid bit, um nach root zurück zu wechseln, und mount auszuführen. Da chmod das suid bit immer löscht, würde in dem scenario mount nicht mehr als root ausgeführt, und damit fehlschlagen. Auf meinem devuan system hat das "/bin/mount" program selbst das suid bit (ich muss später mal nachsehen warum eigentlich):
1 | root@x:~# find / -perm /4000 |
2 | /bin/mount |
3 | /bin/su |
4 | /bin/umount |
5 | ... |
Auf debian wird das wohl auch der Fall sein, Devuan ist ein derivat davon mit relativ wenigen Abweichungen. Systemd muss wohl irgendwie darauf angewiesen sein, dass mount das suid bit hat, und kann es dann wohl irgendwie ohne root nutzen und mount sich selbst zu root zurück wechseln lassen.
Danke für deine Antwort. Hab nur das tar.gz auf die sd karte kopiert und dann mit einem nautilus welches als root gestartet wurde dort hin entpackt. Nun startete das System einwandfrei... Nur doof, dass da auch keine Paketverwaltung im rootfs war... Achja, hab jetzt den Kernel mit tmpfs. Vermutlich lags an beidem. Jetzt muss ich nur noch ein debian / ubuntu rootfs für arm finden, welches aptitude enthält. Oder buildet man sich das auch selbst? Ich glaube buildroot ist nicht geeignet für debian rootfs oder? EDIT: Hab grad gesehen, dass da wohl was schief ging. Ich glaube seit tmpfs hat der kernel nicht das rootfs der karte geladen sondern die busybox von buildroot... Deshalb gings wohl so fix.
:
Bearbeitet durch User
Holger K. schrieb: > Hab nur das tar.gz auf die sd karte kopiert und dann mit einem nautilus > welches als root gestartet wurde dort hin entpackt. Ich würde empfehlen, das statdessen mit dem terminal mit "cd /pfad/zum/rootfs/ && tar xf archivname.tar.gz" zu machen. Dann sieht man nähmlich Warnungen, wenn z.B. ein User nicht gesetzt werden kann usw. Holger K. schrieb: > Jetzt muss ich nur noch ein debian / ubuntu rootfs für arm finden, > welches aptitude enthält. Das Image enthält apt, den default package manager von debian. Darüber kannst du dir auch aptitude installieren. Zuerst musst du schauen, das das Netzwerk läuft. Mit "ifconfig -a" kannst du alle interfaces auflisten. Falls keines da ist, muss man eventuell den Kernel nochmal anpassen. Falls es nicht automatisch konfiguriert wird muss man das mamuell machen "ifconfig interfacename up; dhclient interfacename;". Eventuell kann man das auch dauerhaft machen, früher war das in Debian unter "/etc/network/interfaces", ich bin mir aber nicht sicher, ob das noch so ist. Wenn das Netz läuft, die Uhrzeit prüfen "date". Notfalls die richtige (oder einige minuten in der vergangenheit) setzen (ich glaub das war "date -s '2019-06-18 hh:mm'"). Danach "apt-get update && apt-get install aptitude". Alternativ kann man die Packete auch in ein lokales Repo auf einem Wechseldaenträger packen und die /etc/apt/sources.list anpassen. Noch eine Alternative wäre schon vor der Erstverwendung mit chroot ins rootfs zu wächseln und es im vornherein installieren. Und vermutlich hat buildroot auch optionen, um weitere packete vorzuinstallieren, aber das hab ich bisher noch nicht verwendet.
Holger K. schrieb: > Jetzt muss ich nur noch ein debian / ubuntu rootfs für arm finden, > welches aptitude enthält. > > Oder buildet man sich das auch selbst? Normalerweise installiert man aptitude über die Debian-Repo. Du solltest bei dir entspr. das apt überprüfen bzw. einrichten (/etc/apt/sources.list) Und dann apt-get update apt-get upgrade und apt-get install aptitude Als Beispiel anbei mein sources.list für Debian 8 (jessie) auf einem Banana Pi system (ARM 32 bit).
:
Bearbeitet durch User
Danke für eure Antworten. Netzwerk funktioniert soweit eigentlich. Mein Problem ist, dass der jetzige Kernel immer ein rootfs enthält. Wenn ich cd / und dann ls mache, dann zeigt er mir ein minimales rootfs an, aber nicht jenes der Karte... Auch das zImage ist von zuvor 5.2Mb auf 8.4Mb gewachsen. Ich kriege es jedoch nicht weg... Denn unter target-filesystems ist "append initial rootfs to kernel" deaktiviert. Ich glaube ich muss mal ein clean machen.
Holger K. schrieb: > EDIT: > > Hab grad gesehen, dass da wohl was schief ging. > Ich glaube seit tmpfs hat der kernel nicht das rootfs der karte geladen > sondern die busybox von buildroot... Woher kommt denn die busybox? Ich sehe im verlinkten rootfs gar keine initramfs oder dergleichen in der dieses sein könnte. Oder ist das bei dir direkt in den Kernel mit hinein kompiliert? Ich glaube systemd hat auch noch eine rescue shell. So oder so, Schau mal mit mount nach, was wie gemountet ist, und mit "ls /dev/", was es so für devices gibt die das rootfs enthalten könnten.
Wenn bei dir die Internetverbindung schon klappt: Ich hatte vor einiger Zeit das rootfs so übers Netz installiert:
1 | targetdir="/mnt/rootfs" |
2 | distro="jessie" |
3 | debootstrap --arch=armhf --foreign $distro $targetdir |
Mutluit M. schrieb: > Wenn bei dir die Internetverbindung schon klappt: > Ich hatte vor einiger Zeit das rootfs so übers Netz > installiert:targetdir="/mnt/rootfs" > distro="jessie" > debootstrap --arch=armhf --foreign $distro $targetdir Hast du das auf dem Target aufgerufen? Hab ein make linux-dirclean und linux-reconfigure ausgeführt. Nun ist der Kernel wieder kleiner geworden... Mal sehen, ob sich nun booten lässt....
Holger K. schrieb: > Mutluit M. schrieb: >> Wenn bei dir die Internetverbindung schon klappt: >> Ich hatte vor einiger Zeit das rootfs so übers Netz >> installiert:targetdir="/mnt/rootfs" >> distro="jessie" >> debootstrap --arch=armhf --foreign $distro $targetdir > > Hast du das auf dem Target aufgerufen? Nein, es war wohl auf dem PC, wahrscheinlich direkt auf die richtige Partition auf der SD-Karte. Das ganze liegt schon länger zurück, weswegen ich mich an die Details nicht mehr erinnern kann bzw. in meinen Aufzeichnungen nachsehen müsste.
Holger K. schrieb: > Mutluit M. schrieb: >> Wenn bei dir die Internetverbindung schon klappt: >> Ich hatte vor einiger Zeit das rootfs so übers Netz >> installiert:targetdir="/mnt/rootfs" >> distro="jessie" >> debootstrap --arch=armhf --foreign $distro $targetdir Das sollte normal auf dem hostsystem möglich sein (als root). Dann fehlt aber noch die second stage. Ich mache das in der regel in einem chroot, aber auf dem Target sollte das auch gehen. Ausprobiert hab ich letzteres aber noch nie. Der kernel sollte dann beim ersten boot das /sbin/init nicht finden, prüft dann noch ein paar andere Orte, und führt am Schluss vermutlich /bin/sh aus. Dann muss man vermutlich das bootstrapping auf dem target manuell noch abschliessen, mit "/debootstrap/debootstrap --second-stage". Aber eben, ich hab das noch nicht probiert, kann auch sein das der schritt dann auch schon automatisiert ist.
Ich glaube ich war damals nach folgender Anleitung vorgegangen: https://www.piprojects.net/debian-image-bauen/
Mutluit M. schrieb: > Nein, es war wohl auf dem PC, wahrscheinlich direkt auf die richtige > Partition auf der SD-Karte. Ok, das ist gut zu wissen.. Es läuft nun!!! Also eine kurze Zusammenfassung. - Linuxkernel war zuerst richtig gebuildet jedoch ohne tmpfs aktiviert. - in diesem zustand habe ich mehrere rootfs versucht, jedoch immer mit nachträglichem chown root:root Dies war falsch... - Nun also richtig kopiert, doch es bootet immer noch nicht wegen tmpfs. - Beim aktivieren von tmpfs hab ich das erstellen eines rootfs als cpio und das erstellen eines initramfs deaktiviert. Ab da, war der kernel nicht mehr 5.2Mb sonder 8.4Mb. Nach dem jetzigen booten, gab es keine Probleme mehr, jedoch wurde nicht das rootfs von der Karte gebootet sondern das an den Kernel angehängte. Warum es angehängt wurde, weiss ich nicht. - Nach mehrmaligem umschalten der konfigurationen in buildroot und make linux-reconfigure und linux-rebuild hat sich leider nichts geändert. Das minimale rootfs blieb im kernel. Durch deaktivieren von tmpfs wurde das image minimal kleiner (ca. 100kbyte) gebootet wurde aber immernoch das angehängte rootfs. Also nach mehreren versuchen dann - make linux-dirclean und make linux-reconfigure Diesesmal wieder mit ausgeschaltetem initramfs. genau wie zuvor. Und, siehe da, der Kernel wurde 5.2Mb gross. Doch, es bootete noch immer nicht, da tmpfs unbekannter Befehl sei... Ach ja, durch linux-dirclean wurde auch die kernelconfig tmpfs entfernt. Also nochmals tmpfs aktiviert und kernel erzeugt. Nun +100kb. Gebootet und... Endlich!!! Armbian lebt ^^ Es ging also so ziemlich alles schief was möglich war. Aber gelernt habe ich sehr viel! Danke wiedermal an alle Unterstützer!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.