• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Wo sind die Gigabytes?

berni51

Well-Known Member
Themenstarter #1
Bei der Installation von OpenBSD 6.2-current auf dem Intel NUC hab ich einen Augenblick nicht aufgepasst und dem System die gesamte HD mit 1 TB überlassen. Sonst hat sich das BSD bei dieser Option auch brav die ganze Platte geholt.
Jetzt aber fällt mir auf, dass das System nur knapp 500 GB aufgeteilt hat. Wo ist die andere Hälfte?

type: SCSI
disk: SCSI disk
label: 024 HN-M101MBB
duid: 52e9554ddfa1b13d
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 121601
total sectors: 1953525168 # total bytes: 931.5G
boundstart: 64
boundend: 1953520065
drivedata: 0

16 partitions:
# size offset fstype [fsize bsize cpg]
a: 1.0G 64 4.2BSD 2048 16384 12958 # /
b: 8.0G 2097216 swap # none
c: 931.5G 0 unused
d: 4.0G 18918880 4.2BSD 2048 16384 12958 # /tmp
e: 19.5G 27307456 4.2BSD 2048 16384 12958 # /var
f: 2.0G 68290784 4.2BSD 2048 16384 12958 # /usr
g: 1.0G 72485088 4.2BSD 2048 16384 12958 # /usr/X11R6
h: 10.0G 74582240 4.2BSD 2048 16384 12958 # /usr/local
i: 2.0G 95553760 4.2BSD 2048 16384 12958 # /usr/src
j: 6.0G 99748064 4.2BSD 2048 16384 12958 # /usr/obj
k: 300.0G 112331008 4.2BSD 4096 32768 26062 # /home

Kann ich eine weitere Partition mit den restlichen GB erstellen und irgendwo einhängen?
 

mapet

Active OpenBSD User
#2
Klar, du kannst aber auch /home vergrößern. Mit growfs(8) kannst du anschließend das filesystem dann auf die neue Größe anpassen.
 

berni51

Well-Known Member
Themenstarter #3
Klingt gefährlich - vor allem, wenn man nicht wirklich Bescheid weiss (so wie ich).
Im Moment weiss ich nicht mal, wie ich die fehlenden GB überhaupt sichtbar machen soll. :(
 
#4
Jetzt aber fällt mir auf, dass das System nur knapp 500 GB aufgeteilt hat. Wo ist die andere Hälfte?
Ich meine mich sehr dunkel daran zu erinnern, dass OpenBSD bei der automatischen Partitionierung maximal 500GB nutzt

http://scie.nti.st/2013/3/4/how-to-resize-an-openbsd-root-partition/
Wenn du erst den Upgrade-Prozess startest und frühzeitig abbrichst, kannst du dir das Mounten sparen und solltest dann mit der Anleitung keine Probleme haben.
Den Punkt mit dem Entfernen des Swap usw. kannst du dir auch sparen, da dein /home bereits am Ende steht
 
#5
Growing disk partitions

If an existing partition is followed by unallocated free space, you may increase its size using the growfs(8) utility. Make sure the partition is not currently mounted. Edit your partition table interactively with disklabel -E sd0 and modify the size of the partition using the m command. Adjust the filesystem to use the entire partition with growfs(8):

# growfs sd0k

Before the partition can be mounted again, its integrity must be checked with fsck(8):

# fsck /dev/sd0k
https://man.openbsd.org/growfs
https://www.openbsd.org/faq/faq14.html#GrowPartition


HINWEIS: Am besten vorher ein backup deiner Daten und configs machen. Sicher ist sicher.

Im Prinzip brauchst Du hier nicht in den bsd.rd zu booten.

1.) Logge deine user aus und logge dich als root ein.
2.) ``umount /dev/sd0k'' (Dein /home aushaengen).
3.) ``disklabel -E sd0'' (Die Partitionstabelle editieren).
4.) ``m k'' eingeben und dort die neue Groesse des /home angeben.
5.) ``q'' zum Beenden eingeben und speichern.
6.) ``growfs sd0k'' eingeben, um das filesystem zu vergroessern.
7.) ``fsck /dev/sd0k'' eingeben, um das neue Dateisystem zu pruefen.
8.) ``mount /dev/sd0k /home'' eingeben, um das /home wieder einzuhaengen.
9.) Wieder als user einloggen.
 

mapet

Active OpenBSD User
#6
Klingt gefährlich - vor allem, wenn man nicht wirklich Bescheid weiss (so wie ich).
Im Moment weiss ich nicht mal, wie ich die fehlenden GB überhaupt sichtbar machen soll. :(
Die GB sind doch sichtbar in der Partition "c". Sie sind nur beider automatischen Vergabe der disklabels nicht berücksichtigt worden. Mit "disklabel -E sd0" kommst du wieder in den Editiermodus und kannst hier mit c die Partition vergrößern. Aber das kannst du auch alles hier nachlesen.
 

berni51

Well-Known Member
Themenstarter #9
Leute, es ist vollbracht! Dank eurer Hilfe hats geklappt und ich bedanke mich vielmals bei euch.
Zwischendrin gab es einige Augenblicke, wo ich ins Schwimmen geraten bin und reichlich Schweissperlen auf der Stirn hatte.
Aber es ist alles gut gegangen, kein Datenverlust, die Maschine bootet immer noch und ich hab mein Terrabyte.

Aber mal ehrlich: Noch komplizierter kann man so einen Vorgang doch kaum machen. Obwohl - wenn ich an meine alte Sun denke ..... das war genau so unfreundlich.

Hier der Beweis:

# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: 024 HN-M101MBB
duid: 52e9554ddfa1b13d
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 121601
total sectors: 1953525168 # total bytes: 931.5G
boundstart: 64
boundend: 1953520065
drivedata: 0

16 partitions:
# size offset fstype [fsize bsize cpg]
a: 1.0G 64 4.2BSD 2048 16384 12958 # /
b: 8.0G 2097216 swap # none
c: 931.5G 0 unused
d: 4.0G 18918880 4.2BSD 2048 16384 12958 # /tmp
e: 19.5G 27307456 4.2BSD 2048 16384 12958 # /var
f: 2.0G 68290784 4.2BSD 2048 16384 12958 # /usr
g: 1.0G 72485088 4.2BSD 2048 16384 12958 # /usr/X11R6
h: 10.0G 74582240 4.2BSD 2048 16384 12958 # /usr/local
i: 2.0G 95553760 4.2BSD 2048 16384 12958 # /usr/src
j: 6.0G 99748064 4.2BSD 2048 16384 12958 # /usr/obj
k: 877.9G 112331008 4.2BSD 4096 32768 11888 # /home

Heute heisst die Platte zwar sd1, aber nur, weil noch eine SD-Karte eingesteckt ist: Meine boot-card mit dem 6.2-current, nur für den Fall der Fälle. :cool:

Nochmals mein Dank an dieses wunderbare Forum.

Grüße aus dem Vogelsberg
Berni
 
#10
Schoen, dass es ohne Probleme bei Dir geklappt hat. :-)

Ich weiss auch nicht, was bei Deiner Installation schiefgegangen ist. Aber ich mache auch nie die automatische Partitionierung, sondern gebe die Groessen der slices immer von Hand ein. Evtl. probiertst Du das bei Deiner naechsten Installation auch mal. Ist garnicht so schwer und Du musst auch keine Sektoren oder so angeben, sondern kannst einfach jeweils die entsprechenden GB angeben.
 

berni51

Well-Known Member
Themenstarter #11
Ja, dass hab ich dabei gelernt: Automatik ist nicht immer das Beste. Sobald meine SSD ankommt, gibt ja eine weitere Installation.
 
#12
Je nachdem, was Du mit dem Rechner anstellen willst, ist die automatische Partitionierung auch nicht sinnvoll. Nutzt Du nur packages und syspatch, brauchst Du kein /usr/src und /usr/obj und auf einem Server brauchst Du wohl ein grosses /var oder /var/www. Baust Du jedoch dein System aus den source codes selbst, brauchst Du evtl. noch ein /usr/xenocara und /usr/ports und /tmp und /usr/obj sollten dann groesser sein, als die automatischen Vorgaben. Das bekommt man mit der Zeit selbst heraus, welche Groessen fuer einen sinnvoll sind.
 

berni51

Well-Known Member
Themenstarter #13
Da werd ich noch einiges lernen müssen! Bisher ist ja OpenBSD für mich nur Spaß und eine Spielerei, weil die Produktivsysteme noch mit Linux Mint laufen. Aber wenn das so positiv weitergeht mit OBSD, kann sich das ändern. Brauch ja nur einige wenige Applikationen und muss jetzt sehen, ob die unter OBSD genau so stabil sind wie unter Linux.
 
#14
Bisher ist ja OpenBSD für mich nur Spaß und eine Spielerei, weil die Produktivsysteme noch mit Linux Mint laufen.
Schau dir gut an wie das Thema "Applikationen updaten" an, funktioniert mit dem pkg-Manager nämlich nur bei OpenBSD-current

Als kleiner Tipp am Rande :)

Hier die Möglichkeiten:
3rd Party: https://www.mtier.org/solutions/apps/openup/
Do it yourself: selber bauen

Als kleiner Beweis, hier sind packages aus dem stable Repo:
https://ftp2.eu.openbsd.org/pub/OpenBSD/6.2/packages/amd64/
Alles Stand vom 6.2 Release (Anfang Oktober 2017)
 
#15
@mogbo

Er hat schon -current am laufen, da seine hardware unter release nicht supported wird. ;-)

Was meinst Du denn genau? ``pkg_add -u'' funktioniert auch unter release. Allerdings nur beim upgrade auf eine neuere Version, da die packages innerhalb einer Version nicht aktualisiert werden. Bei sicherheitsrelevanten backports der packages unter release kann man dann natuerlich auch die packages von mtier nutzen.
 

pit234a

Well-Known Member
#16
ist die automatische Partitionierung auch nicht sinnvoll.
für mich persönlich fand ich diese Partitionswut schon immer unverständlich. Auch unter ZFS brauche ich nicht so viele Datasets, wie mir da per Default angelegt werden. Aber bei Datasets ist das eher akademisch, "sie fressen ja kein Brot". Eine Partition ist in ihrem Platz immer begrenzt und wenn sie mal voll läuft, gibt es mitunter Probleme.
Das bekommt man mit der Zeit selbst heraus, welche Groessen fuer einen sinnvoll sind.
Deshalb denke ich, dass es gerade am Anfang eher sinnvoll ist, auf möglichst wenig Partitionen zu setzen. Hat man einen besseren Überblick darüber, was man braucht, kann man das berücksichtigen. Aber es funktioniert ja auch mit einer einzigen Partition für / (neben SWAP) und warum soll man sich die Möglichkeiten unnötig einschränken? Zumal ja eh fast niemand die weitergehenden Möglichkeiten mit Partitionen nutzt.
 
#17
Aber es funktioniert ja auch mit einer einzigen Partition für / (neben SWAP) und warum soll man sich die Möglichkeiten unnötig einschränken?
W^X würde bei OpenBSD gewisse 3rd Party killen, was man über die fstab einschränken kann. /usr/local extra zu partitionieren kann somit gerade bei OpenBSD sehr sinnvoll sein.
 
#18
Man kann auch das auto-layout direkt beim Install schon veraendern. Wieso das bei 500G aufhoert, weiss ich grad auch nicht mehr.

Die Partitionierungs"wut" hat ihre Gruende, aber das waer eher offtopic (hint: mount options/security).

Ausserdem erinnert das an Sun, weil da auch disklabel "herrscht(e)" ;-)
 
#19
für mich persönlich fand ich diese Partitionswut schon immer unverständlich. Auch unter ZFS brauche ich nicht so viele Datasets, wie mir da per Default angelegt werden. Aber bei Datasets ist das eher akademisch, "sie fressen ja kein Brot". Eine Partition ist in ihrem Platz immer begrenzt und wenn sie mal voll läuft, gibt es mitunter Probleme.
Darum ist die autopartition des installers auch nicht immer sinnvoll. Wer nur packages und syspatch nutzt, braucht kein /usr/src und kein /usr/obj. Das wird bei der automatischen parititon aber angelegt.

Anders als viele andere Betriebssysteme bestärkt OpenBSD seine Benutzer, ihre Laufwerke in eine ganze Reihe von Partitionen zu unterteilen, anstatt nur eine oder zwei große Partitionen zu nutzen. Es gibt einige Gründen, das Laufwerk zu unterteilen:

  • Sicherheit: Du kannst einige Dateisysteme als »nosuid«, »nodev« »noexec«, »readonly« etc. spezifizieren. Dies übernimmt das Installationsprogramm für dich, solltest du die empfohlenen Partitionen nutzen.
  • Stabilität: Ein Benutzer, oder ein sich schlecht aufführendes Programm, kann das Dateisystem mit Müll anfüllen, wenn Schreibrechte dafür vorhanden sind. Deine kritischen Programme, die hoffentlich auf einem anderen Dateisystem laufen, werden davon nicht beeinträchtigt.
  • Geschwindigkeit: Ein Dateisystem, das häufig beschrieben wird, kann ein wenig fragmentieren. (Glücklicherweise ist das FFS-Dateisystem, das OpenBSD nutzt, nicht anfällig für sehr starke Fragmentierung.)
  • Integrität: Wenn ein Dateisystem aus irgendwelchen Gründen zugrunde gerichtet ist, dann sind deine anderen Dateisysteme sehr wahrscheinlich noch O.K.
  • Größe: Viele Maschinen besitzen eine Beschränkung für die Position auf dem Laufwerk, von der das »Boot-ROM« den Kernel laden kann. In einigen Fällen kann dieses Limit sehr klein sein (504 MB für ältere 486er), in anderen viel größer (2 G, 8 G oder 128 G auf i386-Systemen). Da der Kernel sich an jeder möglichen Position auf der root-Partition befinden kann, sollte die gesamte root-Partition innerhalb dieses beschränkten Bereichs liegen. Für weitere Details siehe in diesem Abschnitt. Eine gute Richtlinie mag sein, die Partition für / komplett kleiner als 2 G zu halten. Es sei denn, du weißt, dass deine Plattform (oder spezielle Maschine) mit mehr (oder weniger) umgehen kann.
  • Nur-Lesen: Du kannst Partitionen, die nie oder nur selten beschrieben werden, für die meiste Zeit im »Nur-Lesen«-Modus einhängen, was die Notwendigkeit eines fsck(8)-Laufs nach einem Crash oder Stromausfall beseitigt, und ebenso vor unbeabsichtigter Veränderung von Daten schützen kann.
  • fsck(8): Sehr große Partitionen verlangen nach mehr RAM für den fsck(8), und auf Systemen mit wenig Hauptspeicher kann dies dazu führen, dass Daten ausgelagert werden müssen, was zu sehr lang andauernden fsck-Läufen führt.
Quelle: https://web.archive.org/web/20140327102038/http://www.openbsd.org/faq/de/faq4.html#Partitioning