1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

USB-Stick als FreeBSD-Installationsmedium plus Repo

Dieses Thema im Forum "FreeBSD - Allgemein" wurde erstellt von holgerw, 20 November 2017.

  1. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hallo,

    mal eine Frage:

    Ich baue mir ja per poudriere mein plasma5 Repo. Nun möchte ich neben dem Speicherort auf unserem Daten-Nas dieses Repo für unterwegs auf USB-Stick gerne mitnehmen.

    Super wäre es nun, wenn ich den selben Stick als FreeBSD-Installationsmedium nutzen kann.

    Geht das und wenn ja, wie?

    Viele Grüße
    Holger
     
  2. mordin

    mordin New Member

    Registriert seit:
    31 August 2017
    Beiträge:
    25
    Das sollte eigentlich ganz einfach funktionieren. Ausprobiert habe ich das aber nicht :p
    1. dd ein memstick.img auf den Stick
    2. gpart recover da0 (um den zweiten GPT-Header ans Ende des Sticks zu "verschieben")
    3. Neue Partition erstellen: gpart add -t freebsd-ufs -i 5 -l plasma5repo da0
    4. newfs /dev/da0p5
    5. Partition mounten und Repo kopieren
    Dem Installer ist die neue Partition hoffentlich egal...
     
    holgerw gefällt das.
  3. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hallo @morodin

    danke für die Info. Dann sollte es ja auch möglich sein, nach der Installation per chroot ins frische System zu wechseln (der Installer bietet das für Nachkonfigurationen sogar bequem an), das Repo zu mounten und das gesamte Userland dann darüber zu installieren - ganz ohne Internetverbindung.

    Oh das wäre richtig klasse, da habe ich was zum Testen an meinem alten TP R500 Notebook, denn da soll neben einem Void-Linux wieder ein FreeBSD mit plasma5 drauf.
     
  4. ralli

    ralli Well-Known Member

    Registriert seit:
    1 Juni 2012
    Beiträge:
    1.771
    Im Handbuch Kapitel 17.4 - USB Speichermedien steht:

    Also bei Haswell Architektur könnten Schwierigkeiten auftreten. Im übrigen ist das Problem mittlerweile gelöst und funktioniert es?
     
  5. Lance

    Lance Member

    Registriert seit:
    26 Oktober 2015
    Beiträge:
    364
    Moin,
    hätte dazu auch mal Fragen. Reicht es für ein Repo einfach die Pakete samt Abhängigkeiten wo hinzukopieren? Denke eher nicht. Oder schaut FreeBSD automatisch in dem Verzeichnis, von wo aus man Paket XY installiert (mit "pkd add Paket.txz) automatisch auch nach Abhängigkeiten in diesem Verzeichnis? Oder brauche ich die Variable
    Code:
    env REPOS_DIR=
    vor einem "pkg install Paket" ?

    LG Lance
     
  6. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hallo,

    leider geht das nicht, ich habe das Image mit dd auf einen 8G großen Stick gepackt (da4), dann:
    Code:
    gpart recover da4
    da4 recovered
    Dann:
    Code:
    gpart show da4
    =>       3  15720437  da4  GPT  (7.5G)
             3      1600    1  efi  (800K)
          1603       118    2  freebsd-boot  (59K)
          1721   1504448    3  freebsd-ufs  (735M)
       1506169      2048    4  freebsd-swap  (1.0M)
       1508217  14212223       - free -  (6.8G)
    Dann aber:
    Code:
    gpart add -t freebsd-ufs -i 5 -l plasma5repo da4
    gpart: index '5': Invalid argument
    Ohne -i und mit Größenangabe:
    Code:
    gpart add -t freebsd-ufs -l plasma5repo -s 5g da4
    gpart: index '5': No space left on device
    Hmm, und wie jetzt weiter?
     
  7. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    Eigentlich hätte ich auch erwartet, dass das funktionieren würde.
    Nun phantasiere ich mal ein wenig rum, das heißt, so habe ich das selbst noch nie gemacht, aber immerhin schon mal so ähnlich. Damals brauchte ich ein FreeBSD-Bootonly von einem Stick und es gab noch keine entsprechenden Images von offizieller Seite.

    Du kannst ein md-device anlegen, dann dd dein memstick-image dorthin.
    Den Stick mit gpart einrichten, vollständig und mit der zusätzlichen Partition, aber die sonstigen Partitionen belassen.
    Dann, was man braucht, vom md-Device nach Stick mit rsync.

    Ich skizziere bewusst mal nur einen Plan.
    Statt eines md-Gerätes kann natürlich auch ein zweiter Stick benutzt werden.
    Wenn man das memstick-Image in der Art eines ISO einem md-Gerät zuordnen und direkt mounten kann, würde das vielleicht auch genügen. Ich glaube nicht, dass das geht, weil die Struktur doch anders ist. Ähm. Aber warum eigentlich nicht? Probieren geht über studieren...

    Also, der tiefere Sinn ist jeweils, dass man seinen Stick erst mal vorbereitet und einrichtet und nicht die vorgegebene Struktur des Images mit dd übernimmt, sondern dann nur noch den Inhalt des Images auf den vorbereiteten Stick überträgt.
    gpart richtet ja auch den Bootcode schon passend ein, ansonsten könnte man vielleicht auch mit dd aus dem "entpackten" image was übertragen, was dann aber wieder etwas komplizierter wird.
     
  8. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    ich habe auch nicht vor, ernsthaft an dem Problem zu arbeiten, aber ich war eben doch neugierig und habe ein bei mir noch vorhandenes memmstig.img mal probiert:
    Code:
    pit@senyo ~:- > mdconfig -a -t vnode -f /usr/home/Download-pit/FreeBSD-11.1-RELEASE-amd64-mini-memstick.img
    md0
    
    pit@senyo ~:- > mmls -B /dev/md0
    GUID Partition Table (EFI)
    Offset Sector: 0
    Units are in 512-byte sectors
    
      Slot  Start  End  Length  Size  Description
    000:  Meta  0000000000  0000000000  0000000001  0512B  Safety Table
    001:  -------  0000000000  0000000002  0000000003  0001K  Unallocated
    002:  Meta  0000000001  0000000001  0000000001  0512B  GPT Header
    003:  Meta  0000000002  0000000002  0000000001  0512B  Partition Table
    004:  000  0000000003  0000001602  0000001600  0800K  
    005:  001  0000001603  0000001720  0000000118  0059K  
    006:  002  0000001721  0000641464  0000639744  0312M  
    007:  003  0000641465  0000643512  0000002048  1024K  
    008:  -------  0000643513  0000643514  0000000002  1024B  Unallocated
    
    pit@senyo ~:- > ls /dev | grep md0
    md0
    md0p1
    md0p2
    md0p3
    md0p4
    pit@senyo ~:- > file -s /dev/md0p1
    /dev/md0p1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4  ", root entries 512, sectors 1575 (volumes <=32 MB) , sectors/FAT 5, sectors/track 63, heads 1, serial number 0x5b811818, label: "EFI  ", FAT (12 bit), followed by FAT
    pit@senyo ~:- > file -s /dev/md0p2
    /dev/md0p2: data
    pit@senyo ~:- > file -s /dev/md0p3
    /dev/md0p3: Unix Fast File system [v1] (little-endian), last mounted on , last written at Fri Jul 21 02:23:45 2017, clean flag 1, number of blocks 319872, number of data blocks 318271, number of cylinder groups 6, block size 8192, fragment size 1024, minimum percentage of free blocks 8, rotational delay 0ms, disk rotational speed 60rps, TIME optimization
    pit@senyo ~:- > file -s /dev/md0p4
    /dev/md0p4: data
    pit@senyo ~:- > gpart show md0
    =>  3  643510  md0  GPT  (314M)
      3  1600  1  efi  (800K)
      1603  118  2  freebsd-boot  (59K)
      1721  639744  3  freebsd-ufs  (312M)
      641465  2048  4  freebsd-swap  (1.0M)
    
    Gleichzeitig erschienen dann Geräte in DSBMC (mit Anlegen des md-Gerätes):
    screenshot-2017.12.02-135613.jpg
    und ich konnte die auch wie üblich durch Doppelklick mounten:
    Code:
    pit@senyo ~:- > mount | grep md0
    /dev/md0p1 on /media/EFI (msdosfs, local, nosuid, synchronous, mounted by pit)
    /dev/md0p3 on /media/FreeBSD_Install (ufs, local, noatime, nosuid, mounted by pit)
    
    Natürlich wäre das auch manuell möglich gewesen.

    freebsd-swap macht mir keine Sorgen. Ich persönlich ließe das eh weg.
    freebsd-boot, da kenne ich mich nun zu wenig aus damit. Ich sehe das, also die entsprechende Partition, aber ich habe noch nie gesehen, dass man die auch mounten könnte. Es sieht hier nicht so aus und es scheint auch nicht so unbedingt nötig zu sein. Wenn ich einen Stick mit gpart ja vollständig einrichte, also die gewünschten Partitionen einrichte und anlege und formatiere und dann den bootcode schreibe, dann müsste das ja alles so auch richtig sein und funktionieren.
    Ich würde da kein SWAP nehmen und dann also auf dem Stick freebsd-boot, efi, freebsd-ufs und nochmal freebsd-ufs einrichten und eben formatieren.
    Dann einhängen und mounten und aus dem ebenfalls gemounteten md-Gerät mit rsync (oder was auch immer, dump|restore, drag_n_drop...) alle Daten kopieren.

    Keine Ahnung, ob das funktionieren kann.
    Wie gesagt, die erste Methode hielt ich eigentlich auch schon für gut und glaubte, dass es so gehen müsste.
    Warum es nicht geht, kann ich mir nicht wirklich erklären, vermute aber, dass es mit dem GPT zusammenhängt. Der erste wird ja nicht erstellt, sondern mit dem Image ausgeliefert und der passt vielleicht irgendwie genau dazu. Nun verändern wir da nichts und wollen mit gpart recover nur den zweiten GPT ans Ende des Sticks legen und vielleicht geht hierbei was schief, weil das "Ende des Sticks" nicht wirklich erkannt wird.
    Deshalb will ich eine Methode vorschlagen, die beide GPT gleich von Anfang an auf einem Stick richtig und passend anlegt und das mal probieren.

    edit: es fehlten ein paar Zeilen im ersten Code-Block
     
    holgerw gefällt das.
  9. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    mal noch ein ein wenig Feedback (wenn einen etwas interessiert, kann man manchmal nicht anders und spielt weiter...)
    ich habe mir einen Stick hergenommen und die alte Information mit einigen Nullen überschrieben und dann mit gpart so eingerichtet, wie ich das oben vorgeschlagen hatte, die Dateisysteme formatiert (newfs-msdos ohne jede Option für efi -ergibt FAT12, wie in der Vorgabe und das passt scheinbar auch, ufs wie in der man-page zu gpart mit newfs -Uj (ohne nachgesehen zu haben, was das bedeutet) und das nochmal und ohne SWAP). Bootcode geschrieben.
    Dann habe ich den neuen Stick gemountet, also nacheinander die einzelnen Partitionen und das gelang.
    Dann mit rsync das EFI (aus md0p1) überspielt, keine Probleme.
    Dann mit rsync das System überspielt (aus md0p3), nicht genug Platz im Ziel. Als ich hinsehe, ist das neue Dateisystem in UFS2 und die Vorgabe ist angeblich UFS1. Außerdem habe ich mir gar nichts vorher angesehen, keine Optionen. Ich würde nicht ein Journal auf einem Stick haben wollen (grundsätzlich ja nicht, aber auf Stick erst recht nicht).
    Der rsync brach also an der Stelle mit Fehlern ab. Ich werde da vermutlich auch nicht weiter machen.

    Trotzdem versuchte ich einen Boot und der fing auch gut an, aber dann:
    Im memstick.img wird offenbar mountfrom ufs:/dev/ufs/FreeBSD_Install erwartet und ich hatte keinen Label gesetzt. Wer das also ernsthaft versuchen möchte, sollte das gleich richtig machen. Einen passenden Label zu benutzen, ist die einfachste Lösung. Einfach dem newfs mitgeben. Ich wiederhole nochmal:
    FreeBSD_Install
    Außerdem, wie gesagt, die Partition war zu klein und ich sehe keinen Grund, warum man sie nicht auch etwas größer anlegen könnte. Ich wollte nur möglichst nah bei der Vorgabe bleiben.

    Wieso ich nun nicht einfach mein gültiges device für das root-Dateisystem angebe und sehe, ob das alles weiter läuft?
    Weil es genau an der Stelle nun hängt. ufs ist noch nach Tastatur-Eingabe erschienen, doch seither hängt der Rechner so.
    Das kann an dem nicht vollständig übertragenen System liegen, oder daran, dass ich keine SWAP genommen habe oder sonstwo. Es gibt keine Panic und dergleichen. einfach nur Hängen.

    Als nächstes habe ich versucht, das Label auf dem Stick zu ändern, aber ich erhalte nur
    Code:
    pit@senyo /home/pit:-# tunefs -L FreeBSD_Install /dev/da1p3
    tunefs: bad volume label. Valid characters are alphanumerics.
    deshalb änderte ich die fstab nach /dev/da0p3 und das hat eben gebootet, ich bin im Installer gelandet.
    Von dort gleich in die shell, Dateisystem rw gemountet, Mountpoint angelegt und die zusätzliche ufs-Partition vom Stick gemountet und sogar hin geschrieben, funktioniert.

    Ich denke, das hört sich zunächst mal vielversprechend an. Vielleicht mit Fallstricken und einigen Dingen, die man noch verbessern kann und vielleicht noch etwas nachdenken, aber grundsätzlich bootet der so angelegte Stick das memstick-System und hat noch eine weitere, benutzbare Partition für irgendwas, vielleicht ein repo.
    Weil man die fstab zugänglich hat, kann man sie auch ändern. Also auch das repo direkt irgendwo einbinden. Wenn man das möchte usw...
     
    holgerw gefällt das.
  10. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    Ich hatte übrigens nicht nachgesehen, ob im EFI-Modus gebootet worden war. Der Test-PC kann beides, schaltet automatisch um und ich habe keinen Zugriff auf das Bios und seine Einstellungen.
    Deshalb habe ich eben nochmal kurz in einem Mac-Book probiert, bevor ich den Stick wieder vernünftig einrichte und der ist natürlich im EFI-Modus sauber gebootet.
    Nun habe ich also nicht explizit einen NON-Efi-Modus getestet und auch keinen PC dafür frei (die sind alle 32 Bit).
    Ahnäh! Fällt mir eben ein. Einen hatte ich doch noch frei und der bootet gerade im BIOS Modus von diesem Stick ins Install-System. geht als auch.

    Denk mal drüber nach. Ich glaube, dass das ein guter Ansatz ist und du damit deine Aufgaben lösen kannst.
     
    holgerw gefällt das.
  11. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    Also dann, noch einen: mein letzter Test mit diesem Stick war es jetzt, doch noch Label zu nutzen und ich habe einfach FreeBSDInstall für die SystemPartition und MyRepo für die freie zusätzliche Partition genommen und dann entsprechende Einträge in der fstab gesetzt. Mit tunefs war es nicht möglich, der Vorgabe FreeBSD_Install zu folgen. Der "_" wird wohl nicht akzeptiert.
    So funktioniert es aber problemlos und ohne Murren und wie erwartet. Die beiden vorhandenen Dateisysteme werden wie gewünscht eingebunden und stehen direkt im Installationssystem zur Verfügung.

    Für den Fall der Nachahmung will ich hier vorsorglich noch eine Ausgabe zur Orientierung hineinstellen:
    Code:
    pit@senyo ~:- > tunefs -p /dev/md0p3
    tunefs: POSIX.1e ACLs: (-a)  disabled
    tunefs: NFSv4 ACLs: (-N)  disabled
    tunefs: MAC multilabel: (-l)  disabled
    tunefs: soft updates: (-n)  disabled
    tunefs: soft update journaling: (-j)  disabled
    tunefs: gjournal: (-J)  disabled
    tunefs: trim: (-t)  disabled
    tunefs: maximum blocks per file in a cylinder group: (-e)  2048
    tunefs: average file size: (-f)  16384
    tunefs: average number of files in a directory: (-s)  64
    tunefs: minimum percentage of free space: (-m)  8%
    tunefs: space to hold for metadata blocks: (-k)  0
    tunefs: optimization preference: (-o)  time
    tunefs: volume label: (-L)  FreeBSD_Install
    
    Dies ist die System-Partition aus dem memmstick.img und die hat gegenüber den Standard-Parametern vor allem:
    Code:
    tunefs: maximum blocks per file in a cylinder group: (-e)  2048
    Bei meinen neu angelegten UFS-Systemen ist dieser Wert default auf 4096. Ich vermute, dass daher der Platz nicht ausreichte.
    Für das Anlegen eines neuen Dateisystems auf dem Stick würde ich nun deshalb diesen Vorgaben folgen und trotzdem noch ein wenig mehr Platz vorsehen, als im memstick.img vorgesehen, einfach, um auf Nummer sicher zu gehen. Mit einem teilweise übertragenen System, wie auf meinem Teststick, würde ich mich ganz unwohl fühlen. (Nebenbei: im Installations-System könnte man auch einige Dinge wegstreichen, nur das macht mehr Arbeit und kostet Zeit).
     
    holgerw gefällt das.
  12. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hallo Pit,

    danke für Deine Experimentierbereitschaft. Ich werde das nach gründlicher Lektüre Deiner Kommentare hier noch mal probieren.
     
  13. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    Code:
    pit@senyo ~:- > gpart show da1
    =>  40  16052144  da1  GPT  (7.7G) [CORRUPT]
      40  1600  1  efi  (800K)
      1640  118  2  freebsd-boot  (59K)
      1758  638976  3  freebsd-ufs  (312M)
      640734  15411450  4  freebsd-ufs  (7.3G)
    Bin eben dabei, den Stick wieder gebrauchsfertig zu machen und zeige eben noch die von mir benutzte Partitionierung. Dass der GPT als CORRUPT angezeigt wird, bitte ich zu ignorieren, zu dem Zeitpunkt hatte ich den Bereich mit Nullen überschrieben und es wirkt hier der zweite GPT für diese Ausgabe.
    Wie gesagt, Partition 3 für das Memmstick-System würde ich nun größer wählen.
     
  14. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    so, ich glaube, ich muss meinen PC mal ausschalten und habe eben noch aus der Historie die Befehle zusammengesucht und stelle sie hier mal her, das erklärt oft mehr, als meine Texte, aber, bitte nicht als CP-n-Paste Anweisung verstehen. Ich habe nur in der Historie nachgesehen und natürlich auch einige Fehlversuche absolviert:
    Code:
    gpart create -s GPT da1
    gpart add -b 40 -s 800k -t efi da1
    gpart add -s 59k -t freebsd-boot da1
    gpart add -s 312M -t freebsd-ufs da1
    gpart add -t freebsd-ufs da1
    newfs_msdos /dev/da1p1
    gpart bootcode -p /boot/gptboot -i 2 da1
    newfs -Uj /dev/da1p3
    newfs -Uj /dev/da1p4
    
    Das habe ich alles mehr oder weniger aus dem Handbuch (der man-page) selbst per CP-n-Paste übernommen und vorher nicht nachgeschaut, was die Optionen genau bewirken. Ich habe alles einfach gehalten.
    Die Optionen -Uj beim Anlagen des UFS sind genau verkehrt, ich gebe sie hier wieder und mache aber darauf aufmerksam. Es funktioniert so schon, aber besser ist, man macht es gleich richtig (wofür ich aber auch erst nachlesen müsste) oder korrigiert gleich mit tunefs. Mich stören halt vor allem die Journals.
     
  15. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.237
    Ich habe eben einen Stick mit einem Ghost-BSD-Image, das ich mittels dd darauf gelegt hatte und der zeigte mir in dmesg:
    Code:
    GEOM: da1: the secondary GPT header is not in the last LBA.
    GEOM: iso9660/GhostBSD: the secondary GPT header is not in the last LBA.
    GEOM: diskid/DISK-077B0D0A081E: the secondary GPT header is not in the last LBA.
    
    Das erinnerte mich wieder hieran und ich versuchte dann, nach der Methode auf dem Stick eine neue Partition anzulegen. Nach gpart recover nahm ich den Stick weg und steckte dann wieder ein. Ein erneuter blick in dmesg zeigte dann, dass es keine Fehlermeldung wie oben mehr gab.
    So sah das aus:
    Code:
    pit@senyo /home/pit:-# gpart show da1
    =>  64  16052096  da1  GPT  (7.7G)
      64  1552  1  ms-basic-data  (776K)
      1616  5760  2  efi  (2.8M)
      7376  4903580  3  ms-basic-data  (2.3G)
      4910956  11141204  - free -  (5.3G)
    
    Dann fügte ich eine Partition ein und formatierte die und kann sie in FreeBSD auch nutzen.
    Code:
    pit@senyo ~:- > gpart show da1
    =>  64  16052096  da1  GPT  (7.7G)
      64  1552  1  ms-basic-data  (776K)
      1616  5760  2  efi  (2.8M)
      7376  4903580  3  ms-basic-data  (2.3G)
      4910956  11141204  4  freebsd-ufs  (5.3G)
    
    Sie ist in FAT32 formatiert, aber als Partitionstyp konnte ich fat32 nicht wählen.

    Also, jedenfalls ging das schon grundsätzlich wie oben beschrieben und ich finde es merkwürdig, dass holgerw mit seinem Versuch kein Glück hatte.
     
    mordin gefällt das.