BGAFC Vendégkönyv

Σ: 1 post

TCH (statz)

#1, Főfasz (10503)

9341 | #55a1 | ^ | Idézet | Sun, 29 May 2022 19:17:44 +02

84.236.*.*

*.pool.digikabel.hu

Mivel a gecis FreeBSD Team kihúzta a gecis FreeBSD 11 alól a gecis repót, így kénytelen voltam upgradelni. Ehhez azonban nagyobb tárat kellett már megint adnom ennek a szarnak. Miután a VBox-nak megmondtam, hogy mekkora legyen az új mérete a HDD-nek, írtam rá egy scriptet, hogy egy parancsból menjen a már élő partíció átméretezése.

#!/bin/sh
gpart recover "$1"
sysctl kern.geom.debugflags=16
gpart resize -i "$2" -a 4k "$1"
if [ "$3" = "ZFS" ]
then
	zpool online -e zroot "$1""p""$2"
else
	growfs "/dev/""$1""p""$2"
fi

Használat pl.:

rspart ada0 3 ZFS

Vagy ötször újra kellett csinálnom az egészet, mire rájöttem, hogy a gecis growfs azért dobálja vissza, hogy "superblock not recognized", mert a ZFS-hez nem jó...és erre is abból jöttem rá, hogy kívülről a gparted ill. a parted is csak beszart rajta, miután felcsatoltam a VDI-t NBD-be. Persze ezt egyetlen kurwa FreeBSD-s manual és egyetlen kurwa fórum se írta le; ill. egy fórum igen, az, ahol megtaláltam.

Aztán az update:

freebsd-update fetch install
freebsd-update install
freebsd-update -r 12.3-RELEASE upgrade
freebsd-update install
reboot
freebsd-update install
freebsd-update install
pkg-static install -f pkg
pkg update -f
pkg upgrade -f
pkg clean

Igen. Ezt így kellett update-elni. Ráment a fél napom, mire mindenre rájöttem.

Update 2024.07.26.: Itt van két script, ami elvileg kérdés nélkül megcsinál mindent (gyakorlatilag meg nem, mert a freebsd-update -r "$1""-RELEASE" upgrade csak bekérdez, hogy Does this look reasonable (y/n)?, de az első két parancs 2-3 perc alatt lefut, szóval azt még ki lehet várni, illetve a végén is bereklamál, hogy ez meg az merged, vagy épp nem lehetett mergelni és press enter to edit in vi (jajj nekem!), de tekintve, hogy utána már úgyis a reboot jönne és úgyis kézzel kellene elindítani a másik scriptet, miután visszajöttünk a boltból/orvostól/adóhivatalból/akárhonnan és visszaültünk a gép elé, így tkp. mindegy, csak az újraindítást kell kivárni, az meg egy perc); értelemszerűen először az elsőt, aztán reboot után a másodikat kell lefuttatni (az elsőnek átadván a verziószámot, amire upgradelni akarunk). A végén az a két rm parancs azért kell, mert a FreeBSD telipakolja a csomagjaival/átmeneti fájljaival a fájlrendszert, aztán úgy hagyja és mi meg majd csodálkozhatunk, hogy miért fogyott el már megint a hely.

#!/bin/sh
export PAGER=cat
export ASSUME_ALWAYS_YES=YES
freebsd-update fetch
freebsd-update install
freebsd-update -r "$1""-RELEASE" upgrade
freebsd-update install
reboot

#!/bin/sh
export PAGER=cat
export ASSUME_ALWAYS_YES=YES
freebsd-update install
pkg-static upgrade -f -y
freebsd-update install
pkg clean -y
rm /var/cache/pkg/*.pkg
rm -rf /var/db/freebsd-update/*
zfs list -H -o name -t snapshot | xargs -n1 zfs destroy -R
reboot

Update: Miután letöröltem a rendszerből a sok csomagot/átmeneti cuccot, megpróbáltam frissíteni és még előbb pusztult el, hogy elfogyott a szabad hely. Miután az nem lehetséges, hogy minél több dolgot törlök le, annál kevesebb hely marad, így nekiálltam feltúrni a netet, hogy mégis hogy kezeli a ZFS a szabad helyet, mert azért ez mégse járja, hogy 38 GB-os a partíció és alig van rajta hely úgy, hogy közben alig van rajta anyag. Belefutottam ebbe a topicba és a zfs list -t snapshot parancsot kiadva kiderült, hogy valami két éve tényleg csinált jópár snapshotot. (A jelek szerint az upgrade-ek voltak.) Ebből a gistből és ebből a topicból kiderül, hogy az összes snapshotot a függő klónjaikkal együtt így kell törölni:

zfs list -H -o name -t snapshot | xargs -n1 zfs destroy -R

Hirtelen mindjárt lett 28 GB-nyi szabad hely.

Az upgrade egyébként kb. 9 GB cuccot hagyott a rendszerben, ebből 6 GB a snapshotok voltak, 2GB az upgrade cuccai, 1 GB a csomagok.

Update: Mivel viszont így kiderült, hogy valójában sosem volt szüksége 40 GB-ra a FreeBSD-nek, csak teliszórta snapshotokkal és egyebekkel a FS-t, így most felmerült, hogy hát össze kéne nyomni a lemezt. Mivel a lemezkép dinamikus, így a VBoxManage modifymedium --compact <VDI image> használható erre...de az csak akkor tudja összenyomni, ha a használaton kívüli blokkok ki vannak nullázva. Ezt a legtöbb filerendszeren úgy lehet megejteni, hogy dd if=/dev/zero of=/path/to/big/file/filled/with/zeroes bs=1024k (vagy amekkora blokkméret tetszik) és utána rm /path/to/big/file/filled/with/zeroes és uccu neki. ZFS-en viszont ez nem így megyen. A mai napot a net végigtúrásával töltöttem, hogy rájöjjek, hogy lehet, de nem sikerült. Mármint rájönni. Megoldani igen. Elméletileg úgy kéne, hogy

set zfs:zfs_initialize_value=0
zpool initialize <pool neve> <partíció UUID-ja>

Na, ez az, ami nem működik. Az első lenne hivatott arra, hogy az inicializációs értéket a default 0xdeadbeefdeadbeee-ről (És nem 0xdeadbeefdeadbeef-ről, ahogy a ticket állítja! Sz*rk: Viszont OmniOS - és így valószínűleg Solaris és annak minden forkja/klónja - alatt tényleg 0xdeadbeefdeadbeef a default. Lehet, hogy csak FreeBSD alatt tér el. Vagy a BSD-k alatt. Passz.) nullára állítsa, hogy az üres blokkokat nullával töltse ki, de ha a default shellből próbálom, akkor reklamál, hogy csak alfanumerikus karakterek lehetnek a névben (a kettőspont meg ugye nem az), ha meg pl. bash-ból, akkor meg elfogadja ugyan, de foganatja nincs. Ezenfelül - ellentétben a ticketben leírtakkal - ha megadom az UUID-et, akkor reklamál, hogy hát ez nem része a pool-nak, míg nélküle - ellentétben a ticketben leírtakkal - működik. Viszont az üres blokkokat az alap 0xdeadbeefdeadbeee-vel töltötte fel, amit ugye a VBox nem fog összenyomni. Viszont, ha mi kézzel kicseréljük a lemezképben ezt a bizonyos stringet (little endian rendszereken ez fordítva - ee be ad de ef be ad de-ként - manifesztálódik), akkor utána már be lehet írni neki, hogy

VBoxManage modifymedium --compact /a/SOFTDISK/vbox/FreeBSD64/FreeBSD64.vdi

...hogy aztán elszálljon, hogy

VBoxManage: error: Cannot register the hard disk '/a/SOFTDISK/vbox/FreeBSD64/FreeBSD64.vdi' {6d709617-6206-4691-a62d-0bde4a4d9982} because a hard disk '/media/SOFTDISK/vbox/FreeBSD64/FreeBSD64.vdi' with UUID {6d709617-6206-4691-a62d-0bde4a4d9982} already exists
VBoxManage: error: Details: code NS_ERROR_INVALID_ARG (0x80070057), component VirtualBoxWrap, interface IVirtualBox, callee nsISupports
VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 197 of file VBoxManageDisk.cpp

Viszont az UUID-et megadva menni fog és mivel volt olyan kedves, hogy ki is írta, így

VBoxManage modifymedium --compact {6d709617-6206-4691-a62d-0bde4a4d9982}

És máris csak 16 GB a lemezkép 40 helyett. Minő öröm...végre nem 20 percig fog tartani, amíg átmásolja a backup lemezre, hanem csak 8.

Update: https://omnios.org/article/hole-punching

Szóval a

set zfs:zfs_initialize_value=0

az az /etc/system-be kell, hogy menjen...hát ezt nem írták - ezt a manualt leszámítva - sehol sem... És akkor tényleg csak

zpool initialize <pool name>

oszt' csá. Alternatíva CLI-ből a

mdb -kwe 'zfs_initialize_value/z0'

parancs.

Update: Legalábbis OmniOS/Solaris alatt, mert FreeBSD alatt TERMÉSZETESEN nincs /etc/system és azt sem találom, hogy hová kéne ezeket beírni! Kösz szépen...

Update: Megadták a helyes tippet:

sysctl vfs.zfs.initialize_value=0

Sajnos viszont a múltkorival ellentétben, most nem ment össze a VDI, pedig össze kellett volna...

Update 2025.10.05.: Közben - amíg az oldal nem volt elérhető - sikerült kideríteni, hogy azért nem ment össze, mert az inicializálást csak egyszer lehet megejteni. Namármost, FreeBSD alatt van -u kapcsolója a zpool initialize-nak, ami "deinicializálja" a pool-t és akkor lehet újrainicializálni és akkor már össze fog zsugorodni. Ez sajnos Solaris (és OmniOS) alatt nincs, ott egy kicsit körülményesebben kell ezt megoldani. A ZFS - mint kiderült az eddigiekből - "lenyeli" a csupa nullát tartalmazó blokkokat. By default. De ezt ki lehet kapcsolni és akkor lehet fillezni:

zfs set compression=off <pool name>
zfs set dedup=off <pool name>
dd if=/dev/zero of=/root/whatever bs=16M ; rm /root/whatever