Root partitie resizen voor grotere disk

[MClaeys]

De disk van een serverke is in de loop der jaren wat klein geworden. Wat jaren geleden heb ik er 25GB voor voorzien wat toen op zich voldoende leek (de meeste data staat op een andere database server). Maar inmiddels staat hij toch vol.
Ik heb de server afgesloten, de disk vergroot in ESX en weer gestart, maar nu moet ik dus mijn partitie nog vergroten en het filesysteem laten "meegroeien". Hier ben ik niet mee bekend.

Voor Linux zijn er allerhande tutorials te vinden, dus zo gezegd zo gedaan dacht ik.
De eenvoudigste manier die ik vond was met fdisk en dan resize2fs. Maar daar zeggen ze dat je "start"-nummer hetzelfde moet zijn (kwestie geen data te verliezen) en je eind nummer geen andere partities mag overlappen. Bij mij zit er maar weinig ruimte tussen SDA1 en SDA2.

Kan ik op een of andere manier de andere partities moven zodat ik toch de extra ruimte kan benutten? (Ik heb wel een backup, maar als ik niet moet restoren is dat te prefereren). Of is dat iets waar zelfs menig Linux Guru van begin daar niet aan?

[fuserke]

Als het een virtuele server is gewoon gparted gebruiken

[blaatpraat]

Als je die mogelijkheid hebt:
Een andere linux opstarten (live image laden bijvoorbeeld), en daarin gparted gebruiken.

Als je die mogelijkheid niet hebt, wordt het moeilijker.
Heb je LVM gekozen tijdens de installatie? Of pure native ext4?

[MClaeys]

Ik denk LVM, maar dat is al wat lang geleden om zeker van te zijn en voor snel iets op te zetten tik ik ook soms nogal snel er door.

Een live image en gparted, daar had ik niet aan gedacht . Ik wist wel niet dat gparted partities kon verplaatsen, wel visueel vergroten. Morgen eens testen.

[blaatpraat]

Als het LVM is, zou het moeten lukken.
Maar de voorkeurspiste is een live image met gparted.

[GuntherDW]

Gezien je de disk aanroept met /dev/sda* zal het wel ruwe ext4 zijn, alsook is het "maar" swap e.d. dus die kan je veilig removen en achteraf gewoon terugmaken.

Om het makkelijk te houden kan je een gparted livecd booten op je server inderdaad maar dit is vrij simpel. /dev/sda2 en /dev/sda5 deleten, /dev/sda1 resizen en een nieuwe swap (met mogelijk extended partition errond, al is dat in dit geval niet echt nodig?) maken op het einde terug.

Gewoon achteraf zien dat je UUID's nog kloppen in je /etc/fstab, gezien die veranderd zullen zijn, uiteraard als je een nieuwe swap aanmaakt.

[MClaeys]

Blijkbaar inderdaad geen LVM.
Ik heb met gparted de partities gedelete, opnieuw aangemaakt aan het eind van de disk en de initiele vergroot.
changes gecommit.
Er moet toch ergens iets mis gelopen zijn helaas, want bij Power On gaat de machine wel in de "aan"-mode, maar er gebeurt verder niks (zelfs de force into bios mode niet). Reageert zelfs niet op het Power off signaal via ESX (wel via esxcli). De hele ESX host word er erg traag van, wat vreemd is voor een serverke met 1 cpu en 2GB ram. Dus maar even men folder terug kopieren van voor ik begon en opnieuw proberen. Geen idee hoe ik het heb klaargespeeld. Eerst nog effe zien of het niet oplosbaar is door een file te verwijderen die misschien corrupt is.

[GuntherDW]

Als heel uw ESX machine traag wordt zou ik toch ook eens m'n logs nakijken of die niet volgeblafd worden met errors ofzo.
Maar als zelfs "forced enter into BIOS" niet werkt gaat er inderdaad wel iets mis geloof ik .

Het kan vrij simpel zelfs zonder gparted eigenlijk maargoed, als je het "simpel" wil houden met wat geklik ipv rammelen in de CLI kan het wel zo.

[MClaeys]

Vanalles van files verwijderd, getest, geen resultaat. Dan maar backup terug geplaatst. Werkte nog niet.
Bleek het de USB controller te zijn waar iets mis mee was. Verwijderd uit VM settings, terug toegevoegd met de 2 USB devices, hij boot weer.
Nieuwe poging dus .

@GuntherDW, ik vond gparted nog niet zo simpel eigenlijk, al kwam dat meer omdat ik per ongeluk de Ubuntu live cd had aangeklikt en die niet zo vlot werkt op die specs van de VM .
Ik ga er later nog eens naar zien (kwestie er niet heel men verlofdag aan te hangen). Volgende poging eens met fdisk, we kunnen er ineens maar wat van leren.
Als ik uw uitleg goed snap, eerst kijken in fstab naar de UUID's.
Vervolgens de swap en extended deleten.
Dan de primary deleten en opnieuw aanmaken met startwaarde hetzelfde dan voordien en een grotere eindwaarde.
Nieuwe swap partitie maken aan het einde (heb ik die eigenlijk nodig? Ik kan gerust ram toevoegen aan de VM en ik denk dat de 2GB zelfs nog voldoet)
Een resize2fs voor /dev/sda1
Reboot want ik neem aan dat hij dat anders niet kan uitvoeren op de primary partitie.



Edit: toch nog niet geheel ok precies. Zodra ik de USB devices weer link aan de USB controller zelfde probleem. Dus eerst dat maar proberen fixen.ook gefixt

[GuntherDW]

Als je niet zeker bent van je zaken kan je een snapshot maken welke je dan achteraf verwijdert, of de VM exporten en lokaal draaien op je eigen pc met daarop vmware player of virtualbox.

Maar zoiets klopt "ongeveer".

swap is eigenlijk altijd handig. Het zorgt ervoor dat er niet random processen gekilled worden als er wat meer RAM gevraagd wordt door de OOM killer.
Met "check de UUID's" bedoelde ik meer achteraf, met het "blkid" commando kijken in fstab en die aanpassen dan. Indien je fstab met UUID's werkt tenminste. Oudere setups werken nog met ruwe /dev/sdXX of "LABEL=...".

Wel raar verhaal hoe USB zoiets kan veroorzaken though?

[tien]

als je de tijd kunt nemen is het wel een goed moment om eens een restore te proberen naar "andere" hardware

[MClaeys]

Ja, beide geconnecteerde sticks stonden in error (random pinken van de leds). Ooit ook eens gehad toen ik nog gewoon op een pc draaide, vamdaar dat ik er naar keek. Even fysiek los gekoppeld en weer aan en het werkte weer. De trage ESX interface had geen invloed op de rest van de VM's dus het was puur de webgui bij die VM uiteindelijk.

Ik maak momenteel een gewone backup voor ik start op een afzonderlijke disk dus daar verwacht ik niet echt issues.

Qua restore naar andere hardware, ben wel eens van zin in de toekomst naar een andere VM te migreren voor Home Assistant, maar nu volstaat een grotere disk. Verder bolt alles goed (HA ook, enkel onvoldoende ruimte voor meer dan 1 backup file momenteel).

[Tim.Bracquez]

**

[dupondje]

Als je nog eens een install doet van een VM, geen partities maken, gewoon op de sda installeren. Als je erna een groter wenst kan deze gewoon vergroten en resize2fs draaien, klaar. swapfile in paritie of file heeft geen performance impact. Dit zonder risico van data te verliezen

Maar voor Grub heb je een partition nodig.
Op uw extra disks kun je inderdaad zonder partition werken.

[Tim.Bracquez]

**

[devilkin]

Waarom niet gewoon LVM gebruiken? Dan kan je de boel schoon splitsen en resizen achteraf indien nodig.

[dupondje]

@dupondje: Niet nodig hoor, kan gewoon er bij op de sda zonder partitie. Doe dit altijd zo, meest flexibele en ook geen gedoe dat je /boot te klein is.

https://wiki.archlinux.org/index.php/GR ... nless_disk

Euh? Kan wel, maar niet echt aan te raden/supported.
Grub gebruikt juist de eerste 2048 sectors tussen 0 en begin eerste partitie, als je geen partitie hebt wordt dat lastig.

Toevallig geen Xen PV VM's

[MClaeys]

Het komt er eigenlijk op neer dat ik bij de installatie al de mist in ga Ik gebruik telkens gewoon de standaardoptie "Benut gehele schijf" en vervolgens alles in 1 partitie, maar eigenlijk kies ik dus beter "Benut gehele schijf en gebruik LVM".
Deze week nog eens een poging doen ze te vergroten, en meteen weer wat bijgeleerd van Linux

[GuntherDW]

Het is een beetje een keuze die je moet maken.
LVM is een abstractielaag bovenop je disk. Als je vaak partities gaat resizen of semi-raid functies wil kan je van LVM gebruik maken.

LVM maakt echter het resizen IMO niet makkelijker, de procedure blijft dezelfde als het over je boot medium gaat.
Meer nog, voor servers met "maar" 1 disk is LVM een beetje overbodig IMO.

Zeker nu met dingen als GPT indien je veel partities op 1 disk wil.

[devilkin]

Dunno. Je boot gewoon groot genoeg maken, en de rest kan je spelen met lvm. Gebruik het altijd, ook op laptops met maar 1 ssd, maar ieder z'n ding.

[MClaeys]

Bij al men systemen gebruik ik eigenlijk maar 1 disk. Normaal zijn ze ook groot genoeg, maar deze is jaren geleden gemaakt en in de loop der tijd zijn er dan plugins gekomen voor Home Assistant en dat zijn losse docker containers die nogal wat plaats innemen blijkbaar . Nooit bij stil gestaan of naar omgekeken tot ik zag dat men backup niet meer liep sinds een week . Binnenkort ook men Zabbix eens opnieuw in gang steken zodat zulke zaken sneller opvallen. En in tussentijd zien of het vergroten lukt, zo niet => migratie naar een andere VM met grotere disk, ook geen ramp .

Edit: Gisteravond uitgevoerd zonder problemen. Toch voor dezelfde manier gegaan uiteindelijk dan de eerste keer, maar dan met men gparted ISO ipv Ubuntu. Was op 5 minuten in orde. Had deze keer de Zigbee2mqtt stick los gekoppeld voor het geval hij weer in error zou komen (en ineens es een nieuwe besteld om dat definitief op te lossen).

Tnx voor alle tips Ik kan redelijk men plan trekken op Linux, maar aan zulke zaken pruts ik niet graag. En bij de eerste handleiding was ik al eens de mist in gegaan voor ik het hiet kwam vragen (lang leve backups).