non è che ci sia molta differenza.
Quello che mi interessa è riavere il pc funzionante perché anche rimettendo una FC15 nuova mi troverei sempre con il problema dei driver fino, almeno, alla FC16 e nemmeno subito direi.
Contavo che i driver per la 15 migliorassero sempre di più.
Allo stato attuale cosa mi consigli di fare?
non usare i driver proprietari.
Bene direi che per velocizzare il tutto rimetto una FC15 nuova e poi ripristino il backup ma senza usare gli ATI proprietari o i catalyst open non saprei come utilizzare il doppio monitor o l’accelerazione hardware.
Insomma non avrei mai il pc in ordine e performante…o sbaglio?
occorre aspettare i driver ati 11.9
Driver che dovrebbero essere prossimi tra le altre cose.
Comunque il sistema si sta “zappando” in questo momento e, vedrò cosa ottengo senza i driver per ATI.
Peccato perché volevo rifare un’installazione pulita con FC16 una volta che uscivano i driver corretti ma, evidentemente, la stabilità degli attuali era tutt’altro che scontata.
manda una e.mail di protesta alla ATI.
Nulla da fare:
ho piallato tutto con una nuova installazione di Fedora 15 e Gnome3 con i driver video standard ma, dopo l’aggiornamento al nuovo kernel, stesso problema.
Il problema sembra grave a questo punto.
sembra un problema hardware.
vuoi tentare una installazione di prova, staccando lo “staccabile” ovvero disattivare tutte le periferiche che non sono necessarie ?
Ho solo tastiera e mouse, oltre alla eternet.
Aggiungo che con il kernel della distro da DVD è rimasto acceso oltre un giorno, lavorandoci, senza dare problemi.
Ieri sera ho spento dopo aver fatto gli aggiornamenti e non presentava nemmeno il problema del mancato stop.
oggi riaccendendo sempre sh: can’t access tty
dischi ?
unità ottiche ?
Un DVD-RW e 4 dischi in RAID 10 gestiti dal controller della scheda madre.
Un disco esterno USB per il backup.
Ieri a computer funzionante e dopo aver fatto gli aggiornamenti ho fatto diverse volte la chiusura della sessione senza problemi.
Il riavvio, quindi immagino all’introduzione del nuovo kernel, si verifica il problema: importante dire che tornando al vecchio kernel il blocco succede uguale.
Sembra che lasci appeso un file di lock.
Mi servirebbe aiuto nel decifrare come seguire i passi del wiki.
Sembra che il problema sia conosciuto e anche di facile (nel senso che sono pochi comandi) rimedio.
Correggo quanto detto prima:
al momento con il kernel 2.6.38.6.26.rc1 il sistema si avvia normalmente.
questo fatto suggerisce una regressione kernel su qualche elemento hardware.
visto che la tua macchina appare una macchina di produzione.
usa questo kernel ed escludi l’aggiornamento del kernel per avere la massima stabilità.
allego il file fstab:
[code]
/etc/fstab
Created by anaconda on Tue Sep 13 22:36:30 2011
Accessible filesystems, by reference, are maintained under ‘/dev/disk’
See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
/dev/mapper/VolGroup-lv_root / ext4 defaults 1 1
UUID=bbeabc5b-7e91-4e4b-b2a8-4a0741f0b3f6 /boot ext4 defaults 1 2
UUID=70D6-1701 /boot/efi vfat umask=0077,shortname=winnt 0 0
/dev/mapper/VolGroup-lv_home /home ext4 defaults 1 2
/dev/mapper/VolGroup-lv_swap swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0[/code]
Questa la configurazione in /boot/grub/menu.lst per vedere le differenze:
[code]# grub.conf generated by anaconda
Note that you do not have to rerun grub after making changes to this file
NOTICE: You have a /boot partition. This means that
all kernel and initrd paths are relative to /boot/, eg.
root (hd0,0)
kernel /vmlinuz-version ro root=/dev/mapper/VolGroup-lv_root
initrd /initrd-[generic-]version.img
#boot=/dev/md127
default=0
timeout=0
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.40.4-5.fc15.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.40.4-5.fc15.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_MD_UUID=c41ba2d3:b70ac154:61d13ec7:17974165 rd_MD_UUID=397ac946:f28c3030:cfffa4e4:06998937 rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_DM LANG=it_IT.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=it rhgb quiet
initrd /initramfs-2.6.40.4-5.fc15.x86_64.img
title Fedora (2.6.38.6-26.rc1.fc15.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.38.6-26.rc1.fc15.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_MD_UUID=c41ba2d3:b70ac154:61d13ec7:17974165 rd_MD_UUID=397ac946:f28c3030:cfffa4e4:06998937 rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_DM LANG=it_IT.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=it rhgb quiet
initrd /initramfs-2.6.38.6-26.rc1.fc15.x86_64.img[/code]
Googolando sembra che il misfatto risieda in questi file.
Come rimuovo il kernel -40 senza fare danni?
Scusami la banalità.
lascialo stare, basta eseguire questa manovra:
# gedit /boot/grub/grub.conf
modifica la linea:
default=0
in:
default=1
salva chiudi.
partirà sempre con il kernel 2.6.38.6-26
Facendo così, visto che ho solo due Kernel in elenco di cui uno non funziona, volendo provare il prossimo aggiornamento rischio che se ha lo stesso problema della -40 mi ritrovo senza alternative?