NomadBSD - ein LiveUSB-System basierend auf FreeBSD 11.1

Die /root/.login und nvidia_setup habe ich korrigiert/erweitert. Wenn das jetzt funktioniert, werde ich, da die Pakete für nvidia-driver-{304,340} recht groß sind, sie in ein uzip packen, und dieses bei Bedarf unter /nvidia mounten.
 

Anhänge

  • dot.login.txt
    567 Bytes · Aufrufe: 264
  • nvidia_setup.txt
    15,1 KB · Aufrufe: 397
So, erster Versuch unter Linux/KVM (ich weiß, dass es dafür nicht gedacht ist) endet bei "Starting XOrg..." wo ich dann in einer root-Shell lande. Schade. Werde es als nächstes mal doch auf nem Stick testen. Kann es nur efi booten oder geht auch ein gutes altes BIOS?
 
So, erster Versuch unter Linux/KVM (ich weiß, dass es dafür nicht gedacht ist) endet bei "Starting XOrg..." wo ich dann in einer root-Shell lande.
So weit bin ich bei meinem Versuch in VirtualBox nicht gekommen. Da müsste man mal genauer rein schauen, wo es da hängt.
Werde es als nächstes mal doch auf nem Stick testen. Kann es nur efi booten oder geht auch ein gutes altes BIOS?
Der Stick bootet auch auf Systemen ohne EFI. Mein altes Asus Eee PC 1015px läuft wunderbar damit.
 
Also per USB-Stick auf dem X220 getestet: Selbes Ergebnis. Er läuft sauber durch und wenn er den X starten will passiert nix und endet dann in der root-Shell.
 
Also ich hab es zwischenzeitlich mal ganz kurz auf dem T61 getestet, da hat alles gut funktioniert. Nach 10 Minuten Test kann ich aber noch nicht viel dazu sagen. Außer,
dass es evtl. nicht schlecht wäre keine offenen root-Shells zu haben und, das man das Beepen der Konsole abschalten könnte (aber das ist natürlich Geschmackssache)

Auf dem x220 hab ich es nochmal versucht. Das Xorg-Log sagt
Code:
No devices detected
no screens found(EE)

Es sieht auch irgendwie stark danach aus als wollte er unbedingt nVidia-Treiber laden. Das x220 hat aber natürlich kein nVidia-Chip.
 
Danke für die Rückmeldung, @Rakor!
Außer,
dass es evtl. nicht schlecht wäre keine offenen root-Shells zu haben
Ich habe /root/.login um den Befehl lock -npv erweitert. Damit ist die Root-Shell zu. Werde dann noch autologin auf den anderen beiden Terminals deaktivieren.
und, das man das Beepen der Konsole abschalten könnte
Ja, unbedingt. Werde ich auch gleich machen.

Es sieht auch irgendwie stark danach aus als wollte er unbedingt nVidia-Treiber laden. Das x220 hat aber natürlich kein nVidia-Chip.
Könntest Du mal bitte die Ausgabe von
Code:
% pciconf -lv | grep -B 3 display | grep device
posten? Ist das nvidia-Modul geladen?
 
lustiges Phänomen auf dem x220. Wenn ich ein Medium einmal gebootet habe kann ich es anscheinend nicht nochmal booten. Ich muss es dann wieder neu per dd schreiben, dann kann ich wieder einmal booten... Sehr komisch. Sieht irgendwie so aus als findet er keinen Bootcode.

Also nvidia.ko ist geladen.

Code:
pciconf -lv | grep -B 3 display | grep device
sagt:
Code:
device = '2nd Generation Core Processor Family Integrated Graphics Controller'

Achso und die Shell-Auswahl ist klasse... Leider ist kein fish dabei :)
 
lustiges Phänomen auf dem x220. Wenn ich ein Medium einmal gebootet habe kann ich es anscheinend nicht nochmal booten. Ich muss es dann wieder neu per dd schreiben, dann kann ich wieder einmal booten... Sehr komisch. Sieht irgendwie so aus als findet er keinen Bootcode.
Es scheint so zu sein, dass bei einem gpart recover das Attribut lenovofix entfernt wird. gpart recover wird vor dem anlegen der home-Partition ausgeführt. Ein gpart set -a lenovofix da0 (da0 als root-Device angenommen) nach dem Setup sollte das Problem beheben. Ich habe das Setup-Skript indes schon angepasst.

Also nvidia.ko ist geladen.

Code:
pciconf -lv | grep -B 3 display | grep device
sagt:
Code:
device = '2nd Generation Core Processor Family Integrated Graphics Controller'
Ja, es war, wie zu erwarten ein kleines Problem in nvidia_setup. Es fehlte bei grep nur das -w Flag.

Achso und die Shell-Auswahl ist klasse... Leider ist kein fish dabei
Habe ich natürlich gleich mit rein gemacht :)

Die geänderten Dateien habe ich in ein Archiv gepackt, mit dem man Version 1.0 einfach patchen kann. Lediglich die Datei herunterladen, den Stick einhängen und das Archiv entpacken
Code:
# (cd /tmp && fetch http://freeshell.de/~mk/download/nomadbsd-1.0-patch.tgz)
# mount /dev/gpt/nomadroot /mnt/
# (cd /mnt && tar xf /tmp/nomadbsd-1.0-patch.tgz)
# umount /mnt
 
Hey perfekt, funktioniert. Danke marcel.
Ich werde das Ganze bei Gelegenheit mal genauer testen müssen, aber es gefällt mir schonmal sehr gut. Wirkt aus einem Guss.

Durch den Lock auf tty0 kann man nur leider nicht mehr zurück in den X welchseln ohne sein Rootkennwort eingegeben zu haben.... Aber das sind Details.
 
Hey perfekt, funktioniert. Danke marcel.
Ich werde das Ganze bei Gelegenheit mal genauer testen müssen, aber es gefällt mir schonmal sehr gut. Wirkt aus einem Guss.
Danke Dir. Das lese ich gern :)
Durch den Lock auf tty0 kann man nur leider nicht mehr zurück in den X welchseln ohne sein Rootkennwort eingegeben zu haben.... Aber das sind Details.
Habe ich gleich korrigiert. Es muss nur das -v Flag von lock in /root/.login entfernt werden, um das Problem zu beheben.

An Verbesserungsvorschlägen, Softwarewünschen, etc. bin ich stets interessiert.
 
Wie sieht es eigentlich mit Updates aus und der Installation von Software aus? Gibts da geschmeidige Optionen oder ne Planung?
 
Wie sieht es eigentlich mit Updates aus und der Installation von Software aus? Gibts da geschmeidige Optionen oder ne Planung?
Ich arbeite gerade an einem Skript, dass teilautomatisierte Updates der Konfigurationsdateien und Skripten durchführen soll, etwa so wie mergemaster. Software-Installationen -und Updates sind allerdings ein Problem, denn die installierten Pakete befinden zwecks Speicherplatzeinsparung in einem unveränderlichen uzip-Image. Ohne uzip würde die installierte Software alleine schon 5GiB in Anspruch nehmen. Man könnte unter /home, bzw /private ein beschreibbares software Verzeichnis anlegen, das per unionfs über /usr/local gelegt wird. Dadurch könnte man dann zusätzliche Software installieren. Aber ein Upgrade bestehender Software wäre damit auch nicht möglich.
 
Wieso wäre damit ein Update bestehender Software nicht möglich?
Wäre eine Option beim Einrichten möglich, dass er statt dem uzip ein normales FS nutzt? In Zeiten von 64GB- Sticks ist Platz relativ geworden.
 
Wieso wäre damit ein Update bestehender Software nicht möglich?
Ich hätte schreiben müssen: prinzipiell möglich, aber praktisch nicht sehr schön, weil man so im schlechtesten Fall nochmal alle Pakete unter /home/software installiert hätte.
Wäre eine Option beim Einrichten möglich, dass er statt dem uzip ein normales FS nutzt?
Das ließe sich relativ leicht machen, könnte allerdings eine Ewigkeit dauern, da viele einzelne Dateien geschrieben werden müssen. Man müsste mal ein grobes Benchmark machen.
 
Ich hätte schreiben müssen: prinzipiell möglich, aber praktisch nicht sehr schön, weil man so im schlechtesten Fall nochmal alle Pakete unter /home/software installiert hätte.
Das stimmt. Da wäre ne Deduplication schön. Aber da wüsste ich aktuell keine Lösung für.

Das ließe sich relativ leicht machen, könnte allerdings eine Ewigkeit dauern, da viele einzelne Dateien geschrieben werden müssen. Man müsste mal ein grobes Benchmark machen.
Naja, sollte nicht viel länger dauern als eine initiale Installation auf dem Medium, oder? Man könnte dann auch evtl vom Bootloader aus sagen "zurücksetzen" und dann das FS einmal neu schreiben lassen um auf den Anfangszustand zurück zu kommen.
Updates halte ich schon für wichtig um den Schritt vom "Notfallmedium" zum "Produktiven Mobilmedium" zu bekommen. Sonst müßtest du wegen jedem Sicherheitslückchen immer ein neues Image bauen.

Oder ein Script welches da Image automatisch aus den aktuellsten Komponenten zusammenbaut. Dann hast du aber das Problem, dass du nie sicher sein kannst ob die zur Verfügung gestellte Version auch rund läuft.
 
Naja, sollte nicht viel länger dauern als eine initiale Installation auf dem Medium, oder?
Ich hatte mal ein paar Tests mit einem diese Abfall-Sticks von Rossmann gemacht, um die Dateisystemparameter für USB-Sticks zu optimieren. Das Entpacken des FreeBSD-Source (src.txz) dauerte etwa eine Stunde, und das sind dann etwa 1,2GiB. Nichtsequentielle Schreibzugriffe sind auf solchen Flashmedien ein Alptraum.
Während ich das hier schreibe, bereite ich gerade einen Test auf einem 32GiB Toshiba-Stick vor. Mal sehen, ob das mit den aktuellen Dateisystem-Flags und dem GEOM disk scheduler etwas besser läuft. Werde dann gleich berichten.

Updates halte ich schon für wichtig um den Schritt vom "Notfallmedium" zum "Produktiven Mobilmedium" zu bekommen.
Sehe ich auch so. Zumindest lässt sich das System bald per nomadbsd-update (in Arbeit) in Sachen Konfigurationsdateien und System-Skripten auf den neusten Stand bringen. Aber was das Update der installierten Pakete betrifft, fällt mir im Moment einfach nichts wirklich praktikables ein, außer, dass sich der Benutzer z.B. per Update-Skript das neuste uzip herunterlädt. Allerdings ist das fast so groß wie das gesamte Image. Andererseits ist so sichergestellt, dass alles konsistent ist.
 
Wie sieht es eigentlich mit Updates aus
Da möchte ich mal meine Erfahrungen mit Knoppix einwerfen und als Beispiel nennen.
Die haben ja grundsätzlich das gleiche Problem, wenngleich sie Debian als Basis nutzen und definitiv eher eine Demo sein wollen, als ein Notfall-System.
nomadbsd habe ich (leider) bisher noch nicht getestet und angesehen (außer kurz darin gestöbert), doch die verwendeten und beschriebenen Technologien erscheinen mir durchaus verwandt zu jenen, die in Knoppix genutzt werden und die die für Live-Systeme wirklich extrem nützlich sind.

Bei Knoppix gibt es einfach regelmäßig neue Versionen und keine Updates zu laufenden Versionen.
Es wird ganz genau auch darauf hingewiesen, dass dies nicht sinnvoll ist und sogar das System zerstören kann, was sicher auch daran liegt, dass Knoppix immer auch Pakete von außerhalb des Debian-Branches einbindet und auch Entwicklerpakete nutzt. Es hat nicht den Anspruch sicher und stabil zu sein, es will zeigen, was mit einem GNU/Linux so geht.
Nun finde ich diese Zielsetzung nicht unbedingt nachahmenswert.

Aber den Ansatz, dass eben die aktuelle Live-Version so bleibt, wie sie ist und keine (System)-Updates erfolgen, bis es eine neue Version gibt, den halte ich für durchaus vertretbar und nachahmenswert.


Knoppix bietet noch was sehr Gutes, das ich bisher noch nicht ausprobiert habe und nur durchgelesen.
Es gibt ein "Remastering-Script" (mit der letzten Version 8.1 erstmals offiziell integriert).
Knoppix nutzt UNIONFS, bzw AUFS und stellt das System komplett aus bisher (maximal) drei Teilen zusammen: KNOPPIX, KNOPPX1 und KNOPPIX-DATA. Die Aufspaltung in KNOPPIX und KNOPPIX1 ist notwendig, weil es auf einem FAT zu liegen kommen soll und das kann nur 4G. KNOPPIX-DATA ist die optionale und sogenannte OVERLAY(Partition). Früher wurde das oft als "persistente- Home-Partition" bezeichnet, weil es eben den Ausschaltvorgang überlebte. Im laufenden System sind alle Teile eingebunden (wie ich lese also synonym zu nomadbsd) und damit auch alle durchgeführten Änderungen aktiv.
Dieser Zustand kann nun durch das Remastering-Script aufs Neue "eingefroren" und neue, komprimierte Images (in 4G Blöcken) erzeugt werden. Damit erhält man dann eine Art personalisiertes Knoppix und wer sich die Mühe macht, viel Ballast zu verwerfen, wird entsprechend auch ein kleineres System erhalten.
Wie ich es bisher verstanden habe, lebt nomadbsd alleine auf einem Stick. Knoppix ist so gedacht, dass es einfach von einem normalen FAT booten kann und der komplette Rest des Sticks weiter (auch für andere Systeme) als Austauschmedium verfügbar ist.
Ich liebe dieses Konzept.

Demnächst in diesem Theater werde ich mir auch nomadbsd mal ansehen.
Derzeit warte ich noch ein wenig die aktuellen Entwicklungen ab, bevor ich es wieder mit einem Download versuche. Sorry for that.

Aber ein echt cooles Projekt und sehr genau passend zu meinen eigenen Gedanken, die ich seit genauerer Betrachtung von Knoppix in Zusammenhang mit FreeBSD hatte. Mir fehlte jegliche Kompetenz dazu. Dass @marcel das nun gerade macht, ist einfach toll. Ich bin einfach begeistert, leider bisher nur als Zuschauer.
 
An Verbesserungsvorschlägen, Softwarewünschen, etc. bin ich stets interessiert.
einer meiner Lieblinge wird oft nicht eingebaut: sysutils/sleuthkit
Typischerweise werden ja Live-Systeme oft zur Inspektion von Systemen benutzt und da ist der sleuthkit mir sehr hilfreich gewesen (früher häufiger, als heute).

Außerdem ist photorec aus sysutils/testdisk für mich quasi ein Standard in einem Live-System, wenngleich die Tools selten benutzt werden.

edit:
sysutils/ddrescue
benchmarks/bonnie++
sollten auch dabei sein.
 
Zu meinem Test, das FreeBSD-Source-Archiv auf dem Stick zu entpacken: Es dauerte 96 Minuten. Damit ist die Variante, das uzip auf dem Stick zu entpacken, leider an den Gegebenheiten gescheitert.
 
Zurück
Oben