problema con Grub dopo aggiornamento del 18/02/2020

[oquintoo]

Salve,
avevo appena risolto con clean update un problema con l'aggiornamento del 14/02/2020,....adesso si è presentato un problema che non mi è mai capitato , dopo l'aggiornamento di oggi l'avvio è diventato lunghissimo....
...ho pensato problemi alla scheda madre però ho provato con un vecchio disco che avevo e l'avvio è normale, ovvero dopo le schermate della scheda madre avvia istantaneamente il grub del disco con i vari os tra cui un vecchio manjaro.
Invece con il disco con Manjaro aggiornato, dopo le schermate con indicata la RAM e i dischi, al momento che deve accedere alla schermata del Grub passa un minuto buono con schermo nero, poi si avvia normalmente.

Non penso di risolvere ma mi domando come un aggiornamento può modificare l'accesso al disco, nel senso che essendo nel Master Boot credevo che non fosse modificabile,....ho testato il disco ed è buono ,.....poi comunque una volta avviato funziona normalmente ,

ho provato a reinstallare il grub ma il problema è nel passaggio dalla scheda madre al Grub

Ripeto, l'unica verifica che ho fatto è della scheda madre che con un'altro disco funziona perfettamente,.....

[andy2]

Secondo me il disco non c'entra nulla, probabilmente è qualche servizio all'avvio che magari attende più tempo del previsto.
Intanto prova a vedere cos'è che rallenta.
Da un terminale lancia il comando

Codice: [Seleziona]

systemd-analyze blameche ti elenca tutto quello che avviene alla partenza con i relativi tempi.

Anche se tu dici che te lo fa prima del grub? In questo caso sarebbe strano, hai solo manjaro come sistema?
Magari prova a controllare che non sia stata cambiata la configurazione del grub (non dovrebbe).

P.S. Controlla anche magari se hai spazio libero a sufficienza sulle varie partizioni.

[oquintoo]

Grazie per la risposta, invio il comando

Codice: [Seleziona]

[corrado@manquad ~]$ systemd-analyze blame
         12.725s udisks2.service
          7.629s mariadb.service
          7.537s lvm2-monitor.service
          6.563s polkit.service
          5.679s org.cups.cupsd.service
          5.384s dev-sda8.device
          4.838s ufw.service
          4.236s systemd-journal-flush.service
          3.365s accounts-daemon.service
          2.587s avahi-daemon.service
          2.579s ModemManager.service
          2.562s NetworkManager.service
          2.552s systemd-logind.service
          2.477s upower.service
          1.929s systemd-udevd.service
          1.567s tlp.service
          1.144s colord.service
           948ms mnt-ARCHIVIO.mount
           900ms systemd-timesyncd.service
           827ms mnt-BACKUP.mount
           803ms mnt-IIARCHIVIO.mount
           723ms systemd-fsck@dev-disk-by\x2duuid-a28994ff\x2da268\x2d492a\x2db>
           600ms systemd-journald.service

Anche se tu dici che te lo fa prima del grub? In questo caso sarebbe strano, hai solo manjaro come sistema?

Lo fa prima del Grub, per questo è molto strano..., per esempio ho fatto la prova mettendo il cd di supergrub nel masterizzatore e in fase di boot lo carica immediatamente con la schermata "ricerca os" e immediatamente li vede e ,scusa se mi ripeto ma, immediatamente avvia il sistema scelto.Come ho già scritto, avendo casualmente un vecchio disco dello stesso pc , ho provato ad avviarlo e funziona perfettamente ( nonostante sia un SATA 150)
Per quello che riguarda i sistemi operativi ce ne ho diversi , uso principalmente Manjaro, al bisogno Win 10, Xubuntu per il multimediale e Debian per gestire il database della mia associazione , poi altri solo per testarli....comunque ti scrivo il mio grub.conf

Codice: [Seleziona]

Found Windows 10 on /dev/sda1
Found Ubuntu 18.04.2 LTS (18.04) on /dev/sda10
Found Ubuntu 18.04.3 LTS (18.04) on /dev/sda3
Found PCLinuxOS on /dev/sda7
Found Debian GNU/Linux 9 (stretch) on /dev/sda9
Found Ubuntu 18.04.1 LTS (18.04) on /dev/sdb7
Found Ubuntu 14.04.5 LTS (14.04) on /dev/sdb8
Found MX 18.3 Continuum (18.3) on /dev/sdb9
Found memtest86+ image: /boot/memtest86+/memtest.bin
done


[oquintoo]

Ho provato a riscrivere un ISO del sistema di un mese fa e incredibilmente adesso si avvia normalmente...
con il comando systemd-analyze blame

Codice: [Seleziona]

8.292s mariadb.service
          8.058s lvm2-monitor.service
          7.531s systemd-journal-flush.service
          6.565s udisks2.service
          6.202s org.cups.cupsd.service
          5.953s polkit.service
          5.711s dev-sda8.device
          4.246s ufw.service
          3.317s ModemManager.service
          2.845s accounts-daemon.service
          2.500s systemd-udevd.service
          2.298s avahi-daemon.service
          2.272s NetworkManager.service
          2.263s systemd-logind.service
          1.239s tlp.service
           897ms mnt-ARCHIVIO.mount
           874ms systemd-timesyncd.service
           815ms mnt-BACKUP.mount
           787ms mnt-IIARCHIVIO.mount
           621ms systemd-journald.service
           576ms colord.service
           572ms systemd-fsck@dev-disk-by\x2duuid-a28994ff\x2da268\x2d492a\x2db>
           490ms lightdm.service

l'unica voce che manca rispetto a prima è
 

Codice: [Seleziona]

12.725s udisks2.service
e comunque questo ritardo lo vedevo in fase di caricamento , invece io mi riferisco ad una schermata nera di un minuto abbondante

Codice: [Seleziona]

a start job is running  dev/disk/by-uuid
Adesso il problema è che non potrei aggiornare  , anche perchè trovare l'aggiornamento che mi provoca questo ritardo nell'avvio è come cercare un ago in un pagliaio .....

[andy2]

Purtroppo in questi casi forse la cosa più pratica è farsi un backup, aggiornare e vedere che succede, se va male, ripristinare il backup. Visto mai uno degli aggiornamenti risolva il problema.
O magari, riaggiornando ora, sei più fortunato e non si verifica più il problema.

[Cubanpit]

Aspetta, sulla schermata compare il seguente messaggio?

Codice: [Seleziona]

a start job is running  dev/disk/by-uuid
Se la risposta è sì, allora non può essere prima di GRUB, il sistema sta già partendo e semplicemente non trova uno dei dispositivi da montare all'avvio, se si avvia ugualmente si tratta probabilmente della partizione di swap.

[oquintoo]

@Cubanpit

Aspetta, sulla schermata compare il seguente messaggio?

Codice: [Seleziona]

a start job is running  dev/disk/by-uuid
Si , però è un ritardo che ho osservato nella fase di caricamento del sistema operativo ed è  durato 90 secondi, ...osservato nel senso che vicino alla stringa erano descritti i secondi che scorrevano...
...io invece mi riferisco alla fase precedente , ovvero quando il bios della  scheda madre ha finito di riconoscere i vari hardware e la schermata di grub con la scelta dei vari sistemi operativi, è tra queste due fasi che c'è una schermata nera di un minuto abbondante.....che prima durava un attimo.
La cosa curiosa è che questo minuto di schermata nera rimane anche se avvio windows..... in tanti anni è la cosa più strana che mi sia capitata 

[Cubanpit]

Tanto per essere sicuri, questa pagina suggerisce di controllare lo spazio su disco, perché potrebbe causare un ritardo nel caricamento di GRUB.

[oquintoo]

problemi di spazio non ci sono, comunque è un problema legato al Grub

Ho fatto una prova "stupida" , ho riscritto l'immagine del sistema di un mese fa quando non presentava il problema, poi ho salvato il grub.cfg, poi ho aggiornato e mi sono ritrovato il problema con la schermata nera che dura un minuto circa.
Poi ho sovrascritto il grub.cfg che avevo salvato e il problema è scomparso...
...adesso devo trovare la differenza tra i due grub.cfg e non sono pratico del comando  diff per vedere le differenze nelle stringhe

.... rimane una non soluzione perchè se aggiorno il grub il problema si ripresenta

comunque grazie per l'aiuto

[oquintoo]

Trovato l'arcano,  in pratica il Grub riscrive decine e decine di volta 2 partizioni ,  mi sono accorto che il  vecchio grub era di 317 KiB e quello che mi genera adesso è di 1.1 MiB

Ho fatto la prova di eliminare tutte le voci duplicate dal grub e il sistema si carica normalmente,...per il momento quando aggiorno devo correggere il grub che comunque forse non è il vero responsabile....... nel senso che potrebbe esserci problemi di "riconoscimento" da parte delle partizioni.

[Cubanpit]

Quali voci vengono ripetute? Com'è fatto il tuo file /etc/fstab?
Non conosco bene la procedura con cui GRUB genera le sue configurazioni, ma magari è sufficiente cambiare il modo in cui vengono indicate le partizioni per circumnavigare il problema.

[oquintoo]

Queste due si ripetono decine e decine di volte, per capirsi 3/4 del grub ripete l'accesso a queste due partizioni......

Codice: [Seleziona]

menuentry 'Ubuntu 18.04.1 LTS (18.04) (su /dev/sdb7) (su /dev/sda3) (su /dev/sda9) (on /dev/sdb8)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz--36ece854-a7f2-4bfd-8bac-febcd3230345' {
savedefault
insmod part_msdos
insmod ext2
set root='hd1,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos8' --hint-bios=hd1,msdos8 --hint-efi=hd1,msdos8 --hint-baremetal=ahci1,msdos8  36ece854-a7f2-4bfd-8bac-febcd3230345
else
  search --no-floppy --fs-uuid --set=root 36ece854-a7f2-4bfd-8bac-febcd3230345
fi
linux /vmlinuz root=/dev/sdb7
initrd  /initrd.img.old
}
menuentry 'MX 18.3 Continuum (18.3) (su /dev/sdb9) (su /dev/sda3) (su /dev/sda9) (on /dev/sdb8)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz--36ece854-a7f2-4bfd-8bac-febcd3230345' {
savedefault
insmod part_msdos
insmod ext2
set root='hd1,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos8' --hint-bios=hd1,msdos8 --hint-efi=hd1,msdos8 --hint-baremetal=ahci1,msdos8  36ece854-a7f2-4bfd-8bac-febcd3230345
else
  search --no-floppy --fs-uuid --set=root 36ece854-a7f2-4bfd-8bac-febcd3230345
fi
linux /vmlinuz root=/dev/sdb9
initrd  /initrd.img
}Il file etc/fstab

Codice: [Seleziona]

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=a28994ff-a268-492a-b696-1753347e9549 /home          ext4    defaults,noatime 0 2
UUID=3002c6e5-6903-47d7-bdd3-f22ee611e80c swap           swap    defaults,noatime 0 2
UUID=1ea89163-6b6b-4cc0-a72b-dafb793e145c /              ext4    defaults,noatime 0 1
UUID=4A0EC5320EC517B9    /mnt/ARCHIVIO ntfs silent,umask=000,utf8 0 0
UUID=F228863E9FE8ACF1    /mnt/IIARCHIVIO ntfs silent,umask=000,utf8 0 0
UUID=4058B78058B77370    /mnt/BACKUP ntfs silent,umask=000,utf8 0 0

Per curiosità ho avviato Gparted ed ho notato che aveva invertito i nomi delle partizioni, ovvero sda1 sda 2 sda3 e via discorrendo, me li ha fatti vedere come sdd1 sdd2 e così via,....c'è qualcosa in questo riconoscimento dei dischi che potrebbe essere la causa del problema

[Cubanpit]

Okay, quindi non è la voce di Manjaro che viene ripetuta, prova a controllare i file fstab dei sistemi che vengono ripetuti.
Nel file grub.cfg dovrebbero esserci delle sezioni divise da commenti, tutta la sezione con le ripetizioni è generata da 10_linux?

[oquintoo]

No, ...la voce "10_linux" compare correttamente due volte a BEGIN e a END,
...quelli che si ripetono sono Xubuntu e MXLinux  e tutti e due sono su un secondo disco sdb , invece Manjaro è su sda

Questo è il fstab di MXLinux

Codice: [Seleziona]

# Pluggable devices are handled by uDev, they are not in fstab
UUID=6b0e9758-c6e6-4a0e-a4a5-bf326d38a846 / ext4 defaults,noatime 1 1
UUID=3002c6e5-6903-47d7-bdd3-f22ee611e80c swap swap defauts 0 0
...l'unica differenza che ho trovato rispetto agli altri è che alla fine della prima stringa termina con 1 1 , quando in tutti gli altri finisce con 0 1 ,...però ho provato a mettere lo zero e rifare il grub ma mi fa lo stesso problema

[Cubanpit]

No, ...la voce "10_linux" compare correttamente due volte a BEGIN e a END,

Quindi tutte quelle voci sono generate dal file /etc/grub.d/10_linux, che per qualche motivo fa casini.
Il penultimo "1" di solito non viene usato, chiama il comando dump che viene usato per alcune forme di backup.

Ho trovato questo vecchio bug, ma se come dici è tutto generato da 10_linux il problema non è lo stesso. Bisognerebbe andare a capire quale riga di questo file va a generare i duplicati, si tratta di un lavoro un po' lunghetto.