USB-Stick als FreeBSD-Installationsmedium plus Repo

[holgerw]

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

 

[mordin]

Das sollte eigentlich ganz einfach funktionieren. Ausprobiert habe ich das aber nicht

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]

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.

 

[ralli]

Im Handbuch Kapitel 17.4 - USB Speichermedien steht:

Anmerkung:
Die Unterstützung für USB 3.0 ist mit einiger Hardware, einschließlich Haswell (Lynx Point) Chipsätzen, nicht kompatibel. Wenn FreeBSD beim Booten mit dem Fehler failed with error 19 abbricht, müssen Sie xHCI/USB3 im BIOS deaktivieren.

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

 

[Lance]

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

env REPOS_DIR=

vor einem "pkg install Paket" ?

LG Lance

 

[holgerw]

Hallo,

leider geht das nicht, ich habe das Image mit dd auf einen 8G großen Stick gepackt (da4), dann:

gpart recover da4
da4 recovered

Dann:

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:

gpart add -t freebsd-ufs -i 5 -l plasma5repo da4
gpart: index '5': Invalid argument

Ohne -i und mit Größenangabe:

gpart add -t freebsd-ufs -l plasma5repo -s 5g da4
gpart: index '5': No space left on device

Hmm, und wie jetzt weiter?

 

[pit234a]

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.

 

[pit234a]

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:

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):

und ich konnte die auch wie üblich durch Doppelklick mounten:

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

 

[pit234a]

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

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...

 

[pit234a]

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.

 

[pit234a]

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:

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:

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]

Hallo Pit,

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

 

[pit234a]

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.

 

[pit234a]

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:

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.

 

[pit234a]

Das sollte eigentlich ganz einfach funktionieren. Ausprobiert habe ich das aber nicht

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...

Ich habe eben einen Stick mit einem Ghost-BSD-Image, das ich mittels dd darauf gelegt hatte und der zeigte mir in dmesg:

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:

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.

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.