problema riavvio kernel 3.2.x compilato da sorgente (ubuntu 11.04)

Ho un nuovo elemento.

All'avvio del sistema, appena prima della comparsa della schermata di login, su schemata nera viene visualizzato in alto a destra il seguente messaggio di errore: "init: ureadahead main process (249) terminated with status 5".

Mi era capitato una volta quando qualche giorno fa avevo aggiornato i kernel ufficiali (2.6.38-13 credo) e avevo riavviato, ma non ci avevo fatto molto caso; dopo un semplice aggiornamento di pacchetti di questa mattina sembra farlo sempre.

Grazie ancora per eventuali aiuti!

Solo una precisazione sul messaggio di errore: il numero tra le parentesi dopo "process" non è sempre lo stesso.

Grazie

Ciao devtry,
non sono un esperto nel campo del kernel, provo comunque a darti una mano.

Credo che un possibile problema possa essere la configurazione del kernel stesso - ti suggerirei di compilare il kernel a mano copiando la configurazione del vecchio kernel (è in /boot/config-<nome vecchia versione>) in un file chiamato .config all'interno della directory dei sorgenti e poi dando il comando "make oldconfig" al posto di "make config/make xconfig" e simili. In questo modo verrà utilizzata la configurazione vecchia, ti verranno poste domande solo per le opzioni aggiunte alla nuova release che non hanno un corrispettivo in quella vecchia.

L'altro modo è scaricare i pacchetti già pronti dal sito del team del kernel (<http://kernel.ubuntu.com/~kernel-ppa/mainline>). Prova a scaricare il kernel per Ubuntu Precise (12.04), dovrebbero andare comunque bene (chiaramente fai un backup prima di procedere, non si sa mai).

Se il problema era di configurazione non dovresti riscontrare ulteriori malfunzionamenti; in caso contrario l'unica strategia attuabile è installare versioni sempre meno recenti del kernel e continuare a provare fino a che non si giunge alla prima versione che non presenta più il malfunzionamento. A quel punto uno sviluppatore dovrebbe esaminare il codice che è stato modificato da quella versione a quella successiva e riflettere sulle possibili cause.

Per quanto riguarda il problema di ureadahead, sembra che qualche disco/partizione non venga montato correttamente all'avvio. È difficile però fornire una spiegazione plausibile, alcuni (vedi ad es. <http://ubuntuforums.org/showthread.php?t=1423305>) dicono di controllare il file /etc/fstab e vedere se tutto è in ordine (magari gli UUID dei dischi sono stati modificati), non mi fido tuttavia a dare una risposta definitiva visti i problemi del nuovo kernel.

Ciao Alessandro,

grazie per la tua risposta.

Per la configurazione del kernel ho usato "make gconfig"; mi sembra però di aver comunque caricato da lì la vecchia configurazione (questo già per il 3.2.1). Tuttavia non sono del tutto certo di averlo fatto e potrei aver poi modificato qualcosa, quindi proverò a fare come dici te usando "make oldconfig". Una domanda: usando questo comando non va a prendere la configurazione dell'ultimo kernel (nel mio caso quello incriminato)?

Avevo inizialmente pensato di usare i pacchetti precompilati di Ubuntu, ma avevo rinunciato pensando due cose:
 - se lo compilo io dovrei avere prestazioni migliori (non so se è un'impressione ma sembra essere così, per esempio nel tempo di spegnimento)
 - non essendo un esperto mi sono chiesto se il fatto che sono per Precise possa dare problemi su un'altra versione di Ubuntu

Per l'altro problema proverò a dare un'occhiata al thread sul forum (grazie per l'indicazione), ma forse è meglio prima provare a mettere a posto il kernel e vedere cosa succede.

Grazie ancora per l'aiuto!

> Una domanda: usando questo comando non va a prendere la configurazione dell'ultimo kernel (nel mio caso quello incriminato)?
Se intendi "prendere" come "copiare automaticamente dalla directory /boot", no (devi copiare il file di configurazione a mano nella cartella dei sorgenti del nuovo kernel). Se invece intendi "prendere" come "utilizzare la stessa configurazione del vecchio kernel", allora sì (dovrai solo configurare le opzioni comparse nella nuova versione del kernel). Con la stessa configurazione dovresti evitare problemi di incompatibilità.

> Avevo inizialmente pensato di usare i pacchetti precompilati di Ubuntu, ma avevo rinunciato pensando due cose:
> - se lo compilo io dovrei avere prestazioni migliori (non so se è un'impressione ma sembra essere così, per esempio nel tempo di spegnimento)
> - non essendo un esperto mi sono chiesto se il fatto che sono per Precise possa dare problemi su un'altra versione di Ubuntu
Per quanto riguarda la compilazione hai ragione; per quanto riguarda la versione del pacchetto, effettivamente alcune incompatibilità in linea di principio potrebbero esserci, nella pratica non ne ho mai incontrata una. Fra l'altro con una ricerca ho trovato questo thread su Ubuntu-it (<http://forum.ubuntu-it.org/index.php?topic=502512.msg3924754>) in cui si suggerisce proprio di utilizzare i pacchetti per Precise. In ogni caso ti consiglio di mantenere comunque il vecchio kernel a fianco di quello nuovo, così se dovessi riscontrare problemi puoi sempre "tornare indietro". (Un suggerimento: se compili il kernel da sorgente ti conviene usare questi comandi:
sudo apt-get install kernel-package
cp /boot/config-<versione vecchio kernel> .config
make oldconfig
make-kpkg clean
make-kpkg kernel_image
In questo modo dopo aver compilato il kernel verranno automaticamente creati i pacchetti .deb che lo contengono, così potrai rimuoverlo facilmente se necessario.)

Un'ultima nota: se utilizzi make-kpkg e ti compaiono errori, potrebbero essere necessarie delle piccole modifiche ai sorgenti (vedi <https://wiki.ubuntu.com/KernelTeam/GitKernelBuild>, punto 7).

Grazie mille, mi hai chiarito un po' le idee!

Credo che per prima cosa procederò con una compilazione fatta per bene e con la vecchia configurazione (speriamo che risolva i problemi).

Ottimo l'ultimo link: mi sembra molto utile e contiene anche il collegamento alla pagina inglese della wiki per la compilazione (l'avevo cercata ma non l'avevo trovata) che mi sembra più completa e aggiornata di quella italiana.

Mi ci vorrà un attimo di tempo perchè sono impegnato in altre cose; appena ho fatto riporto i risultati sperando che siano positivi.

Grazie ancora e a presto!

Ho ricompilato e reinstallato il kernel 3.2.2 utilizzando la configurazione del vecchio kernel ufficiale di Ubuntu: il problema del riavvio persiste. Non ho fatto le modifiche ai sorgenti indicate nel link di Alessandro, ma non mi sembra che la compilazione abbia dato errori, forse qualche warning: devo provare a compilarlo con quelle modifiche (non so neanche bene cosa facciano)?

Ho provato anche ad installare il kernel 3.2.2 ufficiale di Ubuntu 12.04, il problema rimane.

Tutto ciò mi fa pensare che il problema sia proprio del kernel.

Provo col 3.1.10?

Grazie

Dimenticavo: le patch che si trovano su http://www.kernel.org/ accanto ai link "Full Source", cosa sono?

Sono per chi ha una versione più vecchia del kernel o sono da applicare al kernel a cui si riferiscono? Potrei quindi provare ad applicare la patch (magari corregge il problema)?

Grazie ancora!

Per quanto riguarda le patch di kernel.org, queste sono semplicemente le patch da applicare ai kernel della versione immediatamente precedente per passare a quella successiva. Ad esempio, se ho i sorgenti della versione 3.2.2 del kernel e voglio aggiornarlo alla versione 3.2.3, basta che scarichi la patch della versione 3.2.3 e la applichi ai sorgenti della versione 3.2.2. In questo modo evito di scaricare nuovamente tutto l'archivio compresso del kernel e scarico solamente le modifiche, riducendo il tempo di download e il consumo di banda. Nel tuo caso quindi queste patch non si applicano.

Le modifiche ai sorgenti di cui ti ho parlato servono solo per consentire a make-kpkg di generare i pacchetti Debian del kernel correttamente e non dovrebbero aver influenza sulla funzionalità.

Il problema potrebbe essere sia nel kernel come hai detto tu, sia in una delle utilità (quali ureadahead) che si appoggiano ad esso (magari le rispettive versioni non supportano correttamente gli ultimi kernel). Potresti provare a:
1) installare versioni sempre precedenti del kernel come hai detto e verificare qual è l'ultima che non da' problemi;
2) provare a installare anche Ubuntu 11.10 (che ha incorporato i kernel della serie 3.0) a fianco di Ubuntu 11.04 e a compilare gli ultimi kernel su quella versione di Ubuntu (i programmi di utilità lì dovrebbero essere compatibili);
3) controllare nella documentazione del kernel quali versioni del compilatore e delle utilità sono richieste (file Documentation/changing) e controllare che siano presenti nella tua versione di Ubuntu;
4) provare a chiedere sul canale IRC #ubuntu; benché l'installazione dei kernel non compilati da Ubuntu stessa non sia ufficialmente supportata, magari qualcuno con un po' più d'esperienza potrebbe darti una mano.

Provo col punto "3)": ho dato un'occhiata e non ho trovato il file "changing", ma uno che si chiama "Changes" e mi sembra che sia quello; ho già visto che mi manca qualcosa, quindi, anche se magari non è quello, faccio un tentativo. Oltretutto è uscito il kernel 3.2.4, quindi c'è qualche speranza in più.

Dimenticavo: grazie per la risposta!

Ho installato i pacchetti indicati nel file "Changes" che mi mancavano e ho compilato ed installato il kernel 3.2.4: il problema è sempre presente.

Non provo neanche col 3.2.5 che risolve solo il problema del consumo energetico.

Adesso penso di provare ad installare versioni vecchie fino a trovarne una che funziona come avevi subito suggerito te. A tal proposito: lo spazio sul disco rigido mi sta finendo e ho visto che sono i kernel che sono andati ad occupare svariati GB (soprattutto per la compilazione). Per le prove userò i pacchetti precompilati di Ubuntu, ma come faccio a rimuovere in maniera pulita i kernel che non mi servono? Le cartelle in cui ho compilato posso poi eliminarle?

Ultima cosa: potrebbe avere senso provare poi col kernel 3.3?

Grazie ancora!

Per rimuovere i kernel che non ti servono, se hai usato make-kpkg basta rimuovere i pacchetti linux-image-<versione> e linux-headers-<versione>, dove <versione> è la versione del kernel che non ti serve. Quest'azione disinstalla il kernel dal sistema. Puoi quindi rimuovere le cartelle dei sorgenti (con il classico rm -rf <nomecartella>). Stai chiaramente attento a non rimuovere l'ultima versione del kernel ufficiale di Ubuntu (la 2.6.38-13).

Per quanto riguarda il kernel 3.3, personalmente ti sconsiglierei di provarlo, se non altro perché è la versione di sviluppo instabile. La differenza tra i kernel della serie 2 e quelli della serie 3 è abbastanza marcata (il cambio di numero di versione lo conferma), è tale differenza secondo me a causare i problemi. Ho controllato i changelog e ad un primo esame non ci sono variazioni rilevanti tra i kernel 3.2 e quelli 3.3 dal punto di vista che stiamo trattando.

In ogni caso, se il bug del blocco/riavvio si dovesse verificare anche con i kernel ufficiali ti suggerisco di inviare un report (purtroppo i problemi legati all'alimentazione dipendono molto dai singoli BIOS, più o meno bacati, fornendo un report dettagliato con marca/modello della scheda madre e versione del BIOS si potrebbe vedere se il problema c'è anche nei nuovi kernel e lo si potrebbe risolvere).

Grazie, adesso ho di nuovo spazio libero.

Avevi ragione:

- ultima versione funzionante: 2.6.39.4
- prima versione col problema del riavvio: 3.0.0

Un'ultima verifica potrebbe essere quella che proponevi anche te: installare Ubuntu 11.10 che ha già il kernel della serie 3 (quindi ufficialmente supportato). Riesco però poi a recuperare in un secondo tempo la partizione fatta per installarlo e reintegrare lo spazio nello partizione dell'11.04?

E dire che il BIOS l'ho anche aggiornato all'ultima versione disponibile prima di installare Ubuntu.

Comunque, volendo descrivere meglio il problema:

- con i kernel funzionanti il sistema viene arrestato, le ventole continuano a girare, dopo breve compare la schermata del produttore e tutto va bene (forse lo schermo non si spegne neanche mai veramente: è nero ma è acceso)

- con i kernel "buggati" il sistema viene arrestato, si spegne lo schermo, si fermano le ventole, le ventole ripartono, dopo un paio di secondi si sente un rumore secco ed è come se il computer fosse completamente spento; dopo un altro paio di secondi il computer si riaccende da solo e tutto prosegue normalmente

> Riesco però poi a recuperare in un secondo tempo la partizione fatta per installarlo e reintegrare lo spazio nello partizione dell'11.04?
Sì, tranquillamente. Puoi fare l'aggiornamento diretto della release (attenzione però, c'è un bug che ti richiede, dopo l'aggiornamento, di eseguire il boot in modalità di ripristino e di creare un link simbolico per consentire il boot completo: <https://bugs.launchpad.net/bugs/858122>, la soluzione è nell'"original report" in alto: "To correct the broken symlinks, run the following commands as root:..." o, in alternativa, quella descritta qui: <https://uksysadmin.wordpress.com/2011/10/14/upgrade-to-ubuntu-11-10-problem-waiting-for-network-configuration-then-black-screen-solution/>) oppure installare Ubuntu 11.10 in un'ulteriore partizione, copiare i documenti da quella vecchia, quindi avviare da Live CD, eliminare la vecchia partizione e ingrandire la nuova.

Sarebbe interessante installare Ubuntu 11.10 e, se il problema c'è ancora, provare a eseguire dei test sul kernel come descritto qui: <https://wiki.ubuntu.com/BIOSandUbuntu>. I test della sezione "BIOS checking tools" e "Reboot Methods" sono secondo me quelli da cui si dovrebbe iniziare.

Caro Alessandro,

scusa per la mia lunghissima assenza, ma il computer bene o male funzionava ed non ho più avuto tempo di occuparmi di questo problema.

Grazie per la tua ultima risposta: ho seguito i tuoi consigli.

Ho installato Ubuntu 11.10 accanto all'11.04 (ridimensionando la partizione di Natty) e a Windows (poco utilizzato, ma è sempre lì); ho quindi avviato il nuovo OS e ho fatto tutti gli aggiornamenti; ho provato il riavvio: stesso solito problema.

Sono passato allora ai test sul kernel (seguendo la wiki di Ubuntu che mi hai indicato); ho lanciato fwts ed ho ottenuto alcuni fallimenti; non saprei però bene come interpretarli: riporto il sommario del file "results.log" nel caso tu (o altri) ci capisca di più.

---------------- INIZIO ---------------

01498 summary
01499 summary 292 passed, 21 failed, 1 warnings, 1 aborted, 92 skipped, 2 info only.
01500 summary
01501 summary Test Failure Summary
01502 summary ====================
01503 summary
01504 summary Critical failures: NONE
01505 summary
01506 summary High failures: 3
01507 summary fadt test, at 1 log line: 1341
01508 summary "FADT pm1a register has invalid bit width of 0."
01509 summary syntaxcheck test, at 1 log line: 1426
01510 summary "Assembler error in line 1879"
01511 summary syntaxcheck test, at 1 log line: 1446
01512 summary "Assembler error in line 1886"
01513 summary
01514 summary Medium failures: 9
01515 summary mtrr test, at 1 log line: 79
01516 summary "Memory range 0x80000000 to 0xfebfffff (PCI Bus 0000:00) has incorrect attribute Write-Combining."
01517 summary msr test, at 1 log line: 167
01518 summary "MSR CLOCK_MODULATION (0x19a) has 1 inconsistent values across 2 CPUs for (shift: 0 mask: 0x1f)."
01519 summary dmi_decode test, at 1 log line: 374
01520 summary "DMI type Processor: Out of spec check."
01521 summary wmi test, at 1 log line: 571
01522 summary "GUID CC1A61AC-4256-41A3-B9E0-05A445ADE2F5 is unknown to the kernel, a driver may need to be implemented for this GUID."
01523 summary method test, at 5 log lines: 946, 956, 966, 976, 986
01524 summary "\_PTS returned values, but was expected to return nothing."
01525 summary method test, at 5 log lines: 1022, 1027, 1032, 1037, 1042
01526 summary "Method \_WAK did not return ACPI_TYPE_PACKAGE."
01527 summary fadt test, at 1 log line: 1337
01528 summary "32 and 64 bit versions of FADT pm1_cnt address do not match (0x00000404 vs 0x0000000000000000)."
01529 summary fadt test, at 1 log line: 1339
01530 summary "32 and 64 bit versions of FADT pm1_cnt size do not match (0x10 vs 0x0)."
01531 summary acpitables test, at 1 log line: 1398
01532 summary "FADT 32 bit FIRMWARE_CONTROL is non-zero, and X_FIRMWARE_CONTROL is also non-zero. Section 5.2.9 of the ACPI specification states that if the FIRMWARE_CONTROL is non-zero then X_FIRMWARE_CONTROL must be set to zero."
01533 summary
01534 summary Low failures: 1
01535 summary maxreadreq test, at 1 log line: 319
01536 summary "2 devices have low MaxReadReq settings. Firmware may have configured these too low."
01537 summary
01538 summary Other failures: NONE
01539 summary
01540 summary Test |Pass |Fail |Abort|Warn |Skip |Info |
01541 summary ---------------+-----+-----+-----+-----+-----+-----+
01542 summary acpiinfo | 1| | | | | |
01543 summary acpitables | 6| 1| | | | |
01544 summary apicedge | 1| | | | | |
01545 summary apicinstance | 1| | | | | |
01546 summary bios32 | | | | | | |
01547 summary bios_info | | | | | | 1|
01548 summary checksum | 14| | | | | |
01549 summary crs | 1| | | | | |
01550 summary cstates | 3| | | | | |
01551 summary dmesg_common | 1| | | | | |
01552 summary dmi_decode | 39| 1| | | | |
01553 summary ebda | 1| | | | | |
01554 summary fadt | | 3| | | | |
01555 summary fan | 3| | | | | |
01556 summary hda_audio | 2| | | | | |
01557 summary hpet_check | 4| | | | | |
01558 summary klog | 1| | | | | |
01559 summary maxfreq | 1| | | | | |
01560 summary maxreadreq | | 1| | | | |
01561 summary mcfg | 2| | | | | |
01562 summary method | 139| 10| | | 81| |
01563 summary microcode | | | 1| | | |
01564 summary mpcheck | | | | | 9| |
01565 summary msr | 56| 1| | | | |
01566 summary mtrr | 1| 1| | | 1| |
01567 summary nx | 3| | | | | |
01568 summary oops | 1| | | | | |
01569 summary os2gap | 1| | | | | |
01570 summary osilinux | | | | 1| | |
01571 summary smbios | 1| | | | | |
01572 summary syntaxcheck | 1| 2| | | | |
01573 summary version | 3| | | | | |
01574 summary virt | | | | | 1| |
01575 summary wakealarm | 4| | | | | |
01576 summary wmi | 1| 1| | | | 1|
01577 summary ---------------+-----+-----+-----+-----+-----+-----+
01578 summary Total: | 292| 21| 1| 1| 92| 2|
01579 summary ---------------+-----+-----+-----+-----+-----+-----+

---------------- FINE ---------------

Sono passato allora all'altro punto: i vari metodi di riavvio. L'unica cosa che potevo fare era provare; su un sito ho trovato che la modifica va fatta sul file "/etc/default/grub" modificando la linea GRUB_CMDLINE_LINUX=”” mettendo fra i doppi apici "reboot=<metodo>" (con successivo "sudo update-grub"). Ho provato con "a", "p": niente da fare. Ho provato con "b": il riavvio funzionava (tutto ciò sull'11.10).

A quel punto ho sperato che il problema fosse risolto, ma ho pensato di controllare anche il comportamento con Ubuntu 11.04. Nel dubbio che fosse necessario ho fatto anche lì la modifica a "/etc/default/grub". Non ha funzionato!

Ho provato a fare altre modfiche al metodo per il riavvio (da Ubuntu 11.04) : l'11.04 non funziona mai e Ubuntu 11.10 funziona sempre.

A questo punto (non sapendo bene come funziona) mi chiedo: il problema è che Ubuntu 11.10 ormai è in qualche modo il "master" e controlla lui grub (per cui non si riesce più a modificare il metodo di riavvio per l'11.04)? O c'è altro che non va?

Prima ero convinto che fosse un bug del kernel, adesso non so più bene cosa pensare. Dovrei provare a togliere l'11.10 per vedere se da solo l'11.04 va a posto con "reboot=b"? Non c'è un altro metodo per cambiare il metodo di reboot?

Ho visto anche che il kernel nel frattempo è andato avanti: può valer la pena provare il 3.2.9?

Grazie per qualsiasi aiuto!

Un particolare che mi ero dimenticato di dire: con alimentazione da batteria, dopo lo spegnimento "secco", il computer non si riavvia, ma rimane spento.

Ho trovato adesso su Internet che in "/proc/cmdline" si trovano tutti i comandi passati al kernel in esecuzione; su Ubuntu 11.10 compare "reboot=b" mentre su Ubuntu 11.04 non c'è nessun "reboot=<comando>": ciò conferma che Ubuntu 11.04 non recepisce le modifiche (e non le può effettuare).

Spero almeno che ciò voglia dire che "reboot=b" è la soluzione; tuttavia, possibile che non si possa impostare per entrambi gli OS?
Forse ho trovato che si può forzare il metodo direttamente nei sorgenti del kernel, ma non so se è la cosa migliore da fare.

Hai qualche consiglio?

Grazie!

> Forse ho trovato che si può forzare il metodo direttamente nei sorgenti del kernel, ma non so se è la cosa migliore da fare.

Come non detto, è già il codice così come è che dovrebbe già capire quale è il metodo giusto: quindi si può considerare comunque un bug del kernel? Si potrebbe provare ad esaminare "linux-3.x.x/arch/x86/kernel/reboot.c"?

Grazie ancora!

> Si potrebbe provare ad esaminare "linux-3.x.x/arch/x86/kernel/reboot.c"?

Avendo un certa conoscenza del C e della programmazione in generale, ho dato un'occhiata; come il kernel determini il metodo di riavvio non sono riuscito a capirlo (almeno per il momento; un kernel non è uno scherzo da capire, o almeno è così per me che essenzialmente è la prima volta che cerco di leggerlo). Tuttavia mi sembra di aver individuato una funzione che riceve la stringa del metodo come parametro e la testa per impostare le varie opzioni: da principiante mi verrebbe da dire che si possa forzare il metodo voluto in quella funzione.

Rimane però una soluzione poco elegante e non definitiva: ammesso che funzioni dovrei compilare ogni volta il kernel (ogni volta che lo cambio) con la modifica.

Ciao devtry,
non ti preoccupare per l'assenza - ho avuto un po' d'impegni anch'io ultimamente (esami universitari).

Il log del test sul kernel mostra che l'implementazione ACPI del BIOS che usi ha qualche bug (oppure che Linux non riesce a leggerla correttamente): ho notato infatti che si sono verificati alcuni errori nell'area FADT (una struttura dati contenente parametri relativi alla gestione energetica, vedi <http://wiki.osdev.org/FADT>).

Il parametro reboot=b che hai impostato richiede al kernel di utilizzare un altro metodo per il riavvio (chiedendolo al BIOS anziché tentando di operare un hard reset da solo: se vai alla pagina <https://wiki.ubuntu.com/BIOSandUbuntu>, dove c'è la lista completa dei valori possibili per tale parametro, puoi notare che il parametro "reboot=a", che mi hai detto di aver provato senza successo, sfrutta proprio ACPI, a conferma della diagnosi).

> A questo punto (non sapendo bene come funziona) mi chiedo: il problema è che Ubuntu 11.10 ormai è in qualche modo il "master" e controlla lui grub (per cui non si riesce più a modificare il metodo di riavvio per l'11.04)? O c'è altro che non va?
Ubuntu 11.10 dovrebbe essere diventato il "master" nel senso che è la partizione con Ubuntu 11.10 (la versione installata per ultima) a controllare il funzionamento di GRUB. Se però modifichi il file /etc/default/grub sulla partizione con Ubuntu 11.10, eseguendo "sudo update-grub" dovresti aggiornare le opzioni di avvio per tutte le versioni di Ubuntu (lo vedi dal file /etc/grub.d/10_linux; esso contiene la procedura "linux_entry" chiamata per ogni versione di Linux trovata nel computer, e alla riga 232 puoi notare che le opzioni del kernel sono passate a tale procedura senza distinzioni sulle versioni). Mi pare strano che tali opzioni siano state passate solo a una versione di Ubuntu e non a entrambe.
Guardando nel file /boot/grub/grub.cfg dovresti poter verificare se le opzioni sono passate a ogni versione del kernel, in caso contrario basta aggiungerle. In ogni caso puoi modificare le opzioni di avvio a ogni boot (senza bisogno di modificare i file di GRUB) spostandoti nel menu di GRUB sulla riga corrispondente all'OS che vuoi avviare, premendo "e", operando la modifica (nella riga che contiene il kernel da caricare) e premendo Ctrl+X alla fine. Lo svantaggio è che tale modifica va fatta a ogni avvio.
Hai accennato anche alla possibilità di modificare il kernel, concordo sul fatto che sia una soluzione poco elegante e complessa.

> Ho visto anche che il kernel nel frattempo è andato avanti: può valer la pena provare il 3.2.9?
Dato che con "reboot=b" il funzionamento è corretto, il problema che hai è decisamente un bug nel kernel. Pertanto, ti conviene seguire la procedura per provare l'ultima versione di sviluppo del kernel compilato da Ubuntu; se anche lì si manifesta il problema, sarà sufficiente aprire un report su Launchpad (il gruppo di lavoro del kernel di Ubuntu poi procederà a girare le informazioni agli sviluppatori del kernel Linux se il problema che hai è nel kernel e non in una patch applicata da Ubuntu stessa).

Riassumo qui le procedure per il debug in ACPI e nel kernel (<https://wiki.ubuntu.com/DebuggingACPI> e <https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies>), in modo che il bug report sia già pronto per l'analisi da parte dei programmatori.

1) Assicurati che il BIOS della tua scheda madre sia aggiornato all'ultima versione disponibile.
2) Prova ad installare l'ultima versione di sviluppo del kernel da <http://kernel.ubuntu.com/~kernel-ppa/mainline/>. Per Ubuntu 11.10 (Oneiric) l'ultima versione in questo momento è la "v3.2-rc4-oneiric", per Ubuntu 12.04 beta 1 (Precise) è la "v3.3-rc6-precise" (controlla però, i rilasci sono frequenti). Apri la cartella e scarica e installa i pacchetti corrispondenti al tipo di kernel che hai ("generic-i386" o "generic-pae i386"). Devi installare tre pacchetti complessivamente: "linux-headers-<versione>-<tipo kernel>-..._i386.deb", "linux-image-<versione>-<tipo kernel>-..._i386.deb" e "linux-headers-<versione>-..._all.deb".
Sarebbe ottimo se tu riuscissi anche a dedicare una partizione a Ubuntu 12.04 beta 1 (Precise) per fare delle prove con quella versione e vedere se il bug si verifica anche lì (dato che Ubuntu 12.04 uscirà fra poco e che tutti gli sforzi di sviluppo sono diretti verso quella versione, svolgendo anche là questi test la correzione risulta più facile). Se vuoi provare con Precise, puoi scaricarne la ISO da <http://releases.ubuntu.com/precise/ubuntu-12.04-beta1-desktop-i386.iso>.
N.B.: prima di installare i kernel di sviluppo, ti consiglio caldamente di fare un backup del sistema.
3) Riavvia il computer con il nuovo kernel e verifica che il bug sia ancora presente (se riavvii con l'opzione reboot=b il riavvio viene eseguito correttamente, in caso contrario no).
4) Se è ancora presente, riavvia il computer; non appena Ubuntu è stato caricato e hai eseguito il login, da terminale dai i seguenti comandi:
sudo dmidecode >/tmp/dmidecode.log
sudo fwts -f -r /tmp/fwts.log -b
cp -r /proc/acpi /tmp
tar -cvjf /tmp/acpi.tar.bz /tmp/acpi

È importante dare questi comandi non appena entrato nel sistema, in modo da avere dei log più puliti possibile.

Sempre da terminale dai poi il comando:

ubuntu-bug linux

Segui quindi le istruzioni: si aprirà una pagina di Launchpad in cui dovrai compilare il bug report in inglese.
Quando scrivi il report, nella descrizione precisa:
-marca e modello del computer (o della scheda madre);
-versione del BIOS;
-di' che hai utilizzato l'ultima versione di sviluppo del kernel (dicendo il numero di versione ricavato al passo 2);
-descrivi in dettaglio il problema del riavvio e il fatto che il parametro "reboot=b" in GRUB lo risolve.
Invia il report, Launchpad ti visualizzerà la sua pagina. Usando il collegamento per aggiungere un allegato, includi questi file uno alla volta, come allegati separati:
-/tmp/dmidecode.log
-/tmp/fwts.log
-/tmp/acpi.tar.bz
A questo punto il team del kernel darà un'occhiata e tenterà di determinare dove si annida il bug - controlla di frequente il report inviato perché potrebbe esserti richiesto di eseguire ulteriori comandi diagnostici (ciò accade abbastanza spesso, da quanto ho visto).

Mi rendo conto che la procedura è un po' complessa, se hai bisogno di chiarimenti chiedimi pure.

Grazie ancora per le informazioni dettagliate e per la precisione!

Ciao Alessandro,

grazie a te per la tua disponibilità e la tua chiarezza!

Ho controllato il file "/boot/grub/grub.cfg": effettivamente le opzioni non vengono passate ad Ubuntu 11.04; le voci relative a Natty non compaiono sotto "### BEGIN /etc/grub.d/10_linux ###", ma sotto "### BEGIN /etc/grub.d/30_os-prober ###" insieme a Windows. Quindi mi viene da pensare che non lo riconosca come un OS di tipo GNU/linux.

Sembra anche a me una buona idea installare Ubuntu 12.04 (anche perchè così posso provare senza alcun problema l'ultimissimo kernel); devo solo trovare spazio e tempo (spero di farcela entro il fine settimana).

Mi chiedevo solo questo: entrambe le versioni di Ubuntu che ho installato sono a 32 bit, ma il processore del mio notebook è a 64 bit; fino ad ora sono rimasto sui 32 per i seguenti motivi

 - fino a qualche tempo fa mi sembra ci fosse qualche problemino (ad esempio flash) sulle versioni a 64 bit
 - la versione ufficialmente consigliata era quella a 32 bit
 - dopotutto ho 2 GB di memoria

Adesso che non dovrebbero esserci più problemi mi conviene installare la versione a 64 bit per fare i vari test e simili?
Avevo anche letto che con Precise questa versione diventerà quella consigliata. Farei così, però in "linux-3.x.x/arch/x86/kernel/reboot.c" c'è scritto:

/* reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] | p[ci]
...
...
...
bios Reboot by jumping through the BIOS (only for X86_32)
...
...
....
 */

Se non sbaglio "X86_32" indica i sistemi a 32 bit: quindi non potrei fare la prova con "reboot=b"?

Per la procedura di report del bug per adesso mi sembra tutto chiaro; mi leggo poi tutto con calma (i link che mi hai indicato) e se al momento di farlo mi vengono dei dubbi ti faccio sapere.

Grazie ancora!

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Buongiorno,

sto procedendo con l'installazione di ubuntu 12.04 e con il report del bug.
Aggiungerò in seguito informazioni sugli esiti.

Grazie

Ho riportato il bug: "https://bugs.launchpad.net/bugs/964687".

Ho inserito il link al bug nella pagina di questa domanda.

Darò aggiornamento sullo stato del bug.

Grazie mille (anche per il report dettagliato!)

Grazie a te per tutto l'aiuto!

Come mi è stato suggerito da Joseph Salisbury (in risposta al report del bug) riporto il bug anche upstream.
Appeno ho fatto, inserisco un commento col link.

Grazie

Di niente - per il commento non ti preoccupare, mi sono "iscritto" al bug in modo da poterlo seguire.