Bloccato al riavvio e allo spegnimento

Di recente ho installato Ubuntu 12.04 e lo adoro. Tuttavia ho un problema: non riesco a chiudere o riavviare correttamente.

Quando spengo il mio laptop (Acer Aspire 5560), si blocca sui 5 punti e rimane lì.

Quando riavvio il mio laptop si spegne ma quando si avvia il backup rimane sullo schermo viola (nessun logo che mai)

Cosa, devo fermarlo:

• sudo service network-manager stop prima dell'arresto: niente

• Aggiungendo alcune righe al file GRUB - niente

• installato altre versioni di Ubuntu - niente
• sudo shutdown -h now - Niente

e un po 'di più.

Al momento vedo uno schermo nero davanti a me con il testo

 Asking all remaining processes to terminate [OK]

E i 5 punti con solo l'ultimo arancione.

In altri tentativi ho ottenuto questa cosa:

modem-manager:could not get the system bus......

Prima ho avuto Ubuntu con doppio avvio di Windows. E poi ha funzionato bene. Tuttavia dopo una nuova installazione di Ubuntu da solo ho capito.

Ho avuto un problema simile con un Dell XPS 15z che ho risolto aggiungendo acpi=noirqagli argomenti del kernel:

sudo vi /etc/default/grub

impostato

GRUB_CMDLINE_LINUX_DEFAULT="acpi=noirq quiet splash"

poi

sudo update-grub

Si noti che in precedenza avevo utilizzato acpi=off, che mi ha permesso di avviare, ma non l'arresto. Senza alcuna bandiera acpi, non sono stato in grado di avviare.

È possibile provare a questi comandi nel terminale

Per lo spegnimento:

sudo halt

Per lo spegnimento:

sudo init 0

Per il riavvio:

sudo init 6

Per lo spegnimento:

sudo shutdown -h now

Per ibernazione:

sudo /etc/acpi/hibernate.sh

Ho ricevuto un trucco da questo link: http://www.pbehnke.com/main/node/11 , per qualche motivo se i controlli USB sono impostati su auto, il ciclo di spegnimento-riavvio si avvia. La soluzione era di renderli con onforza.

Ho aggiunto una funzione nello /etc/init.d/haltscript in questo modo -

# Add this function in the /etc/init.d/halt script
# call before do_stop
set_usbs_on () {
    usbcontrolpath="/sys/bus/usb/devices/*/power/control"
    for dev in $usbcontrolpath;
    do
        echo "Setting $dev: " `cat $dev` "to on"
        echo on > $dev
        echo ""
    done
}

e lo chiamo prima do_stopin case $1 stopswitch -

stop)
    set_usbs_on
    do_stop
    ;;

Ora la macchina si spegne.

L'unica cosa che dovevo fare era premere Ctrl+ Alt+ Tper aprire il terminale. Quando si apre, esegui il comando seguente

sudo update-grub

e ora funziona benissimo.

Stesso problema con blocchi spuri "sui 5 punti". Ho letto da qualche parte (non ricordo dove) per prima "Logout" (menu in alto a destra) e poi lo spegnimento. Lo sto facendo da più di un mese senza ulteriori problemi.

Non sono un esperto, ma ho caricato BARTpe per ottenere un prompt dei comandi e reinstallare il BIOS si è avviato direttamente sul disco rigido, suppongo che non potesse vederlo, basta provare a caricare il valore predefinito nel BIOS, potrebbe non essere necessario aggiornare

Mi rendo conto che questo è un post molto vecchio, ma ho trovato la risposta REALE per questo modello. Non è Ubuntu, è l'Aspire.

Dal registro dei bug di Ubuntu: ( collegamento )

Sembra che sia un bug BIOS / UEFI, quindi non esiste una soluzione per risolverlo su 5560g se la pianificazione utilizza efi.

Un utente su TomsGuide conferma che ciò accade anche durante l'installazione di Windows:

Il problema è che il modello ACER Aspire 5560G in qualche modo (non chiedere come {forse legato al BIOS?}) Non può arrestarsi correttamente (blocco) quando il sistema operativo è installato in uno stile di partizione GPT.

Ancora una volta dalla pagina dei bug una soluzione alternativa: ( collegamento )

Workaround: usando gdisk converti gpt in mbr, imposta boot-repair, ripristina mbr e poi ripristina grub

C'è un sacco di lavoro per sistemare una cosa così piccola. Alcuni utenti hanno suggerito che un BIOS aggiorni il mio aiuto.

DISCLAIMER: Non posso confermare nulla al di fuori del fatto che si verifichi l'errore e che Windows abbia effettivamente gli stessi problemi quando installato con gpt. Se decido di seguire la soluzione alternativa (molto rischioso) o aggiornare il BIOS (ancora più rischioso) e ottenere ulteriori risultati, aggiornerò.