Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[RISOLTO] Avvio lento in dual boot su MacOS
#11
L'audio funziona regolarmente, mai avuto problemi, in quanto al bluetooth l'ho disattivato perché non lo uso ma attivandolo funziona pure quello, in quanto ad avahi concordo con te sul fatto che non dovrebbe avere a che fare con l'avvio lento.

In realtà grub è installato perché se faccio esc il relativo menu mi appare, solo che a quel punto la tastiera non risponde e non posso entrare nelle opzioni avanzate e magari provare il boot con un kernel diverso...quindi anche per quello se premo esc non posso vedere nulla, la tastiera non risponde, ma posso cercare di riprovare non appena riparte il boot a fare esc, ma quei messaggi non vengono scritti da nessuna parte e si possono leggere solo a video durante il caricamento di UZ?
#12
Solo a video
#13
esiste dmesg che puoi dare da terminale una volta avviato uzl e da li fai un copia ed incolla delle info che ti da ed in alternativa puoi usare il comando sudo /var/log/boot.log ed anche sudo /var/log/kern.log ma con dmesg puoi vedere anche gli errori dell'ultimo boot.

Ad ogni modo nessuno ci segnala problematiche di questo tipo, hai verificato con qualche utility che invece non sia il tuo hard disk ad avere settori danneggiati?
#14
Non avendo nessuna idea di come un Mac fa il boot ho controllato sul web, https://www.makeuseof.com/tag/install-li...cbook-pro/
Qui viene consigliato di installare rEFInd, da capire se opera a monte o a valle di grub2. Mi spiego, se UZL fosse l'unico sistema GRUB non appare, non c'è motivo. Ma in dualboot con altri sistemi Linux o Windows è grub2 che si occupa di scegliere quale sistema avviare e per forza appare! Non occorre farlo apparire con esc.
Andando con un ragionamento così mi sembra più probabile che the culprit (il colpevole) sia allora rEFInd della lentezza nell'avvio lento a random. Io vedo moltissimi post riguardanti la lentezza di rEFInd, persino su archlinux dove gli users sono scafati e si ricompilano il kernel per il loro hardware per velocizzare il loro boot.
In un post lamentano anche un problema di avvio del bluetooth, non ti suona una campanellina? Il mio consiglio è di chiedere assistenza al manutentore di rEFInd, trattasi di programma terzo alieno a UZL
Qui un paio di link https://forum.ubuntu-it.org/viewtopic.php?t=655008
https://www.reddit.com/r/archlinux/comme...art/?tl=it
#15
(10-01-2024, 07:43 AM)julian.delvecchio Wrote: esiste dmesg che puoi dare da terminale una volta avviato uzl e da li fai un copia ed incolla delle info che ti da ed in alternativa puoi usare il comando sudo /var/log/boot.log ed anche sudo /var/log/kern.log ma con dmesg puoi vedere anche gli errori dell'ultimo boot.

Ad ogni modo nessuno ci segnala problematiche di questo tipo, hai verificato con qualche utility che invece non sia il tuo hard disk ad avere settori danneggiati?

DMESG:

Code:
[  817.598608] [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:78:90:a2:0c:02:e3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x60 TTL=1 ID=43070 DF PROTO=2
[  942.621740] [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:78:90:a2:0c:02:e3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x60 TTL=1 ID=44460 DF PROTO=2
[ 1067.634876] [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:78:90:a2:0c:02:e3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x60 TTL=1 ID=47534 DF PROTO=2
[ 1192.646678] [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:78:90:a2:0c:02:e3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x60 TTL=1 ID=59318 DF PROTO=2
[ 1317.669129] [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:78:90:a2:0c:02:e3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x60 TTL=1 ID=59381 DF PROTO=2
[ 1365.253789] perf: interrupt took too long (5147 > 4905), lowering kernel.perf_event_max_sample_rate to 38750
[ 1442.681820] [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:78:90:a2:0c:02:e3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x60 TTL=1 ID=1634 DF PROTO=2
[ 1567.704919] [UFW BLOCK] IN=enp0s10 OUT= MAC=01:00:5e:00:00:01:78:90:a2:0c:02:e3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x60 TTL=1 ID=7784 DF PROTO=2
imac@imac-iMac:~$

I due comandi sudo mi dice comando non trovato, forse è sbagliata la sintassi? Riguardo ai controlli sul disco, quale utility mi consigli di usare? Oggi il Mac è partito nuovamente in tempi normali, per cui magari l'output di dmesg non riporta nulla di strano

(10-01-2024, 11:40 AM)adrianomorselli Wrote: Non avendo nessuna idea di come un Mac fa il boot ho controllato sul web, https://www.makeuseof.com/tag/install-li...cbook-pro/
Qui viene consigliato di installare rEFInd, da capire se opera a monte o a valle di grub2. Mi spiego, se UZL fosse l'unico sistema GRUB non appare, non c'è motivo. Ma in dualboot con altri sistemi Linux o Windows è grub2 che si occupa di scegliere quale sistema avviare e per forza appare! Non occorre farlo apparire con esc.
Andando con un ragionamento così mi sembra più probabile che the culprit (il colpevole) sia allora rEFInd della lentezza nell'avvio lento a random. Io vedo moltissimi post riguardanti la lentezza di rEFInd, persino su archlinux dove gli users sono scafati e si ricompilano il kernel per il loro hardware per velocizzare il loro boot.
In un post lamentano anche un problema di avvio del bluetooth, non ti suona una campanellina? Il mio consiglio  è di chiedere assistenza al manutentore di rEFInd, trattasi di programma terzo alieno a UZL
Qui un paio di link https://forum.ubuntu-it.org/viewtopic.php?t=655008
https://www.reddit.com/r/archlinux/comme...art/?tl=it
Grazie, provo ad approfondire, però allora mi chiedo perché la lentezza in avvio non c'è stata subito dopo l'installazione di UZ ma solo a distanza di settimane? Oggi però, come ho scritto nel post precedente, il boot è stato regolare, questo iMac sembra davvero metereopatico

L'unica cosa che mi viene in mente e che ho realizzato ieri sera, consiste nel fatto che la prima volta che ho usato stacer ho fatto la pulizia del sistema senza spuntare, quindi lui ha fatto qualcosa ma di fatto non ha rimosso nulla, ieri me ne sono accorto e ho fatto la pulizia mettendo la spunta, oggi accendo il Mac e parte normalmente, magari era quello il problema, devo vedere se da oggi in poi si avvia sempre regolarmente
#16
Da perf: interrupt too long......non è problematico ma è un controllo di perf , ovvero quel job che macina e macina allungando il boot. Tieni monitorato ma porta pazienza se il boot ogni tanto rallenta. Non credo che la pulizia aiuti, in fin dei conti la cache serve. A questo punto potrebbe essere di tutto, anche il kernel. Puoi provare a fare il boot con un altro kernel, magari quello precedente? Da GRUB vai in opzioni avanzate
#17
Mi sono reso conto di aver postato solo una minima parte dell'output di dmesg, così ho fatto una nuova pulizia con stacer, poi ho riavviato il sistema, i tempi di caricamento mi sono sembrati inferiori e nella norma, comunque a sistema appena avviato ho dato nuovamente dmesg nel teminale e questo è il risultato, lo allego come file di testo perché postandolo direttamente supero la lunghezza massima del messaggio, spero si possa capire qualcosa analizzandolo Blush
.txt   DMESG.txt (Size: 88.59 KB / Downloads: 1)

(10-01-2024, 04:21 PM)adrianomorselli Wrote: Da perf: interrupt too long......non è problematico ma è un controllo di perf , ovvero quel job che macina e macina allungando il boot. Tieni monitorato ma porta pazienza se il boot ogni tanto rallenta. Non credo che la pulizia aiuti, in fin dei conti la cache serve. A questo punto potrebbe essere di tutto, anche il kernel. Puoi provare a fare il boot con un altro kernel, magari quello precedente? Da GRUB vai in opzioni avanzate

Se anche arrivo a grub mi si congela la tastiera, quindi non riesco a far nulla, comunque con il dmesg completo forse si riesce a capire qualcosa di più
#18
ciao, a parte una caterva di messaggi di questo tipo e820: reserve RAM buffer [mem 0xbe837000-0xbfffffff] ed il caricamento di fuse per le partizioni non sembra esserci nulla di anomalo, fatto sta che sicuramente utilizzi il boot di macos e li possiamo farci ben poco.
Sull'utility ci ho ragionato su e inutile consigliarne una esempio disks di mint che è su uzl poichè hai sempre il problema della lettura e mount della partizione che usi per il sistema operativo del mac.....
Ripetiamo che non si tratta di problemi per cui se riesci a risolvere con stacer bene ma se la questione della lentezza riguarda l'ecosistema macos e come gestisce il boot (probabile sia cosi) per via di
[ 0.038952] Faking a node at [mem 0x0000000000000000-0x000000023fffffff]
[ 0.104946] Booting paravirtualized kernel on bare hardware
e direi di si, allora non puoi fare altro che rimuovere la partizione macos ed installare uzl in modo pulito come unico sistema operativo se vuoi poter risolvere il problema.
Grub sarà pure installato ma viene in qualche modo tutto inibito dal tuo sistema operativo chiuso e primario.
Noi diamo assistenza per le problematiche uzl e non macos o alti software che si interpongono e che sono chiusi e di terze parti.
#19
Grazie per la precisazione, comunque se non altro nel boot di UZL non c'è nulla di anomalo, fatto sta che oggi sono già al quarto boot normale di fila, per cui stacer o non stacer, va comunque bene così Smile 

Aggiorno il titolo della discussione, grazie ancora per il supporto e per la pazienza Blush
#20
discussione chiusa


Forum Jump:


Users browsing this thread: 1 Guest(s)