/dev/sda1 /boot partition resize Ubuntu 14.04 server

[sj31]

Hallo Allen,

Ik kreeg de nagios (Monitoring) melding: DISK CRITICAL - free space: /boot 36 MB (16% inode=99%):

Er is dus te weinig opslag in de boot partitie. Nu heb ik de volgende partities

code:

root@hostname:~# df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/sda2               14G  7.9G  5.1G  61% /
none                   4.0K     0  4.0K   0% /sys/fs/cgroup
udev                   484M  4.0K  484M   1% /dev
tmpfs                  100M  692K   99M   1% /run
none                   5.0M     0  5.0M   0% /run/lock
none                   497M  4.0K  497M   1% /run/shm
none                   100M     0  100M   0% /run/user
/dev/mapper/home-home  8.1G   58M  7.6G   1% /home
/dev/sda1              230M  181M   37M  84% /boot
/home/host/.Private    8.1G   58M  7.6G   1% /home/host

Kan iemand mij vertellen hoe ik de /dev/mapper/home-home of de /home/host/.private kan verkleinen omdat deze gewoon te groot zijn en wat extra opslag bij de /dev/sda1 kan op doen.

De server draait in een VMware vSphere omgeving.

alvast bedankt!

[borft]

simpel stappenplan:
- filesystem op /home verkleinen (resize2fs)
- LV van /home verkleinen (lvresize)
- VG home verkleinen (pvresize)
- partitie waar je VG op staat verkleinen (vermoedelijk is dat /dev/sda3) (fdisk)
- /dev/sda2 vergroten (fdisk)
- filesystem op /dev/sda2 vergroten (resize2fs)

Als ik jou was, zou ik je root partitie verkleinen... maar waarom heb je eigenlijk een apartie boot partitie? De makkelijkste oplossing is gewoon /boot verplaatsen naar je root partitie, dan ben je in 1x klaar.

[sj31]

borft schreef op donderdag 11 juni 2015 @ 14:14:
simpel stappenplan:
- filesystem op /home verkleinen (resize2fs)
- LV van /home verkleinen (lvresize)
- VG home verkleinen (pvresize)
- partitie waar je VG op staat verkleinen (vermoedelijk is dat /dev/sda3) (fdisk)
- /dev/sda2 vergroten (fdisk)
- filesystem op /dev/sda2 vergroten (resize2fs)

Als ik jou was, zou ik je root partitie verkleinen... maar waarom heb je eigenlijk een apartie boot partitie? De makkelijkste oplossing is gewoon /boot verplaatsen naar je root partitie, dan ben je in 1x klaar.

Dit is een eis van mijn werkgever. Ik ga de stappen even uitproberen!

[borft]

let erop dat je wel een backup maakt van je home partitie..... maar really, de aparte boot partitie is alleen in heel specifieke gevallen nodig, en zeker niet bij zo'n kleine opslag als jij hebt...

[sj31]

borft schreef op donderdag 11 juni 2015 @ 14:20:
let erop dat je wel een backup maakt van je home partitie..... maar really, de aparte boot partitie is alleen in heel specifieke gevallen nodig, en zeker niet bij zo'n kleine opslag als jij hebt...

Zou een snapshot in vSphere ook voldoende zijn?

[Hero of Time]

borft schreef op donderdag 11 juni 2015 @ 14:14:
maar waarom heb je eigenlijk een apartie boot partitie? De makkelijkste oplossing is gewoon /boot verplaatsen naar je root partitie, dan ben je in 1x klaar.

borft schreef op donderdag 11 juni 2015 @ 14:20:
let erop dat je wel een backup maakt van je home partitie..... maar really, de aparte boot partitie is alleen in heel specifieke gevallen nodig.

Jullie bedoelen in gevallen als LVM gebruiken? Want /boot kan niet onderdeel zijn van je LVM, omdat Grub daar niet meer overweg kan.

@sj31:
Dit ga je niet zomaar doen. Beter kijk je wat er in /boot staat, mogelijk tig kernel versies die je gewoon weg moet smijten via je package maanger. Simpelweg de schijf maar vergroten is nooit een oplossing, dat is een tijdelijke work around en snap je niet wat er aan de hand is en waarom het gebeurt. Straks heb je een /boot van 10 GB nodig, simpelweg omdat je nooit naar het onderliggende probleem hebt gekeken en maar domweg de schijf vergroot.

[borft]

Interessant dat je dat zegt, ik draai hier namelijk met:

code:

/dev/mapper/mike-root  9.8G  1.6G  7.7G  18% /
/dev/mapper/mike-usr   9.8G  7.1G  2.2G  77% /usr
/dev/mapper/mike-tmp   9.8G  1.8G  7.5G  20% /tmp
/dev/mapper/mike-home  173G  116G   58G  67% /home
/dev/mapper/mike-var   9.8G  2.8G  6.5G  31% /var

Maar, in het geval van OP staat de root partitie niet eens op LVM, en is ook niet heel erg groot. Ik zie werkelijk geen enkele reden om /boot op een aparte partitie te zetten, en in dit geval al helemaal niet, aangezien er blijkbaar ook ruimtegebrek is.
waarbij /boot op mijn root partitie leeft, die dus inderdaad op lvm staat

[pennywiser]

Ik draai anders alles met lvm ook de bootable partitie:

code:

/dev/mapper/os-root            9.8G  1.9G  7.4G  20% /

Edit: LVM op MDADM nog wel..

[ Voor 14% gewijzigd door pennywiser op 11-06-2015 14:35 ]

[sj31]

Hero of Time schreef op donderdag 11 juni 2015 @ 14:30:
[...]


[...]

Jullie bedoelen in gevallen als LVM gebruiken? Want /boot kan niet onderdeel zijn van je LVM, omdat Grub daar niet meer overweg kan.

@sj31:
Dit ga je niet zomaar doen. Beter kijk je wat er in /boot staat, mogelijk tig kernel versies die je gewoon weg moet smijten via je package maanger. Simpelweg de schijf maar vergroten is nooit een oplossing, dat is een tijdelijke work around en snap je niet wat er aan de hand is en waarom het gebeurt. Straks heb je een /boot van 10 GB nodig, simpelweg omdat je nooit naar het onderliggende probleem hebt gekeken en maar domweg de schijf vergroot.

code:

root@host:~# ls /boot
abi-3.16.0-30-generic  config-3.16.0-30-generic  grub                          initrd.img-3.16.0-39-generic  System.map-3.16.0-30-generic  vmlinuz-3.16.0-30-generic
abi-3.16.0-36-generic  config-3.16.0-36-generic  initrd.img-3.16.0-30-generic  lost+found                    System.map-3.16.0-36-generic  vmlinuz-3.16.0-36-generic
abi-3.16.0-37-generic  config-3.16.0-37-generic  initrd.img-3.16.0-36-generic  memtest86+.bin                System.map-3.16.0-37-generic  vmlinuz-3.16.0-37-generic
abi-3.16.0-38-generic  config-3.16.0-38-generic  initrd.img-3.16.0-37-generic  memtest86+.elf                System.map-3.16.0-38-generic  vmlinuz-3.16.0-38-generic
abi-3.16.0-39-generic  config-3.16.0-39-generic  initrd.img-3.16.0-38-generic  memtest86+_multiboot.bin      System.map-3.16.0-39-generic  vmlinuz-3.16.0-39-generic
root@host:~#

Zeg jij het maar?
Als jij zegt dat het niet zomaar kan wat moet ik dan doen zodat het wel kan, ik wil niet constant een monitoring melding krijgen voor te weinig diskspace

[borft]

Probeer anders eens het volgende:
uname -a
dat geeft je de running kernel. Alles wat ouder is kan in principe weg, en met dpkg --list |grep image kan je vinden welke kernel packages geinstalleerd staan. De oudere versies kan je dan wegmikken.

[sj31]

de partitie indeling is met de setup van de server alsvolgt ingesteld door mijn collega:

code:

Partitieindeling (30GB disk):
Primary 250MB ext2 /boot (bootable)
Primary 15GB ext4 /
Primary 8GB swap
Primary rest LVM
/home ext4 10GB op LVM

[pennywiser]

Dus, cp -pr /boot / -> Grub aanpassen -> fstab aanpassen.

Pas rebooten als je ernaast zit.

[DeBolle]

Ubuntu en oude(re) kernels: https://help.ubuntu.com/c...entation/RemoveOldKernels

[pennywiser]

sj31 schreef op donderdag 11 juni 2015 @ 14:36:
de partitie indeling is met de setup van de server alsvolgt ingesteld door mijn collega:

code:

Partitieindeling (30GB disk):
Primary 250MB ext2 /boot (bootable)
Primary 15GB ext4 /
Primary 8GB swap
Primary rest LVM
/home ext4 10GB op LVM

Ziet er deels uit als een tijdens de installatie door ge-enterde default partitionering.

[Hero of Time]

sj31 schreef op donderdag 11 juni 2015 @ 14:33:
[...]

code:

root@host:~# ls /boot
abi-3.16.0-30-generic  config-3.16.0-30-generic  grub                          initrd.img-3.16.0-39-generic  System.map-3.16.0-30-generic  vmlinuz-3.16.0-30-generic
abi-3.16.0-36-generic  config-3.16.0-36-generic  initrd.img-3.16.0-30-generic  lost+found                    System.map-3.16.0-36-generic  vmlinuz-3.16.0-36-generic
abi-3.16.0-37-generic  config-3.16.0-37-generic  initrd.img-3.16.0-36-generic  memtest86+.bin                System.map-3.16.0-37-generic  vmlinuz-3.16.0-37-generic
abi-3.16.0-38-generic  config-3.16.0-38-generic  initrd.img-3.16.0-37-generic  memtest86+.elf                System.map-3.16.0-38-generic  vmlinuz-3.16.0-38-generic
abi-3.16.0-39-generic  config-3.16.0-39-generic  initrd.img-3.16.0-38-generic  memtest86+_multiboot.bin      System.map-3.16.0-39-generic  vmlinuz-3.16.0-39-generic
root@host:~#

Zeg jij het maar?
Als jij zegt dat het niet zomaar kan wat moet ik dan doen zodat het wel kan, ik wil niet constant een monitoring melding krijgen voor te weinig diskspace

Je hebt 5 kernels op 't systeem staan. Hoeveel denk je er nodig te hebben? Aan 2 heb je meer dan zat, en dat is de laatste en huidige.

Ubuntu heeft standaard instellingen voor apt dat er voor zorgt dat je nooit een kernel in de auto-removable lijst krijgt. Dat is zo idioot IMO, het is gewoon vragen om dit soort problemen.

[pennywiser]

Hero of Time schreef op donderdag 11 juni 2015 @ 14:42:
[...]

Je hebt 5 kernels op 't systeem staan. Hoeveel denk je er nodig te hebben? Aan 2 heb je meer dan zat, en dat is de laatste en huidige.

Ubuntu heeft standaard instellingen voor apt dat er voor zorgt dat je nooit een kernel in de auto-removable lijst krijgt. Dat is zo idioot IMO, het is gewoon vragen om dit soort problemen.

Ze kunnen eraf, eens, maar als je een kernel update doet, zou ik de oude eerst maar gewoon laten staan een tijdje. Kernel stukgemaakt, en de oude al verwijderd, heerlijk.

Hiermee krijg je wel je ruimte terug.

code:

dpkg -l | grep linux
apt-get remove kernelpackage naam

[ Voor 8% gewijzigd door pennywiser op 11-06-2015 14:46 ]

[Hero of Time]

pennywiser schreef op donderdag 11 juni 2015 @ 14:44:
[...]

Ze kunnen eraf, eens, maar als je een kernel update doet, zou ik de oude eerst maar gewoon laten staan een tijdje. Kernel stukgemaakt, en de oude al verwijderd, heerlijk.

Daarom zeg ik ook dat je er aan 2 genoeg hebt. Degene die je draait en degene die je nieuw installeert. Als hij -30 draait blijft die en kan alles tot -39 weg. Fedora, Red Hat en CentOS doen dat geweldig. Ubuntu is gewoon retarded hiermee door alles maar te bewaren.

[pennywiser]

Ubuntu (Debian fork) installeert werkelijk nieuwe kernelpackages als "update", waar Debian alleen security updates uitvoert aan de geinstalleerde en draaiende kernel. Beide verwijderen ze niets tenzij de user dat wil.

[ Voor 3% gewijzigd door pennywiser op 11-06-2015 14:55 ]

[sj31]

Heb net overige kernel's verwijderd en laatste en huidige kernel overgehouden. Eerste had ik 37MB vrij en nu 142MB, maar alsnog vind ik de boot partitie redelijk klein, is er echt geen manier hoe ik deze zou kunnen vergroten?

[CyBeR]

sj31 schreef op donderdag 11 juni 2015 @ 14:10:
Hallo Allen,

Ik kreeg de nagios (Monitoring) melding: DISK CRITICAL - free space: /boot 36 MB (16% inode=99%):

Er is dus te weinig opslag in de boot partitie.

Dat is een interessante conclusie. Ik zou zeggen dat je teveel opslag gebruikt in de boot-partitie. Gooi wat oude kernels weg.

[sj31]

CyBeR schreef op donderdag 11 juni 2015 @ 15:13:
[...]


Dat is een interessante conclusie. Ik zou zeggen dat je teveel opslag gebruikt in de boot-partitie. Gooi wat oude kernels weg.

Lees me laatste bericht

[CyBeR]

sj31 schreef op donderdag 11 juni 2015 @ 15:16:
[...]


Lees me laatste bericht

De enige manier om de partitie te vergroten is de volgende partitie verkleinen.

Overigens is 250MB makkelijk ruim genoeg voor een /boot. Ik maak die altijd 100MB en dat is al ruim zat.

[ninjazx9r98]

sj31 schreef op donderdag 11 juni 2015 @ 15:04:
Heb net overige kernel's verwijderd en laatste en huidige kernel overgehouden. Eerste had ik 37MB vrij en nu 142MB, maar alsnog vind ik de boot partitie redelijk klein, is er echt geen manier hoe ik deze zou kunnen vergroten?

De vraag die je jezelf zou moeten stellen is waarom je van mening bent dat die partitie klein is of beter gezegd waarom deze (veel) groter zou moeten zijn.
Het voegt weinig tot niets toe om een grotere partitie voor boot te hebben.

[Hero of Time]

Mijn /boot:

Filesystem                Size  Used Avail Use% Mounted on
/dev/sda2                 227M   24M  187M  12% /boot

Dus, waarom zou ik meer dan 250 MB, of in dit geval 227 MB, nodig hebben als er net iets meer dan 12% wordt gebruikt? Zolang je netjes bijhoud dat je oude kernels moet opschonen is er niets aan de hand. Het is je werk om dat in de gaten te houden. Wees blij dat Nagios nog een melding gaf, voor hetzelfde geld had je blind de server een herstart gegeven om dan pas erachter te komen dat 't niet volledig beschikbaar is en je server niet meer start.

[sj31]

Hero of Time schreef op donderdag 11 juni 2015 @ 16:18:
Mijn /boot:

Filesystem                Size  Used Avail Use% Mounted on
/dev/sda2                 227M   24M  187M  12% /boot

Dus, waarom zou ik meer dan 250 MB, of in dit geval 227 MB, nodig hebben als er net iets meer dan 12% wordt gebruikt? Zolang je netjes bijhoud dat je oude kernels moet opschonen is er niets aan de hand. Het is je werk om dat in de gaten te houden. Wees blij dat Nagios nog een melding gaf, voor hetzelfde geld had je blind de server een herstart gegeven om dan pas erachter te komen dat 't niet volledig beschikbaar is en je server niet meer start.

Server is restartproof gemaakt, als de stroom uit zou vallen en dan weer aan zou gaan zou de server vanzelf weer aan gaan en alles opnieuw opstarten. Daarnaast kan de stroom niet uitvallen want de vSphere draait op 8 ESX Servers die allemaal een UPS hebben.
Het is niet mijn werk om dit in de gaten te houden, dat is dat van mijn collega maar toch bedankt dat je het even zegt.

[Hero of Time]

sj31 schreef op donderdag 11 juni 2015 @ 16:26:
[...]


Server is restartproof gemaakt, als de stroom uit zou vallen en dan weer aan zou gaan zou de server vanzelf weer aan gaan en alles opnieuw opstarten. Daarnaast kan de stroom niet uitvallen want de vSphere draait op 8 ESX Servers die allemaal een UPS hebben.
Het is niet mijn werk om dit in de gaten te houden, dat is dat van mijn collega maar toch bedankt dat je het even zegt.

Het gaat erom dat standaard de nieuwste kernel wordt geselecteerd voor opstarten. Als de vmlinuz in /boot niet volledig weggeschreven kan worden, krijg je een kernel panic en start je machine dus niet. Heb 't hier bij een collega gezien, de laptop deed 't niet meer. Oorzaak, /boot was vol, ging herstarten omdat Ubuntu dat zei en alles was op de achtergrond gedaan, dus geen foutmelding gezien dat de schijf vol was.

Ga NOOIT, maar dan ook echt NOOIT uit van systemen die 'hufterproof' zijn, want dat bestaat niet. Het kan ALTIJD stuk en gebeurt dan ook altijd als je 't niet verwacht. Of nog beter, als je 't had kunnen weten door te weten wat er nou op die machine gebeurt en is uitgevoerd.

[CyBeR]

sj31 schreef op donderdag 11 juni 2015 @ 16:26:
[...]
Daarnaast kan de stroom niet uitvallen want de vSphere draait op 8 ESX Servers die allemaal een UPS hebben.

UPS'en gaan nooit stuk inderdaad.

[CAPSLOCK2000]

Als ik een aparte boot maak (als) dan maak ik hem groot, 1GB ofzo. Zo'n GB meer of minder is totaal verwaarloosbaar op moderne systemen en het geeft iets meer speelruimte.

Ten tweede laat ik altijd veel ruimte ongebruikt. In dit geval had 10 GB gebruikt voor / en 1 GB voor home.
Als de ruimte ergens op raakt dan voeg ik op dat moment een extra GB toe. Uitbreiden is altijd makkelijker dan verkleinen.

In VMWare doe ik het nog extremere. Ik maak een thinly allocated vdisk aan van 100GB ook al weet ik dat ik maar 10GB nodig heb voor dat systeem. Omdat het thin is wordt de extra ruimte toch niet gebruikt. Als het in de toekomst ooit nodig is kan ik die hele 100GB direct inzetten. Er zijn ook wel andere manier om dat online te doen maar deze manier vind ik het makkelijkste. (Zorg wel voor monitoring van je VMWare datastore want met thin disks is het een stuk moeilijker te bepalen wanneer zo'n ding bijna vol zit).

[iMars]

Misschien is dit ook wel handig : https://help.ubuntu.com/c...entation/RemoveOldKernels

[Verwijderd]

Hero of Time schreef op donderdag 11 juni 2015 @ 14:30:
[...]


[...]

Jullie bedoelen in gevallen als LVM gebruiken? Want /boot kan niet onderdeel zijn van je LVM, omdat Grub daar niet meer overweg kan.

@sj31:
Dit ga je niet zomaar doen. Beter kijk je wat er in /boot staat, mogelijk tig kernel versies die je gewoon weg moet smijten via je package maanger. Simpelweg de schijf maar vergroten is nooit een oplossing, dat is een tijdelijke work around en snap je niet wat er aan de hand is en waarom het gebeurt. Straks heb je een /boot van 10 GB nodig, simpelweg omdat je nooit naar het onderliggende probleem hebt gekeken en maar domweg de schijf vergroot.

Dat is niet waar. /boot kan prima onderdeel zijn van LVM. GRUB kan prima een kernel lezen vanaf een LV. Dus ik weet niet waarom de meeste hier nog steeds /boot op een aparte partitie plaatsen maar dat is al een hele tijd niet meer nodig.

edit:

Ik maak zelf altijd kleine LV's. Dat wordt je namelijk geforceerd om te onderzoeken waarom een LV ineens vol is. Misschien een logrotate instelling vergeten etc.

[ Voor 15% gewijzigd door Verwijderd op 13-06-2015 12:36 ]

[Kees]

Stroom (en servers) kunnen altijd uitvallen..

En verder is het zoals men in dit topic al gezegt heeft. /boot is er voor je kernels, die nemen ongeveer 30MB per stuk in beslag. Op 230MB kun je dus makkelijk 7 kernels bewaren, maar in de praktijk heb je er maar 2 nodig, namelijk degene die je nu draait en de nieuwste. En dat kost je 60MB. Als je dus nagios alerts krijgt moet je ingeving zijn om de boel op te ruimen en niet om de boel te vergroten (kijk eerst maar of apt-get autoremove wat weg wil gooien en doe het anders handmatig met apt-get remove).

De boel te vergroten is hetzelfde als een grotere prullenbak kopen omdat de oude prullenbak vol is. Dat doe je ook niet, je gooit gewoon de oude prullenbak leeg en dan heb je weer genoeg ruimte.

Verwijderd schreef op zaterdag 13 juni 2015 @ 12:34:
[...]


Dat is niet waar. /boot kan prima onderdeel zijn van LVM. GRUB kan prima een kernel lezen vanaf een LV. Dus ik weet niet waarom de meeste hier nog steeds /boot op een aparte partitie plaatsen maar dat is al een hele tijd niet meer nodig.

edit:

Ik maak zelf altijd kleine LV's. Dat wordt je namelijk geforceerd om te onderzoeken waarom een LV ineens vol is. Misschien een logrotate instelling vergeten etc.

Gaat dat ook goed met bare-metal en een UEFI bios boot?

Zelf maak ik vrijwel nooit gebruik van LVM, ik kan redelijk goed inschatten hoeveel ruimte een server nodig heeft, en op het moment dat hij daar dan overheen gaat dan is er waarschijnlijk inderdaad iets mis en dan pak ik liever de oorzaak aan. Dit gecombineeert met 'pro-active' monitoring; Ik wil een alert krijgen zodra:
- De disk onder de 10% komt (~2 dagen om het op te lossen)
- De disk onder de 25% komt en met meer dan 5% daalt in 5 uur (~1 dag om het op te lossen)
- De disk onder de 25% komt en met meer dan 5% daalt in een dag (~5 dagen om het op te lossen)

[ Voor 43% gewijzigd door Kees op 13-06-2015 13:01 ]

[Verwijderd]

Kees schreef op zaterdag 13 juni 2015 @ 12:53:
Stroom (en servers) kunnen altijd uitvallen..

En verder is het zoals men in dit topic al gezegt heeft. /boot is er voor je kernels, die nemen ongeveer 30MB per stuk in beslag. Op 230MB kun je dus makkelijk 7 kernels bewaren, maar in de praktijk heb je er maar 2 nodig, namelijk degene die je nu draait en de nieuwste. En dat kost je 60MB. Als je dus nagios alerts krijgt moet je ingeving zijn om de boel op te ruimen en niet om de boel te vergroten (kijk eerst maar of apt-get autoremove wat weg wil gooien en doe het anders handmatig met apt-get remove).

De boel te vergroten is hetzelfde als een grotere prullenbak kopen omdat de oude prullenbak vol is. Dat doe je ook niet, je gooit gewoon de oude prullenbak leeg en dan heb je weer genoeg ruimte.

[...]
Gaat dat ook goed met bare-metal en een UEFI bios boot?

Ja dat is geen probleem.

[Hero of Time]

Verwijderd schreef op zaterdag 13 juni 2015 @ 12:34:
[...]

Dat is niet waar. /boot kan prima onderdeel zijn van LVM. GRUB kan prima een kernel lezen vanaf een LV. Dus ik weet niet waarom de meeste hier nog steeds /boot op een aparte partitie plaatsen maar dat is al een hele tijd niet meer nodig.

Verwijderd schreef op zaterdag 13 juni 2015 @ 13:16:
[...]

Ja dat is geen probleem.

Heb je een bron dat dit bevestigd?

[CyBeR]

Grub heeft een module om lvm te lezen, net als ext3 en xfs en etc.

[Hero of Time]

En hoe wil je die module laden als de modules, die allemaal in /boot/grub staan, onderdeel is van LVM? Kip/Ei verhaal dus. Wat ik heb gevonden, is dat je een aparte partitie moet hebben waar die grub modules zijn te vinden. Voor UEFI boot net zo, moet Grub ook nog een BIOS partitie hebben om te kunnen booten als /boot onderdeel is van LVM.

Hoe je 't wendt of keert, bij een normale standaard installatie met LVM kan /boot niet zomaar onderdeel zijn van LVM. Je zal hoe dan ook een partitie buiten LVM moeten hebben hiervoor.

[CyBeR]

Mja, ik zei ook niet dat ik 't een goed idee vond. / op LVM imo ook niet. Je maakt de boel er een stuk complexer mee en als er iets mis gaat 't 't super moeilijk om 't te fixen. LVM is op zich niet bepaald nutteloos (hoewel bij VM's het nut een stuk lager is imo) maar ik beperk dat soort dingen graag tot m'n data storage.

[Basz0r]

Hero of Time schreef op zaterdag 13 juni 2015 @ 15:52:
En hoe wil je die module laden als de modules, die allemaal in /boot/grub staan, onderdeel is van LVM? Kip/Ei verhaal dus. Wat ik heb gevonden, is dat je een aparte partitie moet hebben waar die grub modules zijn te vinden. Voor UEFI boot net zo, moet Grub ook nog een BIOS partitie hebben om te kunnen booten als /boot onderdeel is van LVM.

Hoe je 't wendt of keert, bij een normale standaard installatie met LVM kan /boot niet zomaar onderdeel zijn van LVM. Je zal hoe dan ook een partitie buiten LVM moeten hebben hiervoor.

Ik heb onlangs nog een Ubuntu server ingericht met de /boot partitie als LV. Dat werkte prima. Bij CentOS moet je inderdaad een aparte partitie op de disk maken voor de /boot partitie, omdat de gebruikte GRUB versie niet boot vanaf LVM. Ik vond overigens in de Arch wiki hierover een opmerking.

Warning: /boot cannot reside in LVM when using GRUB Legacy, which does not support LVM. GRUB users do not have this limitation. If you need to use GRUB Legacy, you must create a separate /boot partition and format it directly.

Bron: https://wiki.archlinux.org/index.php/LVM

[Verwijderd]

Hero of Time schreef op zaterdag 13 juni 2015 @ 15:52:
En hoe wil je die module laden als de modules, die allemaal in /boot/grub staan, onderdeel is van LVM? Kip/Ei verhaal dus. Wat ik heb gevonden, is dat je een aparte partitie moet hebben waar die grub modules zijn te vinden. Voor UEFI boot net zo, moet Grub ook nog een BIOS partitie hebben om te kunnen booten als /boot onderdeel is van LVM.

Hoe je 't wendt of keert, bij een normale standaard installatie met LVM kan /boot niet zomaar onderdeel zijn van LVM. Je zal hoe dan ook een partitie buiten LVM moeten hebben hiervoor.

Ik zou zeggen probeer het eens? Het is echt niet moeilijk. Het is helemaal een eitje met Ubuntu want daar kun je gewoon in de menu's aangeven dat boot op een lv moet. Je hoeft helemaal geen speciale dingen te doen. Het klopt inderdaad dat GRUB legacy niet kan lezen van een lv maarja de meeste distro's gebruiken GRUB legacy helemaal niet meer.

[Hero of Time]

Het ziet er naar uit dat ik mijn woorden moet terugnemen. Net met Debian Testing getest en heb daar 1 partitie gemaakt met daarin 2 volumes, 1x boot en 1x root. Het klaagde niet en startte gewoon netjes op.

Neemt nog steeds niet weg dat de TS gewoon oude kernels moet opschonen, ipv /boot vergroten. 250 MB voor /boot is meer dan zat.

[Thralas]

De meeste partitioning tools houden tegenwoordig een offset van 2048 sectors voor de eerste partitie aan.

Daarmee is er zo'n ~1 MB voor grub om z'n core.img te embedden, met daarin alle modules om /boot te mounten. LVM (of wat dan ook) is daarom tegenwoordig dus geen probleem.

[_JGC_]

Hero of Time schreef op zaterdag 13 juni 2015 @ 15:52:
En hoe wil je die module laden als de modules, die allemaal in /boot/grub staan, onderdeel is van LVM? Kip/Ei verhaal dus. Wat ik heb gevonden, is dat je een aparte partitie moet hebben waar die grub modules zijn te vinden. Voor UEFI boot net zo, moet Grub ook nog een BIOS partitie hebben om te kunnen booten als /boot onderdeel is van LVM.

Hoe je 't wendt of keert, bij een normale standaard installatie met LVM kan /boot niet zomaar onderdeel zijn van LVM. Je zal hoe dan ook een partitie buiten LVM moeten hebben hiervoor.

Ik boot een server vanaf LVM met grub2. Het enige wat je nodig hebt is vrije ruimte tussen de MBR en eerste partitie. Grub knalt de bootloader in mbr, de benodigde modules (lvm en ext2/3/4) komen in de vrije ruimte voor de eerste partitie en dat werkt prima.