Fa temps que havia observat el següent problema (discussió i solució en aquest fil):
En un equip amb una distribució “de treball” i altres “de prova”, el fet d’instal·lar-hi una nova distribució de prova alterava les UUID. Açò afectava a la de treball que, en tractar d’iniciar, no trobava les particions i fallava durant l’arrancada (les UUID que figuraven al /etc/fstab no coincidien amb les UUID reals que podia obtenir amb $ blkid).
Gràcies a les indicacions de Vicent Cubells, vaig
identificar l’arrel del problema i, corregint les UUID
del /etc/fstab , ho vaig poder solucionar.
Aquest problema s’ha tornat a presentar sempre que he instal·lat
una nova distribució de prova, però ja anava sobre avís.
Ahir vaig descobrir que el problema s’havia repetit en el portàtil, però afectava només a la partició swap: la distribució de treball no sabia muntar-la. Me’n vaig adonar en executar l’ordre $ free :
jordi@ubuntu-hp:~$ free total used free shared buffers cachedMem: 507584 498932 8652 0 8496 153076-/+ buffers/cache: 337360 170224Swap: 0 0 0jordi@ubuntu-hp:~$
A l’última línia, s’observa que no reconeixia la swap. Per si de cas, vaig executar la utilitat Conky i em va confirmar la sospita: la swap no apareixia per ninguna banda.
Amb açò, em vaig explicar les penjades de les últimes setmanes (en realitat, no es penjava: en esgotar la RAM, intentava escriure en una swap que no podia localitzar i es tornava carbassa, entrava en un cicle de lectura-escriptura del que no acabava de sortir mai i em tocava reiniciar amb l’esotèrica combinació Alt-ImpPant-REISUB).
D’altra banda, com que el sistema pot funcionar sense swap, no havia sabut interpretar els símptomes (en el cas que he explicat al principi, l’arrancada fallava: el problema era massa gros per no veure’l).
Després d’observar que la swap havia desaparegut, vaig recordar el que m’havia passat feia mesos, vaig comprovar l’estat de les UUID i vaig veure que, efectivament, la de la partició swap que apareixia al /etc/fstab no es corresponia amb la UUID real. Vaig corregir aquest valor, vaig reiniciar el sistema i, finalment, l’ordre $ free em tornava a mostrar la swap.
jordi@ubuntu-hp:~$ free total used free shared buffers cachedMem: 507584 500952 6632 0 19352 141788-/+ buffers/cache: 339812 167772Swap: 2088440 32516 2055924jordi@ubuntu-hp:~$
I Conky tornava a confirmar el diagnòstic: problema solucionat.
Reflexions
No recordo haver tingut aquests problemes quan treballava amb la Dapper. Si no m’equivoque, la primera volta que els vaig experimentar, treballava amb la Feisty. Em fa l’efecte que, a partir de la Feisty, l’assignació de les particions en el /etc/fstab es realitza mitjançant les indesxifrables UUID en lloc de amb les còmodes /dev/sda1 i similars.
No sé quina n’és la causa, però els problemes que he tingut semblen indicar que la realització d’una instal·lació altera les UUID de totes les particions (no sé si de tots els discos durs presents o si només les dels discos durs que participen en la nova instal·lació). O potser només canvien les UUID de les particions que la nova distribució podrà accedir (les que apareixeran en el seu /etc/fstab).
De moment, cada volta que faig una instal·lació de prova, he de recordar revisar com queden les UUID i corregir el /etc/fstab de la distribució de treball. La solució que em resultaria còmoda seria tornar a configurar el /etc/fstab amb les direccions “tradicionals” (tipus /des/sda1), però em va pel cap que també hauria de clavar mà en el menu.lst del GRUB, i potser alguna cosa més. D’altra banda, també recordo haver llegit no-sé-què sobre els avantatges de les UUID i els problemes de l’altre sistema. Continuaré investigant, perquè açò no és gens pràctic.
Powered by ScribeFire.
