[etch / lenny] upgrade etch -> lenny, kernel niet geupgrade

[Feanaro]

Vorige week heb ik mijn debian etch installatie geupgrade naar lenny volgens de gangbare methode (sources.list aanpassen aan lenny, apt-get update, apt-get dist-upgrade). Daarna opnieuw opgestart, omdat daarmee de nieuwe kernel geladen zou worden.

Inmiddels heb ik al een paar keer opnieuw gestart, maar bij inloggen via SSH en via het "uname -r" commando staat er nog steeds "2.6.24-etchnhalf.1-amd64," terwijl lenny toch de 2.6.26 zou moeten gebruiken en er geen etch meer zou moeten staan volgens mij. Het lijkt dus alsof hij alles geupdate heeft, behalve de kernel...
Ik heb zitten googlen, maar kon niets anders vinden dan dat je na een upgrade moet rebooten om de nieuwe 2.6.26 kernel te laten en hoe je een kernel compileert.

Geen van deze dingen ben ik in geïnteresseerd en ik vroeg me af of meer mensen hier mee zitten en hoe je dit mogelijk verhelpt.

[Verwijderd]

Wat is de output van:

aptitude search linux-image

[maleadt]

Je grub zal verkeerd geinstalleerd staan. Kijk eens via "dpkg -l | grep linux" of de 2.6.26 geinstalleerd is. Zoja, duik eens in "/boot/grub/menu.lst" om te zien of de default niet verkeerd ingesteld staat oid. Zonee, "aptitude install linux-image-2.6.26-2-amd64", of whatever je wil.

[Feanaro]

aptitude search linux-image:

v linux-image -
v linux-image-2.6 -
p linux-image-2.6-amd64 - Linux 2.6 image on AMD64
i linux-image-2.6-amd64-etchnhalf - Linux 2.6-etchnhalf image on AMD64
p linux-image-2.6-openvz-amd64 - Linux 2.6 image on AMD64, OpenVZ support
p linux-image-2.6-vserver-amd64 - Linux 2.6 image on AMD64, Linux-VServer support
p linux-image-2.6-xen-amd64 - Linux 2.6 image on AMD64, oldstyle Xen support
i linux-image-2.6.24-etchnhalf.1-amd64 - Linux 2.6.24 image on AMD64
p linux-image-2.6.26-1-amd64 - Linux 2.6.26 image on AMD64
p linux-image-2.6.26-1-openvz-amd64 - Linux 2.6.26 image on AMD64, OpenVZ support
p linux-image-2.6.26-1-vserver-amd64 - Linux 2.6.26 image on AMD64, Linux-VServer support
p linux-image-2.6.26-1-xen-amd64 - Linux 2.6.26 image on AMD64, oldstyle Xen support
p linux-image-2.6.26-2-amd64 - Linux 2.6.26 image on AMD64
p linux-image-2.6.26-2-openvz-amd64 - Linux 2.6.26 image on AMD64, OpenVZ support
p linux-image-2.6.26-2-vserver-amd64 - Linux 2.6.26 image on AMD64, Linux-VServer support
p linux-image-2.6.26-2-xen-amd64 - Linux 2.6.26 image on AMD64, oldstyle Xen support
p linux-image-amd64 - Linux image on AMD64
p linux-image-openvz-amd64 - Linux image on AMD64, OpenVZ support
p linux-image-vserver-amd64 - Linux image on AMD64, Linux-VServer support
p linux-image-xen-amd64 - Linux image on AMD64, oldstyle Xen support

[Feanaro]

dpkg -l | grep linux

ii doc-linux-text 2008.08-1 Linux HOWTOs and FAQs in ASCII format
ii libselinux1 2.0.65-5 SELinux shared libraries
ii linux-image-2.6-amd64-etchnhalf 2.6.24+13~etchnhalf.1 Linux 2.6-etchnhalf image on AMD64
ii linux-image-2.6.24-etchnhalf.1-amd64 2.6.24-6~etchnhalf.8etch1 Linux 2.6.24 image on AMD64
ii linux-libc-dev 2.6.26-15lenny2 Linux support headers for userspace development
ii python-selinux 2.0.65-5 Python bindings to SELinux shared libraries
ii selinux-policy-default 2:0.0.20080702-6 Strict and Targeted variants of the SELinux policy
rc selinux-policy-refpolicy-targeted 0.0.20061018-5.1+etch1 Targeted variant of the SELinux reference policy
ii util-linux 2.13.1.1-1 Miscellaneous system utilities

Daar staat hij wel bij, ik kijk even in grub...

[Feanaro]

dit is wat er onderin menu.lst van GRUB staat:

title Debian GNU/Linux, kernel 2.6.24-etchnhalf.1-amd64
root (hd0,0)
kernel /vmlinuz-2.6.24-etchnhalf.1-amd64 root=/dev/mapper/bavaria-root ro quiet
initrd /initrd.img-2.6.24-etchnhalf.1-amd64

title Debian GNU/Linux, kernel 2.6.24-etchnhalf.1-amd64 (single-user mode)
root (hd0,0)
kernel /vmlinuz-2.6.24-etchnhalf.1-amd64 root=/dev/mapper/bavaria-root ro single
initrd /initrd.img-2.6.24-etchnhalf.1-amd64

Wat moet ik hierin veranderen dan?

[ Voor 3% gewijzigd door Feanaro op 16-05-2009 19:13 ]

[Verwijderd]

aptitude install linux-image-amd64

Daarna rebooten en de oude kernel verwijderen met:

aptitude purge linux-image-2.6-amd64-etchnhalf

De linux-libc-dev 2.6.26-15lenny2 package is trouwens de development files voor de libc.so.6 library die is gecompileerd tegen de 2.6.26-15 kernel headers.

[ Voor 34% gewijzigd door Verwijderd op 16-05-2009 19:17 ]

[Feanaro]

Dit is gelukt, na een reboot wordt de nieuwe kernel geladen.

Echter enige weken later vind ik een nieuw probleem. Aptitude upgrade vindt bij het upgraden (nieuwe kernel) dit:

Installing new version of config file /etc/debian_version ...
(Reading database ... 58905 files and directories currently installed.)
Preparing to replace linux-image-2.6.26-2-amd64 2.6.26-15lenny2 (using .../linux-image-2.6.26-2-amd64_2.6.26-17_amd64.deb) ...
The directory /lib/modules/2.6.26-2-amd64 still exists. Continuing as directed.
Done.
Unpacking replacement linux-image-2.6.26-2-amd64 ...
dpkg: error processing /var/cache/apt/archives/linux-image-2.6.26-2-amd64_2.6.26-17_amd64.deb (--unpack):
failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during `./lib/modules/2.6.26-2-amd64/kernel/drivers/net/wireless/ath5k/ath5k.ko': No space left on device
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /vmlinuz-2.6.26-2-amd64
Found kernel: /vmlinuz-2.6.24-etchnhalf.1-amd64
Updating /boot/grub/menu.lst ... done

Preparing to replace gnupg 1.4.9-3 (using .../gnupg_1.4.9-3+lenny1_amd64.deb) ...
Unpacking replacement gnupg ...
Processing triggers for man-db ...
Errors were encountered while processing:
/var/cache/apt/archives/linux-image-2.6.26-2-amd64_2.6.26-17_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up gnupg (1.4.9-3+lenny1) ...
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done

Om een of andere vage reden wil hij de nieuwe kernel dus niet installeren. Ik krijg het niet voor elkaar. Nu wilde ik daar eigenlijk een nieuwe topic voor openen, maar wellicht houdt het verband met mijn eerdere probleem (bovenstaand), dus heb ik het hier bij geplaatst.

[moto-moi]

Zo vaag is die reden niet hoor:

code:

No space left on device

doet toch redelijk vermoeden dat een schijf vol is

[Feanaro]

Ja, maar dat lijkt dus niet echt het geval te zijn. df -m geeft:

Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/bavaria-root 268 214 40 85% /
tmpfs 242 0 242 0% /lib/init/rw
udev 10 1 10 1% /dev
tmpfs 242 0 242 0% /dev/shm
/dev/sda1 236 34 191 15% /boot
/dev/mapper/bavaria-home 929015 661363 220461 75% /home
/dev/mapper/bavaria-tmp 380 12 350 4% /tmp
/dev/mapper/bavaria-usr 4808 1312 3252 29% /usr
/dev/mapper/bavaria-var 2886 2389 351 88% /var

Die 21 MB voor de archives die ie nodig heeft, moeten er dan toch gewoon zijn?

[ Voor 131% gewijzigd door een moderator op 02-07-2009 22:58 . Reden: stomme moto-moi moet niet op 'edit' klikken als 'ie quote moet hebben |:( ]

[moto-moi]

Ja, maar dat lijkt dus niet echt het geval te zijn. df -m geeft:

Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/bavaria-root 268 214 40 85% /

Die 21 MB voor de archives die ie nodig heeft, moeten er dan toch gewoon zijn?

De archives zijn er ook zo te zien, maar hij gaat ze in /lib/modules neerzetten, en als ik kijk naar de laatste kernel op een van mijn debian systemen:

hylke@asclepius:/lib/modules/2.6.26-1-amd64$ du -hs
78M	.

(en da's niet de laatste kernel, I know )
dus ik kan me zo voorstellen dat hij het niet in je root kwijt kan ofzo als je maar 40MB vrij hebt

[Feanaro]

Hmm... is er een manier om die boel op te ruimen? Ik heb dit probleem nog niet eerder gehad, dus ruimte is er eerdaags wel gewoon geweest...

Heb aptitude clean gedaan om oude archives weg te doen, maar dat heeft niet het beoogde resultaat...

Is het anders mogelijk om die partitie te vergroten of zo?

[ Voor 38% gewijzigd door Feanaro op 02-07-2009 23:17 ]

[Verwijderd]

Feanaro schreef op donderdag 02 juli 2009 @ 23:02:
Is het anders mogelijk om die partitie te vergroten of zo?

Je gebruikt toch lvm

[Bergen]

Feanaro schreef op donderdag 02 juli 2009 @ 23:02:
Hmm... is er een manier om die boel op te ruimen? Ik heb dit probleem nog niet eerder gehad, dus ruimte is er eerdaags wel gewoon geweest...

Nou.. een rootpartitie van 250 MB noem ik niet echt veel ruimte. Je mag die rootpartitie best een paar GB aan ruimte geven. Het moet niet nodig zijn om de hele tijd te controleren of je partities bijna vol zitten.

Naast de root-partitie geldt dit ook voor /var, waar bijvoorbeeld ook alle packages van apt worden opgeslagen. Kijk maar eens met "du -ch /var/cache/apt/archives/" hoeveel er momenteel aan packages gecached is. (Tip: "apt-get clean" leegt de package cache directory.) Stel dat er een keer een proces is wat vreselijk veel logging genereert, dan moet /var/log ook niet snel vol lopen. Zorg voor een beetje ademruimte. Je home-directory heeft genoeg vrije ruimte, daarvan kun je wel een paar GB aan root en /var geven.

[ Voor 8% gewijzigd door Bergen op 03-07-2009 01:35 ]

[Verwijderd]

Bergen schreef op vrijdag 03 juli 2009 @ 01:31:
[...]
Nou.. een rootpartitie van 250 MB noem ik niet echt veel ruimte. Je mag die rootpartitie best een paar GB aan ruimte geven. Het moet niet nodig zijn om de hele tijd te controleren of je partities bijna vol zitten.

Een paar GB voor / is volkomen waanzin, 512MB voor / is meer dan genoeg.

[Feanaro]

Tja wat die grootte van de / en zo betreft, die heb ik ooit jaren geleden op aanraden van het woody installatieprogramma zo gemaakt.

Wat bedoel je met die lvm? Kan ik daarmee on-the-fly partities resizen? Want anders moet ik met een boot-USB in de weer met scherm en toetsenbord, geloof ik (doe nu alles op afstand met SSH).

[Verwijderd]

Verwijderd schreef op vrijdag 03 juli 2009 @ 08:29:

Een paar GB voor / is volkomen waanzin, 512MB voor / is meer dan genoeg.

Afhankelijk van wat je als losse partitie gaat mounten
In dit geval zou het inderdaad wel voldoende moeten kunnen zijn omdat /var, /tmp, /home en /usr apart worden gemount.

[Verwijderd]

Feanaro schreef op vrijdag 03 juli 2009 @ 09:51:
Kan ik daarmee on-the-fly partities resizen?

Ja.

Dit is toch van jou?

code:

Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/bavaria-root 268 214 40 85% /
tmpfs 242 0 242 0% /lib/init/rw
udev 10 1 10 1% /dev
tmpfs 242 0 242 0% /dev/shm
/dev/sda1 236 34 191 15% /boot
/dev/mapper/bavaria-home 929015 661363 220461 75% /home
/dev/mapper/bavaria-tmp 380 12 350 4% /tmp
/dev/mapper/bavaria-usr 4808 1312 3252 29% /usr
/dev/mapper/bavaria-var 2886 2389 351 88% /var

Linkje: A Beginner's Guide To LVM http://www.howtoforge.com/linux_lvm

[Verwijderd]

Verwijderd schreef op vrijdag 03 juli 2009 @ 10:29:
[...]

Afhankelijk van wat je als losse partitie gaat mounten

We hebben het hier inderdaad over dit geval en niet over user John Doe met 1 partitie

Voorbeeldje van mijn Jaunty Desktop met alle toeters en bellen:

code:

stacheldraht@lucky-star:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              510M  202M  282M  42% /
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
varrun                2.0G  112K  2.0G   1% /var/run
varlock               2.0G     0  2.0G   0% /var/lock
udev                  2.0G  188K  2.0G   1% /dev
tmpfs                 2.0G  192K  2.0G   1% /dev/shm
lrm                   2.0G  2.5M  1.9G   1% /lib/modules/2.6.28-13-generic/volatile
/dev/mapper/raid-home
                       50G   17G   30G  37% /home
/dev/mapper/raid-tmp  504M   17M  462M   4% /tmp
/dev/mapper/raid-usr  5.0G  3.2G  1.5G  69% /usr
/dev/mapper/raid-var 1008M  318M  639M  34% /var
stacheldraht@lucky-star:~$

[Feanaro]

ok ben er even mee bezig. Lijkt er dus op dat ik .. dingen moet doen:

* /home unmounten
* /home schrinken (FS)
* /home shrinken (LV)
* /home mounten

/ vergroten

Klopt dat zo? Ik heb alleen al een probleem bij stap 1:

umount: /home: device is busy
umount: /home: device is busy

[blokje1]

Boot in ieder geval in single user mode ;-). Voorkomt dat je overbodige processen hebt. Vervolgens kan je met fuser -m /home zien welke processen gebruik maken van je logical volume

code:

[root@palladium ~]# fuser -m /home 
/home:                   1r     1c     1e     2r     2c     3r     3c     4r     4c     5r     5c    16r    16c    17r    17c    34r    34c    35r    35c    36r    36c    37r    37c   183r   183c   416r   416c   429r   429c   430r   430c   445r   445c  1115r  1115c  1744r  1744c  1744e  1910r  1910c  1914r  1914c  2554  2554r  2554c  2554e  2558r  2558c  2558e  2610r  2610c  2645r  2645c  2645e  2764r  2764c  2764e  2781r  2781c  2781e  2916  2916r  2916c  2916e  2925  2925r  2925c  2925e  2935r  2935c  2935e  2954  2954r  2954c  2954e  2989r  2989c  2989e  3015  3015r  3015c  3015e  3053r  3053c  3053e  3054r  3054c  3054e  3055r  3055c  3055e  3056r  3056c  3056e  3057r  3057c  3057e  3058r  3058c  3058e  5446r  5446c  5446e  5461r  5461c  5461e  5462r  5462c  5462e  5492r  5492c  5492e  5493r  5493c  5493e  5529r  5529e  9009  9009r  9009c  9009e 16929 16929r 16929c 16929e 16956 16956r 16956c 16956e 18900 18900r 18900c 18900e 18931 18931r 18931c 18931e 18937 18937r 18937c 18937e 18954 18954r 18954c 18954e 19171r 19171c 19171e 19173 19173r 19173c 19173e 19175r 19175c 19175e 28494 28494r 28494c 28494e 28527 28527r 28527c 28527e

Besides that. zorg wel even voor een backup van /home, ik heb vaker dan eens met zelfde geintjes meegemaakt dat data toch verloren kan gaan ;-)


Een login in je X omgeving als normale user gebeurd onder andere vanaf /home, processen hierin locken zich in je home dir als PWD (Process Working Dir). dus kan je /home niet unmounten

[ Voor 5% gewijzigd door blokje1 op 03-07-2009 11:17 . Reden: verklaring waarom /home in gebruik kan zijn ]

[Feanaro]

Aangezien het hier om een server systeem gaat waar ik vanaf hier niet direct bij kan, kan het dus niet. Nou, dan moet ik er maar een toetsenbord en scherm aanhangen en er direct voor gaan zitten...

Heb trouwens geen idee hoe ik bijna 800 GB moet back-uppen..

[ Voor 14% gewijzigd door Feanaro op 03-07-2009 12:05 ]

[blokje1]

Feanaro schreef op vrijdag 03 juli 2009 @ 11:45:
Aangezien het hier om een server systeem gaat waar ik vanaf hier niet direct bij kan, kan het dus niet. Nou, dan moet ik er maar een toetsenbord en scherm aanhangen en er direct voor gaan zitten...

Heb trouwens geen idee hoe ik bijna 800 GB moet back-uppen..

Inloggen als root via ssh
Zorgen dat er geen andere users ingelogged zijn
Alle onnodige services uitzetten (Samba, NFS, netatalk, apache, ftp servers, bittorrent daemons, usenet applicaties)
dan kijken met fuser -m /home welke processen nog gebruik maken van de LV, deze processen afschieten :-)

umount /home
resize FS
resize LVM

lvextend /dev/mapper/volgroup00-lvroot (of hoe hij ook mag heten)
resize2fs /dev/mapper/volgroup00-lvroot (dit resized on the fly)

df -h checken

reboot and cross your fingers :-)

Artikel wat alles uitlegt: http://www.netadmintools.com/art367.html

[ Voor 3% gewijzigd door blokje1 op 03-07-2009 13:45 ]

[Verwijderd]

blokje1 schreef op vrijdag 03 juli 2009 @ 11:15:
Boot in ieder geval in single user mode ;-). Voorkomt dat je overbodige processen hebt.

Wat is dit nu weer voor onzin Met LVM en elk modern filesystem (ext3,ext4,xfs enz enz) kan je gewoon online resizen.

[Bergen]

Verwijderd schreef op vrijdag 03 juli 2009 @ 08:29:
[...]


Een paar GB voor / is volkomen waanzin, 512MB voor / is meer dan genoeg.

Voor jou misschien, maar voor veel gebruikers niet. Vooral als je development packages gaat installeren als je zelf zaken moet compileren (of 'zelfs' kernel sources) is die 512 MB snel vol. Meer dan 512 MB "volkomen waanzin" noemen slaat dus ook nergens op.

Onderstaand is mijn inhoud van / op mijn Ubuntu Hardy server:

# du -hx --max-depth=1
4.0M    ./bin
0       ./proc
4.0K    ./storage
0       ./dev
4.0K    ./opt
4.0K    ./initrd
158M    ./lib
0       ./sys
6.1M    ./sbin
440M    ./usr
4.0K    ./var
156K    ./tmp
4.0K    ./mnt
36M     ./boot
4.0K    ./home
8.5M    ./etc
104K    ./root
4.0K    ./srv
12K     ./media
16K     ./lost+found
652M    .

En als je je afvraagt wat er dan zorgt voor 440 MB in /usr:

/usr# du -hx --max-depth=1
99M     ./bin
4.0K    ./src
20K     ./games
1.7M    ./local
179M    ./share
13M     ./include
116M    ./lib
32M     ./sbin
96K     ./lib64
440M    .

En deze server is niets speciaals. Een hele standaard x86 pc met dhcp/dns/http/file/mail etc. Er staan maar 2 verschillende kernels op (en dus libraries in /lib) op en er is niet eens een gui geinstalleerd. Stel dat ik ook nog Gnome zou installeren met toeters en bellen en bijvoorbeeld kernelsources in /usr/src zou willen zetten, dan heb ik denk ik niet genoeg aan 1 GB. Vandaar mijn opmerking dat meerdere gigabytes geen overbodige luxe zijn. En die ene GB maakt op een harde schijf van bijvoorbeeld 1 TB (of meer) ook niet veel uit toch? Of je /home nou 975 of 974 GB krijgt toegewezen... ach...

[Verwijderd]

Bergen schreef op zaterdag 04 juli 2009 @ 01:20:
[...]
Meer dan 512 MB "volkomen waanzin" noemen slaat dus ook nergens op.

Als je niet goed leest of er niets van begrijpt dan slaat dit antwoord ook nergens op Een standaard en gangbare partitie indeling voor een server is over het algemeen dit:

/
/home
/tmp
/usr
/var
/srv

(eventueel /var/log, /opt /usr/local enzovoort enzovoort)

Als dan 512MB voor je / niet voldoende is dan ben je echt verkeerd bezig

Hier nog een voorbeeldje van een dikke Debian file/shell server. Hier is / zelfs de helft van 512MB

code:

stacheldraht@happy-star:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             228M   94M  123M  44% /
tmpfs                 502M     0  502M   0% /lib/init/rw
udev                   10M   88K   10M   1% /dev
tmpfs                 502M     0  502M   0% /dev/shm
/dev/mapper/homeserver-home
                      130G  105G   18G  86% /home
/dev/mapper/homeserver-tmp
                      938M   18M  873M   2% /tmp
/dev/mapper/homeserver-usr
                      938M  351M  540M  40% /usr
/dev/mapper/homeserver-var
                      938M  413M  478M  47% /var
/dev/md0              463G  355G  104G  78% /srv/raid
stacheldracht@happy-star:~$

[ Voor 43% gewijzigd door Verwijderd op 04-07-2009 02:45 ]

[moto-moi]

ik ben echt al jaaaaaren van het stomzinnige 'overal een partitie van maken', bij mij lopen op alle servers toch standaard /var vol, op desktops /home, dus ik heb liever gewoon 1 grote partitie waar ik alles op kan mounten. Ander verhaal wordt het bij servers die bijv. een interne en externe array hebben, maar daarbij boeit het toch niet hoe groot de interne array is, alleen maar dat ik ervan kan booten, en de externe array mounten we op bijv. /mnt/data

[Bergen]

Tja, de meningen over wat "standaard" is lopen wat dat betreft misschien wat uiteen.

/home op een aparte partitie zetten vind ik vanzelfsprekend, dat zou iedereen moeten doen. (Al is het maar voor het gemak bij een eventuele herinstallatie.)

/var op een aparte partitie vind ik ook logisch, zodat je systeem nog goed blijft werken in het geval dat /var/log vol loopt.

Maar het nut van /tmp en /usr op een aparte partitie zetten ontgaat me. In /tmp staat doorgaans maar heel weinig data en /usr verandert alleen bij installatie van nieuwe software. Waarom moeten /usr en / los van elkaar staan? Om systeemsoftware en usersoftware gescheiden te houden? Waarom? Ik vind het standaard om die gewoon bij / op de partitie te zetten.

Hoe dan ook, dit geeft wel aan dat je de vraag "Hoe groot moet de rootpartitie zijn?" niet moet beantwoorden met een aantal GB maar met de vraag: "Hoe ziet je partitie-indeling eruit?"

[ Voor 18% gewijzigd door Bergen op 04-07-2009 14:02 ]

[Rainmaker]

Verwijderd schreef op vrijdag 03 juli 2009 @ 16:50:
[...]


Wat is dit nu weer voor onzin Met LVM en elk modern filesystem (ext3,ext4,xfs enz enz) kan je gewoon online resizen.

Unmounten is ook zooo 2005

Gewoon lvresize gebruiken terwijl het ding gemount staat en van mijn part nog in gebruik is. Wel even zorgen dat je nog genoeg ruimte in je VG hebt.

Dan FS vergroten en klaar.

Wat me trouwens ook opvalt in vrijwel alle bovenstaande posts: waarom alle subs onder / in LVM gooien, maar / zelf niet? Zoveel moeite is het toch niet om tijdens de instalatie ook een lvRoot (oid) aan te maken? Mocht die 256MB dan toch niet genoeg zijn, kun je m alsnog vergroten.

[ Voor 23% gewijzigd door Rainmaker op 07-07-2009 01:18 ]

[Verwijderd]

moto-moi schreef op zaterdag 04 juli 2009 @ 09:24:
ik ben echt al jaaaaaren van het stomzinnige 'overal een partitie van maken', bij mij lopen op alle servers toch standaard /var vol, op desktops /home, dus ik heb liever gewoon 1 grote partitie waar ik alles op kan mounten.

Het leuke van overal een partitie van maken is dat je veel beter je spul kunt beveiligen. Het ligt alleen aan de situatie. Ik vind het wel prettig om partities noexec te kunnen mounten, of met usrquota,grpquota, of met acl, of met nodev,nosuid,noexec. En ga zo maar door. Ik zie /home als home partitie van afzonderlijke gebruikers, en /srv als datapartitie voor services. Er is wat voor te zeggen om die allemaal met andere flags te willen mounten.

Rainmaker schreef op dinsdag 07 juli 2009 @ 01:15:
Wat me trouwens ook opvalt in vrijwel alle bovenstaande posts: waarom alle subs onder / in LVM gooien, maar / zelf niet? Zoveel moeite is het toch niet om tijdens de instalatie ook een lvRoot (oid) aan te maken? Mocht die 256MB dan toch niet genoeg zijn, kun je m alsnog vergroten.

Als je / te klein wordt, heb je gewoon niet nagedacht over je partitie-indeling. Dat is ofwel onervarenheid, ofwel incompetentie of nalatig.

[Feanaro]

Huh? Hoef ik niet te unmounten? Dat zou de boel wel een stukje handiger maken...

Wat betreft de grootte van /, ik denk dat dat in mijn geval onervarenheid geweest kan zijn. Ik heb gewoon gedaan wat het debian installatieprogramma me destijds aanried en dat was kennelijk 512. Ik heb later wel een x64 versie er overheen geïnstalleerd, dat neemt meer ruimte in misschien dan de x86-versie? Ik heb geen idee. In elk geval is een grotere / en /var denk ik geen overbodige luxe gebleken.

Weet iemand iets om te backuppen trouwens? Ik heb al wel eens gewoon data gekopieerd, maar dan gaan alle rechten en owners heel erg in de war, niet zo praktisch.

Is het trouwens normaal om je www-data (websites etc) in /var te zetten? Volgens mij is het standaard en ik zie hier dat het in mijn geval 2 van de bijna 3 GB in beslag neemt...

[ Voor 12% gewijzigd door Feanaro op 07-07-2009 13:47 ]

[moto-moi]

Verwijderd schreef op dinsdag 07 juli 2009 @ 08:22:
[...]

Het leuke van overal een partitie van maken is dat je veel beter je spul kunt beveiligen. Het ligt alleen aan de situatie. Ik vind het wel prettig om partities noexec te kunnen mounten, of met usrquota,grpquota, of met acl, of met nodev,nosuid,noexec. En ga zo maar door. Ik zie /home als home partitie van afzonderlijke gebruikers, en /srv als datapartitie voor services. Er is wat voor te zeggen om die allemaal met andere flags te willen mounten.

Tsja, dan heb je het over multiuser systemen, ik gebruik linux alleen als desktop en server voor mensen die ik vertrouw waarbij dat soort dingen gewoon niet nodig zijn omdat ik mijn collega's vertrouw

Als je / te klein wordt, heb je gewoon niet nagedacht over je partitie-indeling. Dat is ofwel onervarenheid, ofwel incompetentie of nalatig.

mwah, ik wil mijzelf, kees en ACM toch niet als incompetent afschilderen hoor Wij vinden het gewoon de tijd niet waard om er überhaupt over na te denken als je het simpelweg kan voorkomen door gewoon alles op 1 hoop te gooien.

[Feanaro]

schopje?

[Feanaro]

resize2fs /dev/bavaria/home 900G
resize2fs 1.41.3 (12-Oct-2008)
Filesystem at /dev/bavaria/home is mounted on /home; on-line resizing required
On-line shrinking from 241618944 to 235929600 not supported.

En nu?

[ Voor 200% gewijzigd door Feanaro op 30-08-2009 20:03 ]

[Verwijderd]

Unmounten en daarna resizen.

[Feanaro]

Heb nu alle processen die hem gebruiken met fuser bekeken en afgeschoten, zoals een eerdere reactie al zei. Nu werd ik er via SSH uitgeknikkerd, maar ben met root weer ingelogd. Nu zegt fuser -m /home helemaal niets. Maar als ik /home probeer te unmounten dan zegt ie dat ie "busy" is... Kan dus nog niet unmounten...

[Verwijderd]

Ben je als root ingelogd, of ben je als user ingelogd en daarna root geworden?
Je kunt met lsof zoeken naar processen die iets met /home doen, en als je daar niet uit komt kun je altijd rebooten, inloggen als root (desnoods single-user mode) en dan de partitie unmounten en resizen.

[Feanaro]

Nee, zit via SSH, ben direct als root, niet via su.

Heb geen directe toegang, vandaar.

[ Voor 27% gewijzigd door Feanaro op 30-08-2009 20:21 ]

[Verwijderd]

Idd Online expanden kan wel, maar als je wilt shrinken moet je eerst unmounten. Zie ook de manpage van resize2fs:

code:

The resize2fs program will resize ext2 or ext3 file systems.  It can be
       used  to  enlarge or shrink an unmounted file system located on device.
       If the filesystem is mounted, it can be used to expand the size of  the
       mounted filesystem, assuming the kernel supports on-line resizing.  (As
       of this writing, the Linux  2.6  kernel  supports  on-line  resize  for
       filesystems mounted using ext3 only.

[Feanaro]

Nou ja, dan moet het toch kunnen? Ik heb een 2.6 kernel en ext3...

Hoe kan ik met lsof zoeken naar processen die iets met filesysteem doen?
Er staat een optie "+f" bij, maar die geeft steeds een foutmelding als ik die gebruik.

Umounten is EINDELIJK gelukt!

[ Voor 6% gewijzigd door Feanaro op 30-08-2009 20:26 ]

[Feanaro]

bavaria:~# resize2fs /dev/bavaria/home 900G
resize2fs 1.41.3 (12-Oct-2008)
Please run 'e2fsck -f /dev/bavaria/home' first.

bavaria:~# e2fsck -f /dev/bavaria/home
e2fsck 1.41.3 (12-Oct-2008)
The filesystem size (according to the superblock) is 241618944 blocks
The physical size of the device is 235929600 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no

Pass 1: Checking inodes, blocks, and sizes

Kan het zijn dat dit lang duurt? (900 GB)

[Verwijderd]

Ja dat kan heel lang duren.

[Feanaro]

O ok. Vreemde foutmelding wel. Kan dat zijn omdat ik de LV al verkleind had?

[Verwijderd]

Omg......... je had eerst je filesystem moeten shrinken en daarna pas je LV of partitie.

code:

If  you wish to shrink an ext2 partition, first use resize2fs to shrink
       the size of filesystem.  Then you may use fdisk(8) to shrink  the  size
       of  the partition.  When shrinking the size of the partition, make sure
       you do not make it smaller than the new size of the ext2 filesystem!

[Feanaro]

hmm... dat deden ze ook in de tutorial die er stond... is het erg?

en als het wel erg is.. wat kan ik eraan doen?

[ Voor 26% gewijzigd door Feanaro op 30-08-2009 20:51 ]

[gertvdijk]

Feanaro schreef op zondag 30 augustus 2009 @ 20:50:
hmm... dat deden ze ook in de tutorial die er stond... is het erg?

Niet elke tutorial is heilig. Houd wel je verstand erbij en lees manuals in plaats van klakkeloos commando's overtypen.

Feanaro schreef op zondag 30 augustus 2009 @ 20:50:
en als het wel erg is.. wat kan ik eraan doen?

Datarecovery...

[Verwijderd]

Feanaro jij bedoelt deze tutorial toch?

http://www.netadmintools.com/art367.html

Daarin wordt toch duidelijk eerst het filesystem kleiner gemaakt en dan de LV

[Feanaro]

Ja, het was toch een beetje onduidelijk allemaal. Als het goed is, heb ik nu alles weer gefixt en de partities zijn vergroot .