Yum update mi blocca il notebook

trpost dice:
dopo Bios premi ESC

Gia fatto piu’ volte. Nessuna risposta

[code]# cat /boot/grub/grub.conf

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/sda2

initrd /initrd-[generic-]version.img

#boot=/dev/sda
default=0
timeout=0
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.40.3-0.fc15.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.40.3-0.fc15.x86_64 ro root=UUID=05cf024c-e0b7-49a5-82c0-66134a59e877 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=it_IT.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=it rhgb quiet
initrd /initramfs-2.6.40.3-0.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=UUID=05cf024c-e0b7-49a5-82c0-66134a59e877 rd_NO_LUKS rd_NO_LVM rd_NO_MD 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]

Con la live, il timeout cambialo da 0 a 5 (secondi) così da avere tempo.

Fatto, nessuna uscita, le sequenze di tempi anzidette al reboot non cambiano, dopo bios va subito in blocco, tasto esc ed ‘e’ ininfluenti

Subito in blocco ?
Non inizia nemmeno il boot ?

esatto, cosi’ sembrerebbe.
Dopo logo Dell della fase bios, appare una sequenza di posizionamento di un trattino che salta su 3 posizioni e si fissa in alto a sinistra. Cio’ avviene in ca 1 secondo.

Reinstalla Grub nell’MBR e verifica dove sono memorizzati i kernel usando la live.

Con DVD Fedora 15 (non la Live ma il DVD di installazione) sono entrato in modalita’ Rescue e poi nella shell rescue.
(ho seguito le indicazione della ns guida su FOL).
dopo aver controllato da device.map che il device di boot e’ /dev/sda ho lanciato vari comandi :

grub-install /dev/sda
grub-install /dev/sda1
grub-install --recheck /dev/sda
grub-install --recheck /dev/sda1

a tutti risponde ‘Could not find device for’

allora ho lanciato
#grub
Che testa tutti i device del Bios : risultato non ne appare nessuno…ne’ alcuna lista

Secondo me si e’ corrotto qualcosa all’avvio.

Provo a reinstallare le immagini e in caso di ulteriore insuccesso faro’ tesoro dei suggerimenti di troubleshooting che mi avete dato nei post della discussione.

Thanks per il momento e faccio sapere evoluzione futura appena possibile
Ciao
peppe@dell11

Eccoci qua di nuovo.
Riporto le ultime novita’ sul mio problema (ricordando che il problema era che -dopo una installazione ‘fresca’ di F15- con yum update il sistema si blocca al reboot).
Dopo varie prove ho una situazione di pacchetti tutti aggiornati ma con un sistema che va solo con il kernel …38 mentre con il kernel …40 il blocco al reboot si ripete.
In altri temini:
-effettuo lo yum update con il kernel …38
-nel grub.conf ci sono 2 kernels il …40 e il …38.
-modifico nel grub la direttiva default= 0/1 come appropriato
-se riparto con il …40 -> blocco al boot
-se riparto con il …38 ->il sistema va.

L’unico elemento correlato al blocco e’ un messaggio che si evidenzia durante il boot con kernel …40 (attivando la schermata di log con tasto ESC quando appare il logo Fedora). Questo messaggio dice (riportato da foto del monitor):
“Starting udev Wait for Complete Device Initialization failed, see ‘systemctl status udev-settle.service’ for details.”
e da qui il blocco inizia e il boot non va piu’ avanti.

Ripeto che se invece parto con il kernel …38 tutto procede (anche se un po’ a rilento) e al termine ho il sistema attivo (con tutti pacchetti dichiarati aggiornati).

possiamo vedere un :

$ lsusb

con una tua descrizione delle periferiche ?

In questo momento ho solo connesso un mouse usb a filo e un collegamento di rete con modem alice adsl.
Il pc e’ un notebook dell Ispiron 15.
Avevo provato i reboots anche con tutto scollegato (cioe’ senza mouse esterno) ma senza beneficio

[peppe@dell11 ~]$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 006: ID 0a5c:21bc Broadcom Corp. 
Bus 001 Device 004: ID 0bda:0138 Realtek Semiconductor Corp. 
Bus 001 Device 005: ID 0bda:58c0 Realtek Semiconductor Corp. 
Bus 002 Device 007: ID 046d:c05f Logitech, Inc. 
[peppe@dell11 ~]$ 

sembra un problema di corretto rilevamento dell’hardware.

cosa dice ?:

# systemctl status udev-settle.service

prova a tenere la wireless e/o il bluethoot disattivato all’avvio.

se non da risultati prova a mattere un:

acpi=off

sulla linea del kernel incriminato in grub.conf

Ecco l’uscita del comando.
Questa pero’ e’ la situazione del kernel che funziona.
Adesso provo le altre cose che dici.

[root@dell11 peppe]# systemctl status udev-settle.service
udev-settle.service - udev Wait for Complete Device Initialization
	  Loaded: loaded (/lib/systemd/system/udev-settle.service)
	  Active: active (exited) since Mon, 05 Sep 2011 08:57:43 +0200; 8h ago
	Main PID: 507 (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/udev-settle.service
[root@dell11 peppe]# 

Con Bluetooth.service disabled al reboot: niente da fare.
(Il wireless non so come fare a disabilitarlo ma il led e’ spento)

Provato a inserire sulla riga del kernel apci=off -> niente da fare e appare sempre la scritta udev-settle failed.

Salve, ritorno con il problema irrisolto.
Dopo aver fatto oggi lo yum update mi ritrovo tutti i pacchetti aggiornati ma con il nuovo kernel si blocca al reboot
e da’ udev-settle failed (vedi post sopra).

Allego il grub.conf che funziona bene solo se imposto il default=2.
Per il resto con il kernel …38 tutto sembra funzionare.


[root@dell11 peppe]# cat /boot/grub/grub.conf 
# 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/sda2
#          initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=2
timeout=5
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=UUID=05cf024c-e0b7-49a5-82c0-66134a59e877 rd_NO_LUKS rd_NO_LVM rd_NO_MD 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.40.3-0.fc15.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.40.3-0.fc15.x86_64 ro root=UUID=05cf024c-e0b7-49a5-82c0-66134a59e877 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=it_IT.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=it rhgb quiet
	initrd /initramfs-2.6.40.3-0.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=UUID=05cf024c-e0b7-49a5-82c0-66134a59e877 rd_NO_LUKS rd_NO_LVM rd_NO_MD 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
[root@dell11 peppe]# 

ci fai vedere un:

$ rpm -qa|grep kmod $ rpm qa|grep kernel

kmod non ce ne sono

[peppe@dell11 ~]$ rpm -qa |grep kmod
[peppe@dell11 ~]$ 
[peppe@dell11 ~]$ rpm -qa |grep kernel
kernel-2.6.40.3-0.fc15.x86_64
kernel-2.6.40.4-5.fc15.x86_64
kernel-2.6.38.6-26.rc1.fc15.x86_64
abrt-addon-kerneloops-2.0.3-1.fc15.x86_64
[peppe@dell11 ~]$ 

sembra proprio un problema di dispositivo hardware mal riconosciuto dal kernel 2.6.40

Ultime notizie:
ho provato (agendo con il kernel 38) a disabilitare udev-settle.service con un comando trovato su un interessante sito per Amministratori Linux-f15.
Il comando di disabilitazione e’:
#ln -s /dev/null /etc/systemd/system/udev-settle.service

Lanciato questo comando, al reboot ho forzato (tasto ‘e’)
il kernel 40. Questo e’ ripartito e mi ha fatto entrare nel login grafico (finalmente).
Nota bene: ora pero’ il mouse usb non viene piu’ riconosciuto!
Era forse lui (il mouse usb) a dare la failure hw?

il link simbolico modifica il sistema, consiglio la sua cancellazione.
preferibile la disattivazione di udev-settle.service da systemd

non usare quel mouse.
vedi come si comporta.

Si, avevo gia’ cancellato il link simbolico (mi serviva per debug del problema, che a questo punto appare di conflitto kernel_40-hw).

Ancora due domande:

  1. per disattivare il service lancio:

systemctl disable udev-settle.service ?

  1. se si, e’ indifferente lanciarlo da kernel attivo 38 o 40?