Réussir sa mise à jour Edgy>Feisty - ou charger Feisty Fawn en moins de 15min

Système d'exploitation Linux
1

Des gens ont fait la mise à jour Edgy > Feisty?

Perso j’ai essayé, alors ça commence par 845 Mo de MaJ à 90-250 ko/s, vaut mieux pas être pressé :smiley: ensuite environ trente minutes de dépaquetages/installations/configurations j’arrive à un truc genre “initramp linux kernel 2.6.17” (celui d’Edgy) et là c’est le drame : la fenêtre disparaît dans une autre dimension, pouf! J’attends quelques instants mais rien à faire l’update-manager a planté comme une merde :’(. Évidemment kernel panic au redémarrage :grrr: …

Je décide de formater / et de tout réinstaller depuis le live-cd. Alors que Breezy Badger (5.10) détectait correctement ma résolution, 12801024@60Hz, aucune des versions suivantes n’est foutue de régler ça correctement. Après le 1024768@60Hz de Dapper et Edgy j’ai eu droit à du 1024*768@85Hz donc un bel écran Out of Range au démarrage. Ctrl+Alt+F1, sudo nano /etc/X11/xorg.conf je corrige le taux de rafraichissement, j’utilise le Gestionnaire de pilotes propriétaires pour installer nvidia-glx après un redémarrage il me modifie correctement nv > nvidia dans xorg.conf mais après un détour dans le menu Résolution je vois que je suis passé en 50Hz :confused: alors j’essaie de retoucher xorg.conf à la mano, nvidia-settings, sudo dpkg-reconfigure xserver-xorg, rien n’y fait il est impossible de sélectionner 60Hz. Après ça je vois sur un forum que c’est un problème du driver nvidia et qu’en fait le taux de rafraichissement est bien à 60Hz (vérfier par le menu OSD de l’écran).

Ensuite je décide de réinstaller quelques programmes comme Liferea et d’autres qui s’installent mals, pas d’icône dans la barre d’application, plantage constant de certains apps, amaroK a disparu donc obligé d’utiliser Medibuntu pour le trouver, j’espère qu’il n’y aura pas de conflits à l’avenir…

Mais le pire de tout c’est certainement cette étrange lenteur au démarrage : après avoir choisi Ubuntu dans GRUB il y a le boot screen Ubuntu avec la barre Loading qui reste 5 à 10 minutes bloqué sur la toute première phase de chargement. Si quoi elle bloque? J’aimerais bien le savoir parce que pendant ce temps l’ordinateur ne fait absolument rien, il attend tranquille avant d’enfin se décider à charger.
D’ailleurs pourquoi ne voit-on plus quelles sont les actions effectuées par le système depuis Dapper Drake? Au moins avec Breezy Badger je voyais ce qui posait problème :
http://www.zdnet.com.au/shared/images/news/ubuntu/bootscreen.gif

Donc mon principal problème serait de savoir pourquoi il faut 5/10 min avant que le système se mette à commencer à booter?

Je ne sais pas si le problème pourrait avoir un rapport avec mon fstab :

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=65a438f1-abd1-423f-9853-1b4bc2a5a088 /               ext3    defaults,errors=remount-ro 0       1
# /dev/sda2
UUID=798cecde-bc6c-4c2e-a7e4-1787a4e534c6 /home           ext3    defaults        0       2
# /dev/sdb1
UUID=8e0cef13-1b71-4e4e-9188-bb73cfcc8573 /home/heinrichi/Hitachi320GB ext3    defaults        0       2
# /dev/hdb1
UUID=c895fd6f-7409-4ed7-89b6-80fba624319c /home/heinrichi/IBM40Gio ext3    defaults        0       2
# /dev/hda1
UUID=CCDC4C0ADC4BECF0 /media/hda1     ntfs    defaults,nls=utf8,umask=007,gid=46 0       1
# /dev/hda5
UUID=1C605C85605C6792 /media/hda5     ntfs    defaults,nls=utf8,umask=007,gid=46 0       1
# /dev/sda3
UUID=1ab00f74-84c3-479a-be06-1ec236017220 none            swap    sw              0       0
/dev/hdd        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/hdc        /media/cdrom1   udf,iso9660 user,noauto     0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto  0       0
2

Moi, j’ai mis à jour son nunux aujourd’hui… J’ai trop galéré. :confused:

J’ai commencé par changer les canaux pour les mises à jour… Résultat, tout plantait, pas moyen de mettre à jour cette sale bête ! :grrr:

J’ai trifouillé dans les canaux et ça a fini par passer ! Mais bon, dans mes souvenirs, la dernière mise à jour était plus facile que ça ! :paf:

Valinor4

3

gksudo "update-manager -u -d" de mémoire.
Il désactive les dépôts tiers et fait tout tout seul. Si tu as utilisé une autre méthode que cette seule commande, tu as mal fait. Si tu as fait ça et que ça a merdé, rapporte le bug :paf:

4

je sais pas comment vous vous y prennez, mais je tourne depuis plus d’1 an sur la même install qui est passée de breezy à dapper et maintenant feisty sans l’ombre d’un problème

5

Je suis passé de Dapper, qui était la plus merdique et proche de WinMe des distribs linux que j’ai essayé et j’en essayé un bon paquet, à Edgy sans le moindre problème et pourtant j’ai eu le droit à une bonne vingtaine de questions dans un anglais technique totalement indigeste mais vu que je pouvais toujours me connecter avec Epiphany j’ai finis par surmonter l’interrogatoire après 8 heures de téléchargement/installation (!!!). Du coup quand l’update-manager m’a demandé de rebooter et que ça a fonctionné j’étais assez fier de moi je l’avoue :D.

Moi, qui ne connait pas grand chose du monde Unix j’avais réussi à vaincre ces monstres de Xorg, de fstab, du détestable nvidia-glx, des RAID controllers (merci les forums et les wikis).

Mais cette fois à part un “Please configure mdadm” auquel je n’ai pas la réponse je ne vois pas en quoi je suis responsable du crash vu qu’il n’y avait pas de questions.
J’ai vérifier que je possédais bien la version 0.45.2 d’update-manager, j’ai cliqué sur upgrade après avoir quitter tous les programmes lancés et j’ai attendu. La fenêtre update-manager a disparue toute seule je n’ai pas touché au clavier pendant toute l’opération. Après cinq minutes sans d’attente sans activité du CPU ou du HDD j’ai tenté de rebooter.

D’ailleurs en parcourant le launchpad j’ai vu que je n’étais pas le seul à avoir ce problème, certains avec l’environnement XCFE d’autres avec une version x86_64, moi j’ai eu ça avec une version x86 et GNOME… Apparemment certains ont attendus plusieurs (dizaines?) de minutes et l’installation s’est finalement déroulée correctement avec la demande de rédémarrage.
Je précise qu’à part Medibuntu pour les w32codecs ainsi que les ffmeg je n’installe aucun dépôts ou logiciels non disponibles dans les dépôts Ubuntu officiels.

6

Personnellement je trouve que c’est la meilleur…

7

oupss, dapper -> edgy -> feisty, pardon

8

J’ai changé les mirroirs pour utiliser ceux de pays moins surcharger et à part quelque erreur 404 dues au mirroring incomplet, tout c’est passé dans la joie et la bonne humeur :o
Il y a juste le premier reboot que j’ai eu l’erreur de faire sur un autre pc (avec une GF2) qui m’a obligé à reinstaller les drivers nvidia, et comme j’avais qu’un GF2, j’ai d reinstaller les -legacy, donc pas de GLX_EXT_tfp :o
Mais ca sera corrigé ce soir avec ma GF6 :smiley:

Ah si en fait, j’ai tout ce qui touche à la video et 3D (mplayer, wine, glx, beryl etc…) qui segfault, mais là encore, je soupconne le couple CG/driver

9

+1 pour les process chargé c est pas visible avec upstart ?

10

pax connaitre je reste avec l’usplash standard, si une action prends plus de temps que la normale il repasse automatiquement en mode verbeux

11

Bon j’ai retiré splash de GRUB et le truc qui prend dix minutes avant de commencer la séquence de boot c’est une suite d’environ cinq :

avec à chaque fois une nouvelle ligne waiting for suivi de failed to… Les chiffres de départ changent à chaque fois. Ensuite tout le reste charge très rapidement et j’arrive sur l’écran de login en quelques secondes.

Je ne vois pas d’où vient ce problème d’ata2.00. Pour info j’utilise deux HDD Hitachi en SATA.

12

Perso, j’ai tenté feisty ce week end…
Une fresh install qui plus est…
Resultat : des freeze de 30 secondes des qu’on click dans un menu ou qu’on lance une appli, génial. :heink:
j’ai reinstaller une deuxieme fois, idem…
j’ai regarder vite fais sur le net, j’ai rien vu a ce sujet.
du coup j’ai mis une debian stable, au moins ça a marcher du premier coup :neutre:
je sais pas si je suis tomber sur un cas exceptionnel, toujours est-il que j’ai été bien déçu par cette ubuntu, moi qui avait mis dapper drake sur pas mal de pc sans aucun soucis.

13

Quelques personnes ont apparemment le même problème que moi et notre point commun c’est qu’on a tous un graveur CDRW Lite-On IDE et il semblerait qu’il soit détecté comme un HDD SATA :/. Si on désactive ce graveur le démarrage ne bloque plus. Assez bancal comme méthode.

Apparemment il faut passer sur un kernel plus ancien ou ajouter irqpoll dans GRUB.

14

Quelqu’un a trouver un autre solution sur le forum officiel d’Ubuntu : ouvrir et refermer le tiroir du graveur Lite-On.
Le pire c’est que ça fonctionne ! C’est super pro comme fix :MDR .

15

Juste pour dire que à mon niveau j’ai jamais eu de bleme pourtant j ai une ati avec du sata depuis la dapper c’est du bonheur.

Maintenant le probleme de detection des ecrans je l ai eu aussi
j avais mis sur ma prise vga donc j ai mis sur ma prise dvi

Ho miracle ca fonctionne nickel.

Et pour le sata j’ai tout editer en uuid avec un cd knoppix.

voila mon retour.

16

Ce problème de démarrage ne semble se produire qu’avec certaines combinaisons de controllers SATA associés à des graveurs Lite-On.
Ceci-dit j’ai moi aussi un écran branché sur DVI et mes HDD sont montés par rapport à leur UUID.
Apparemment ceux qui avaient Feisty Alpha 5 n’avaient pas ce souci donc j’espère qu’un nouveau kernel résoudra le problème.

17

Juste un petit up pour dire que le kernel n’a toujours pas été mis à jour malgré les nombreux bugreports envoyés sur le launchpad (par ex). Pourtant on sait qu’elle est notre point commun à tous : les graveurs Lite-On IDE.
2 semaines à ouvrir puis refermer la trappe ou encore désactiver la gestion du graveur dans le BIOS (disable IDE1 slave) chaque jours. :confused:

18

3 semaines et toujours aucune mise à jour du kernel. Là ce n’est plus de l’amateurisme mais de l’incompétence.
Remarquez ça ne change pas beaucoup des Xorg corrompus et des kernels pourris qui était sur les serveurs de MàJ de Dapper…

C’est bien de marquer tous les bugs comme Fix Released mais ça serait bien de les mettre à dispo des utilisateurs.

Une Final Release plus buggé que l’Alpha5 c’est une première.

19

La mise à jour tant attendue du kernel est arrivée [:woohoo] mais ne règle pas le problème des graveurs Lite-On :/.

20

il suffit juste de consulter dmesg pour avoir les infos… pas besoin de tripatouiller grub ou le bootsplash