-
Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr
NomadBSD - ein LiveUSB-System basierend auf FreeBSD 11.1
- Themenstarter marcel
- Beginndatum
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
Es sieht auch irgendwie stark danach aus als wollte er unbedingt nVidia-Treiber laden. Das x220 hat aber natürlich kein nVidia-Chip.
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)
Themenstarter
#61
Danke für die Rückmeldung, @Rakor!
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.
Ja, unbedingt. Werde ich auch gleich machen.
Könntest Du mal bitte die Ausgabe von
posten? Ist das nvidia-Modul geladen?
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.
Ja, unbedingt. Werde ich auch gleich machen.
Könntest Du mal bitte die Ausgabe von
Code:
% pciconf -lv | grep -B 3 display | grep devicelustiges 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.
sagt:
Achso und die Shell-Auswahl ist klasse... Leider ist kein fish dabei 
Also nvidia.ko ist geladen.
Code:
pciconf -lv | grep -B 3 display | grep device
Code:
device = '2nd Generation Core Processor Family Integrated Graphics Controller'
Themenstarter
#63
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.
Ja, es war, wie zu erwarten ein kleines Problem in nvidia_setup. Es fehlte bei grep nur das -w Flag.
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
Ja, es war, wie zu erwarten ein kleines Problem in nvidia_setup. Es fehlte bei grep nur das -w Flag.
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 /mntHey 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.
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.
Themenstarter
#67
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.
Themenstarter
#69
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 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.
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.
Das stimmt. Da wäre ne Deduplication schön. Aber da wüsste ich aktuell keine Lösung für.
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? 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.
Themenstarter
#71
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.
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.
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.
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.
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.
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.
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.
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.