UEFI + grub delete

[j2k]

Εχω μια μητρικη asrock J1900M pro3 με uefi και εχω βαλει debian12 σε gpt ssd (/dev/sda1 - /boot/efi - efi partition ) (/dev/sda2 - / - root partition )

και οταν αλλαζω δισκο ή βγαζω τη μπαταρια της μητρικης σβηνετε το grub bootloader.

Μετα κανω rescue με grub-install /dev/sda και ξαναλειτουργει αλλα οταν ξαναλαξω δισκο παλι σβηνετε.

Αυτο το προβλημα εχω οπως και εδω το ιδιο

https://forums.linuxmint.com/viewtopic.php?t=401499

Τι συμβαινει γιατι η μητρικη το κανει αυτο ? ειναι bug ?

Επεξ/σία 29 Απριλίου από j2k

[mphxths]

Μην αλλαζεις δισκους σαν τα σωβρακα θα ηταν μια λυση  

[imitheos]

8 hours ago, j2k said:

Εχω μια μητρικη asrock J1900M pro3 με uefi και εχω βαλει debian12 σε gpt ssd (/dev/sda1 - /boot/efi - efi partition ) (/dev/sda2 - / - root partition )

και οταν αλλαζω δισκο ή βγαζω τη μπαταρια της μητρικης σβηνετε το grub bootloader.

Μετα κανω rescue με grub-install /dev/sda και ξαναλειτουργει αλλα οταν ξαναλαξω δισκο παλι σβηνετε.

Αυτο το προβλημα εχω οπως και εδω το ιδιο

https://forums.linuxmint.com/viewtopic.php?t=401499

Τι συμβαινει γιατι η μητρικη το κανει αυτο ? ειναι bug ?

Με κάποιες ανακρίβειες λόγω απλοποίησης, η διαδικασία είναι η εξής:

Το BIOS έβλεπε ποια κατάτμηση στον MBR είναι μαρκαρισμένη ως bootable και φόρτωνε τον 1ο τομέα της. Όταν λοιπόν έτρεχες grub-install ή το αντίστοιχο άλλου botoloader, το πρόγραμμα εγκαθιστούσε σε αυτόν τον 1ο τομέα ένα μέρος του bootloader. Ετσι λοιπόν, όποιον δίσκο και να έβαζες, αν είχε στημένο grub, θα φόρτωνε ο grub.

Στο UEFI η διαδικασία αυτή είναι πιο απλή με τον bootloader να είναι ένα απλό αρχείο με ό,τι όνομα θέλεις. Υπάρχει μια μαγκιά που λέγεται fallback / removable loader και το UEFI ξέρει να φορτώσει ένα συγκεκριμένο αρχείο από μία θέση. Αυτό όμως που γίνεται συνήθως είναι ο κάθε bootloader να εγκαθίσταται στη θέση του με το όνομά του (πχ /EFI/grub/grubx64.efi) και μετά με κάποιο πρόγραμμα όπως ο efibootmgr να ορίζεις μία καταχώρηση που να λέει στο UEFI φόρτωσε τον τάδε loader.

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0008,0001
Boot0000* ubuntu        HD(1,GPT,9ab61c6d-62f6-474f-99c4-64eae4e5b595,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)

Παραπάνω βλέπουμε ένα τέτοιο παράδειγμα καταχώρησης. Ο efibootmgr όρισε στο UEFI να φορτώνει τον \EFI\UBUNTU\shimx64 (πάλι ο grub θα φορτωθεί αλλά ορίζεται έτσι ώστε να παίζει το secureboot). Όταν εσύ έρχεσαι και αλλάζεις δίσκο, ο άλλος δίσκος δεν θα είναι ο 9ab61κτλ οπότε η καταχώρηση δεν λειτουργεί. Όταν αφαιρείς την μπαταρία, λογικά σβήνονται όλες οι επιλογές του UEFI (οπότε και αυτή η καταχώρηση) οπότε και πάλι δεν ξέρει τι να φορτώσει.

Μπορείς να αντιγράψεις τον bootloader με το fallback όνομα (πχ /EFI/boot/bootx64.efi) αλλά τότε θα έχεις άλλα θέματα. Απλά μη βγάζεις την μπαταρία.

[j2k]

Το secure boot το εχω απενεργοποιησει στο uefi.

Η εντολη efibootmgr -v δεν λειτουργει στο δικο μου.

Το να βαλω τον bootloader με fallback ονομα γιατι θα εχω αλλα προβληματα ?

Αυτο συμβαινει με τους ssd που εχουνε debian12 + grub αλλα δεν συμβαινει με

ενα usb flashaki που του εχω εγκσταστησει το Ventoy(φοβερο εργαλειο μεγαλη ευκολια) για να bootaro διαφορα isos με λειτουργικα ο bootloader του flasakiou δεν σβηνει ακομα και τη μπαταρια να βγαλω..

Παιζει να φταιει η λειτουργια CSM (compatibility mode) που εχει η asrock μητρικη για να μπορει να bootarei mbr δισκους?

Μηπως πρεπει να βαλω τον grub σε καποιο φλασακι ως fallback λυση?

Τελος παντων τι fallback λυση υπαρχει ωστε να λειτουργει ακομα και να χασει τις ρυθμισεις το uefi ?

Αυτο που θελω ειναι να παιζει οπως παλια με το mbr...

Αμα δε βαλω grub αλλα αλλο bootloader πχ efistub / refined / systemd-boot?

Υποτιθετε οτι ηρθε το uefi για να κανει τα πραματα καλυτερα αλλα εχει σοβαρες παιδικες ασθενειες απο οτι φαινετε..

Δε γινετε παντως να βασιστω στη μπαταρια της μητρικης γιατι μιλαμε για υπολογιστη βιομηχανικου μηχανηματος και θα κρεμασει ολο το μηχανημα.

Επεξ/σία 29 Απριλίου από j2k

[mphxths]

1 hour ago, j2k said:

Η εντολη efibootmgr -v δεν λειτουργει στο δικο μου.

Ειναι χαλασμενη ?  Τι εννοεις δεν λειτουργει ρε αδελφε ?
 

1 hour ago, j2k said:

δεν συμβαινει με

ενα usb flashaki που του εχω εγκσταστησει το Ventoy(φοβερο εργαλειο μεγαλη ευκολια) για να bootaro διαφορα isos με λειτουργικα ο bootloader του flasakiou δεν σβηνει ακομα και τη μπαταρια να βγαλω..

Ναι , γιατι το ventoy δεν γραφει κατι στο bios.
 

1 hour ago, j2k said:

Υποτιθετε οτι ηρθε το uefi για να κανει τα πραματα καλυτερα αλλα εχει σοβαρες παιδικες ασθενειες απο οτι φαινετε..

Mην βγαζεις συμπερασματα για πραγματα που δεν γνωριζεις.

Η λυση ειναι απλη. Μην βγαζεις τον δισκο ή την μπαταρια της μητρικης. Ο bootloader γραφει πραματα στο bios. Οπως το efi αρχειο και το id του δισκου (δες παραθεση ημιθεου). Aν κατι απο αυτα αλλαξει ή σβησει η εγγραφη στο bios ειναι λογικο οτι θα υπαρξει θεμα με το booting.
 

1 hour ago, j2k said:

Δε γινετε παντως να βασιστω στη μπαταρια της μητρικης γιατι μιλαμε για υπολογιστη βιομηχανικου μηχανηματος και θα κρεμασει ολο το μηχανημα.

Πληρωστε τεχνικη υποστηριξη  

[imitheos]

Για να αποκλείσουμε Χ-Υ πρόβλημα, τι προσπαθείς να επιτύχεις αλλάζοντας δίσκους και βγάζοντας την μπαταρία της μητρικής, μήπως μπορούμε να επιλύσουμε αυτό ώστε κατ' επέκταση να λυθεί και το θέμα με τον grub.

2 hours ago, j2k said:

Το secure boot το εχω απενεργοποιησει στο uefi.

Δεν έχει αυτό με αυτό που περιέγραψα αλλά ας μη πάμε εκεί και σε μπερδεύω με κάτι άσχετο.

2 hours ago, j2k said:

Η εντολη efibootmgr -v δεν λειτουργει στο δικο μου.

Πιθανώς να μην είναι εγκατεσημένο το πακέτο;

2 hours ago, j2k said:

Το να βαλω τον bootloader με fallback ονομα γιατι θα εχω αλλα προβληματα ?

Αυτο συμβαινει με τους ssd που εχουνε debian12 + grub αλλα δεν συμβαινει με

Αν η διανομή σου δεν έχει εγγενή υποστήριξη να σου εγκαθιστά τον loader σε removable / fallback θέση, και εσύ αντιγράψεις το αρχείο με το όνομα που πρέπει, ανάλογα με το πώς είναι χτισμένος ο loader, ίσως να πρέπει να αντιγραφούν και τα config του στη νέα θέση και με νέο όνομα. Κάθε φορά που θα αναβαθμίζεις ένα πακέτο στη διανομή, θα προσέχεις αν άλλαξε κάτι στο config ή στον loader και θα το ξανά-αντιγράφεις; Θα το κάνεις, θα παίξει τζάμι σήμερα και μετά από 1 -  2 - 5 μήνες, θα σταματήσει να εκκινεί λόγω κάποιας αλλαγής (και φυσικά θα γίνει _στην χειρότερη στιγμή_). Παρεμπιπτόντως, αν θυμάμαι καλά, το debian _έχει_ εγγενή λειτουργία να σου αντιγράφει το grub και σε fallback θέση οπότε θα τα κάνει όλα εκείνο αυτόματα χωρίς να έχεις θέματα. Και πάλι όμως προτείνω να λύσεις το πρόβλημα που σε οδηγεί να βγάζεις την μπαταρία αντί να βάλεις το τσιρώτο που είναι αυτό.

2 hours ago, j2k said:

ενα usb flashaki που του εχω εγκσταστησει το Ventoy(φοβερο εργαλειο μεγαλη ευκολια) για να bootaro διαφορα isos με λειτουργικα ο bootloader του flasakiou δεν σβηνει ακομα και τη μπαταρια να βγαλω..

Το ventoy, αν θυμάμαι καλά, εγκαθίσταται ως efi\boot\bootx64.efi (δηλαδή σε αυτή τη removable θέση που λέμε) για αυτό παίζει πάντα. Και αυτό το πάντα είναι σχετικό. Έχω δει εκδόσεις UEFI που δεν το υποστηρίζουν αυτό και ψάχνουν μόνο την θέση του windows loader (/efi/microsoft/boot/bootmgfw.efi).

2 hours ago, j2k said:

Αμα δε βαλω grub αλλα αλλο bootloader πχ efistub / refined / systemd-boot?

Για να εκτελεστεί ο refind / sd-boot από το UEFI ή θα πρέπει να τους ονομάσεις με κάποιο όνομα που να ξέρει να τους βρει (άρα fallback) ή τους ονομάζεις όπως θέλεις mitsos35.efi αλλά βάζεις καταχώρηση άρα δεν αλλάζει τίποτα.

2 hours ago, j2k said:

Υποτιθετε οτι ηρθε το uefi για να κανει τα πραματα καλυτερα αλλα εχει σοβαρες παιδικες ασθενειες απο οτι φαινετε..

Το UEFI μπορεί να είναι τέρας με το SPEC του να έχει 2K σελίδες αλλά στο συγκεκριμένο έχεις άδικο. Στο κομμάτι του booting ευκόλυνε πάρα πολύ την κατάσταση σε σχέση με πριν. Είναι τεράστια ευκολία να έχεις ένα απλό αρχείο το οποίο πετάς με ένα cp όπου θέλεις μέσα σε ένα FS, από το να έχεις MBR, stage1, stage1.5, stage2 μέρη του bootloader τα οποία να πρέπει να γραφούν σε συγκεκριμένους τομείς, θυσιάζοντας παράλληλα μια κατσίκα, για να λειτουργήσει. Και δεν είχαν όλα τα FS κενό χώρο στην αρχή της κατάτμησης για αυτό το πράγμα, με συνέπεια πολλοί χρήστες στο παρελθόν, προσπαθώντας να εγκαταστήσουν τον boot loader, να σβήνουν το superblock και να χάνουν όλα τα δεδομένα.

Όπως έγραψα πριν, εγώ προτείνω να μας πεις τι προσπαθείς να επιτύχεις σε αυτό το βιομηχανικό μηχάνημα για να δούμε κάποια καλύτερη λύση.

[dancer_69]

Εγώ πάντως που μέχρι πολύ πρόσφατα είχα μητρική με MBR με dual/triple boot, ποτέ δεν είχα πρόβλημα αναγνώρισης του bootloader με αλλαγές δίσκων ή επαναφορές BIOS. Το μόνο πρόβλημα που υπήρχε με την επαναφορά του BIOS ήταν η αλλαγή στη σειρά των δίσκων και έπρεπε να ρυθμιστεί και πάλι.

Τώρα που αναβάθμισα σε μητρική Asrock, αντιμετώπισα το ίδιο θέμα όταν λόγω προβλήματος στο δίσκο(είχε χαλαρώσει η σύνδεση του σάτα καλωδίου), έγινε ένα bootαρισμα και ο δίσκος δεν αναγνωρίστηκε. Αφού το διόρθωσα και έκανα επανεκκίνηση χάθηκε η καταχώρηση του grub και δεν μπορούσα να μπω στο linux πλέον. Ο windows bootloader, αν θυμάμαι καλά, λειτουργούσε όμως. Ισώς λοιπόν να είναι θέμα του linux? Πάντως κι εγώ περίμενα το UEFI να κάνει πιο εύκολη και ευέλικτη την εκκίνηση των λειτουργικών . Μπορεί να φταίει βέβαια και το γεγονός ότι δεν έχω καθόλου εμπειρία με το UEFI σε αντίθεση με το BIOS που είναι πολύχρονη, αλλά δε μου φαίνεται πρόοδος το γεγονός ότι πρέπει να εγκαθίσταται εκ' νέου ο bootloader κάθε φορά που θα χρειαστεί να γίνει κάποια αλλαγή δίσκου ή επαναφορά του BIOS. Ίσως βέβαια να χρειάζεται κάποια πρόσθετη ενέργεια στη ρύθμιση του bootloader αλλά όλα τα σχετικά με UEFI bootloaders και fallback αρχεία μου φαίνονται λίγο κινέζικα ακόμη.

[j2k]

εαν τρεξω efibootmgr απο το livedvd του debian παιζει οκ βγαζει εξοδο

αν το τρεξω απο το συστημα που ειναι στο δισκο βγαζει αυτο

# efibootmgr -v
EFI variables are not supported on this system.

Τα σεναρια του να βαζεις το δισκο και να παιζει οπως το συστημα με το mbr ειναι πολλα

πχ θελω να παρω το δισκο μαζι μου να του βαλω καποια πραματα-ρυθμισεις

και να τον κουμπωσω στο μηχανημα χωρις να ξαναγραφω τον grub.

Αν κατι κανουνε λαθος και χαλασουνε τις ρυθμισεις του μηχανηματος να υπαρχει ενας εφεδρικος

δισκος τον κουμπωνεις και ολα ειναι οκ.

Παθαινει κατι η μητρικη και θελει αλλαγμα την αλλαζεις απλα και συνεχιζει και λειτουργει...

Δεν εχει νοημα να πω ολες τις περιπτωσεις του γιατι πρεπει να παιζει αμα βγει η μπαταρια η αλλαξουνε

οι ρυθμισεις του uefi επειδη βγηκε ο δισκος κτλπ...

 

Τελος παντων δεν ειναι η λυση να μην βγαλω την μπαταρια μην αλλαξω δισκο κτλπ... αυτο ειναι παρακαμψη γιατι δε βρισκω λυση..

Τι μπορω να κανω ωστε να λειτουργησει οπως σαν να ειτανε με mbr και bios?

Το partition /boot/efi (fat) 512mb που φτιαχνει το debian στην αρχη του δισκου στην εγκατασταση τι ρολο παιζει

δεν μπορουνε αυτα να ειναι στο / (root) που ειναι και το /boot ?

 

Και σε εμενα η μητρικη asrock ειναι που εχει το θεμα.

Μηπως φταιει bug των μητρικων asrock απο τη λειτουργια CSM (compatibility mode) που εχουνε για να bootaroune δισκους με mbr ?

Update

Τελικα τη βρηκα τη λυση.. το προβλημα ειτανε στο οτι τρεχω real time kernel και

επρεπε να περασω efi=runtime στα boot params.

Την εδωσε την λυση καποιος στο stackexchange και δεν ειτανε προφανης..

Τωρα λειτουργει μια χαρα η εντολη efibootmgr.

Επεξ/σία 30 Απριλίου από j2k

[imitheos]

10 hours ago, dancer_69 said:

Τώρα που αναβάθμισα σε μητρική Asrock, αντιμετώπισα το ίδιο θέμα όταν λόγω προβλήματος στο δίσκο(είχε χαλαρώσει η σύνδεση του σάτα καλωδίου), έγινε ένα bootαρισμα και ο δίσκος δεν αναγνωρίστηκε. Αφού το διόρθωσα και έκανα επανεκκίνηση χάθηκε η καταχώρηση του grub και δεν μπορούσα να μπω στο linux πλέον. Ο windows bootloader, αν θυμάμαι καλά, λειτουργούσε όμως. Ισώς λοιπόν να είναι θέμα του linux.

Κάθε εταιρία έχει και δική της υλοποίηση, πολλές από τις οποίες μάλιστα σπάζουν το πρότυπο και δεν το υλοποιούν σωστά (άσχετο με το θέμα, δεν θυμάμαι ποιος dev είχε κάνει μια έρευνα και ένα 60-70% των usb συσκευών που δοκίμασε, παραβίαζαν το úsb πρότυπο για αυτό ήθελαν "ειδικούς" οδηγούς με quirks και χαζά). Βάλε σε αυτό και CSM και λοιπά και περιπλέκεται το θέμα.

Η δική μου Asrock (Z87 intel αν θυμάμαι καλά) πάντως ποτέ δεν είχε αυτό το πρόβλημα να χάσει κάποια καταχώρηση και έχω 3 δίσκους. Αυτός μάλιστα που έχει το κύριο λειτουργικό που γράφω τώρα, είναι SSD σε USB θήκη, οπότε μπορεί το σύστημα να εκκινηθεί χωρίς αυτόν κάποια φορά, και παρόλα αυτά ποτέ δεν είχα θέματα. Δεν ξέρω αν παίζει ρόλο ότι το CSM δεν το έχω ούτε auto, ούτε moto αλλά κατευθείαν κλειστό.

Επεξ/σία 30 Απριλίου από imitheos

[j2k]

Στο wiki του debian λεει αυτο

Could not read EFI vars under RT kernel

Due to high latency, EFI variable access is apparently disabled by default on RT kernel (see patch). You could enable things by passing kernel command line efi=runtime

 

Οποτε αμα ενεργοποιησω το kernel module για τα efivars θα εχω προβλημα στην αποδοση του real time kernel και αυτος ειναι ο λογος που δεν φορτωνουνε απο default το module αυτο γιατι ριχνει την αποδοση του preempt-rt kernel και επειδη με ενδιαφερει η αποδοση του δεν μπορω να το ενεργοποιησω γιατι μετα θα εχω πολυ σοβαροτερα προβληματα απο το uefi

Επεξ/σία 30 Απριλίου από j2k

[imitheos]

36 minutes ago, j2k said:

Στο wiki του debian λεει αυτο

Could not read EFI vars under RT kernel

Due to high latency, EFI variable access is apparently disabled by default on RT kernel (see patch). You could enable things by passing kernel command line efi=runtime

 

Οποτε αμα ενεργοποιησω το kernel module για τα efivars θα εχω προβλημα στην αποδοση του real time kernel και αυτος ειναι ο λογος που δεν φορτωνουνε απο default το module αυτο γιατι ριχνει την αποδοση του preempt-rt kernel και επειδη με ενδιαφερει η αποδοση του δεν μπορω να το ενεργοποιησω γιατι μετα θα εχω πολυ σοβαροτερα προβληματα απο το uefi

 

Το ότι η get_time του efi έχει 10ms latency, το οποίο είναι απαράδεκτο, το καταλαβαίνω. Όμως, με ανοιχτό το runtime, όλα τα υποσυστήματα του πυρήνα, χρησιμοποιούν αυτήν την get_time; Αυτό δεν καταλαβαίνω.

* Το noruntime ορίζεται στο αρχείο drivers/firmware/efi/efi.c και αυτό που κάνει είναι να θέτει τιμή true στην μεταβλητή disable_runtime. Αυτή είναι εσωτερική μεταβλητή την οποία μπορείς να προσπελάσεις μόνο μέσω της συνάρτησης efi_runtime_disabled του ίδιου αρχείου. Τα μόνα αρχεία που χρησιμοποιούν την συγκεκριμένη συνάρτηση είναι τα "arch/arm/xen/enlighten.c arch/loongarch/kernel/efi.c arch/x86/kernel/reboot.c arch/x86/platform/efi/efi.c arch/x86/platform/uv/bios_uv.c drivers/firmware/efi/arm-runtime.c drivers/firmware/efi/efi.c drivers/firmware/efi/riscv-runtime.c" τα οποία είτε αναφέρονται σε άλλες αρχιτεκτονικές ή δεν την χρησιμοποιούν με κάποιο τρόπο που να επηρρεάζει την επιλογή get_time ή κάποια άλλη κρίσιμη συνάρτηση.

* Πάμε στην get_time. Μπορείς να δεις τα αρχεία arch/x86/platform/efi/efi_64.c και drivers/firmware/efi/runtime-wrappers.c για τους διάφορους ορισμούς. Όλα τα υποσυστήματα βλέπω να χρησιμοποιούν διάφορους wrappers για την get_time (που θα παραξενευτώ αν καταλήγουν στην efi.get_time). Το μόνο που χρησιμοποιεί χύμα την efi.get_time ειναι το drivers/rtc/rtc-efi.c, όπως είναι αναμενόμενο, το οποίο όμως δεν υφίσταται καν για x86 αλλά μόνο για άλλες αρχιτεκτονικές. Όλες οι διανομές που ξέρω χρησιμοποιούν το rtc-cmos που είναι generic και πιάνει τα πάντα.

Disclaimer: Δεν είμαι kernel dev. Προφανώς οι kernel devs γνωρίζουν καλύτερα από εμένα το πράγμα. "Διέλευση ιδίαν ευθύνη" που είχε και μια γέφυρα στη πόλη μου. Πάντως από το λίγο που το έψαξα, δεν νομίζω ότι σε x86 αρχιτεκτονική θα έχεις θέματα να ενεργοποιήσεις το runtime (τώρα το αν λυθεί το θέμα με το σκληρό σου και τη μπαταρία είναι άλλο θέμα). Αυτή η άποψή μου ενισχύεται και από το γεγονός ότι ο σύνδεσμος για το patch που έδωσες αναφέρει ότι το πρόβλημα το ανακάλυψε το "SoftIron Overdrive 1000" το οποίο από ό,τι βλέπω είναι μια arm64 πλατφόρμα.

 

[dancer_69]

4 hours ago, imitheos said:

Κάθε εταιρία έχει και δική της υλοποίηση, πολλές από τις οποίες μάλιστα σπάζουν το πρότυπο και δεν το υλοποιούν σωστά (άσχετο με το θέμα, δεν θυμάμαι ποιος dev είχε κάνει μια έρευνα και ένα 60-70% των usb συσκευών που δοκίμασε, παραβίαζαν το úsb πρότυπο για αυτό ήθελαν "ειδικούς" οδηγούς με quirks και χαζά). Βάλε σε αυτό και CSM και λοιπά και περιπλέκεται το θέμα.

Η δική μου Asrock (Z87 intel αν θυμάμαι καλά) πάντως ποτέ δεν είχε αυτό το πρόβλημα να χάσει κάποια καταχώρηση και έχω 3 δίσκους. Αυτός μάλιστα που έχει το κύριο λειτουργικό που γράφω τώρα, είναι SSD σε USB θήκη, οπότε μπορεί το σύστημα να εκκινηθεί χωρίς αυτόν κάποια φορά, και παρόλα αυτά ποτέ δεν είχα θέματα. Δεν ξέρω αν παίζει ρόλο ότι το CSM δεν το έχω ούτε auto, ούτε moto αλλά κατευθείαν κλειστό.

Επειδή λόγω γενικού προβλήματος του δίσκου(έσπασε απ' το πουθενά το πλαστικό στη σύνδεση sata) αναγκάστικα κι εγώ να τον βάλω(προσωρινά) σε usb θήκη και τα βρήκε όλα κανονικά χωρίς πρόβλημα. Βέβαια έβαλά κι εγώ, αν και δεν έχω rt kernel, την παράμετρο που αναφέρθηκε, οπότε δεν ξέρω αν είναι λόγω αυτού.

Το CSM εμένα ήταν ενεργό εξ΄ορισμού. Δοκίμασα και με ανενεργό μιας και ανέφερε ότι θα είναι γρηγορότερη η εκκίνηση, αλλά δεν είδα κάποια διαφορά οπότε το ενεργοποίησα ξανά(auto δεν έχει), μιας και αν είναι ανενεργό υποστηρίζονται μόνο UEFI συσκευές.

Επεξ/σία 30 Απριλίου από dancer_69

[j2k]

Λοιπον δε βρηκα λυση ακομα αλλα ειδα οτι στο ventoy εχει μια λειτουργια browse που απο εκει παω στο EFI\BOOT\bootx64.efi

και ετσι bootarei και μετα μεσα απο το linux με την εντολη efibootmgr φτιαχνω την εγραφη στην nvram του uefi.

Για να παιζει ομως το efibootmgr πρεπει να εχει στα kernel boot args efi=runtime που δεν το θελω γιατι πιθανον να επηρεαζει το jitter του kernel(αυτο θα το δω με δοκιμη)

Το προβλημα ειναι οτι η μητρικη δεν ψαχνει στο removable media path (EFI\BOOT\bootx64.efi) σαν fallback αμα δεν εχει εγραφη στη nvram

ομως το ventoy και χωρις εγραφη στη nvram το κανει boot αρα εκει πρεπει να ψαξω τη λυση...

To flashaki με το ventoy φαινετε να ειναι με mbr και να εχει efi partition...

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* Debian 12	HD(1,GPT,eca74bff-bd36-4eb9-ac0c-e23fdc4a5967,0x800,0x100000)/File(EFI\debian\grubx64.efi)
Boot0001* UEFI: KingstonDataTraveler 3.00000	PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(2,0)/USB(3,0)/HD(2,MBR,0xa64e94a0,0x7368000,0x10000)..BO

# fdisk /dev/sdc

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdc: 57.73 GiB, 61991813632 bytes, 121077761 sectors
Disk model: DataTraveler 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa64e94a0

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdc1            2048 121012223 121010176 57.7G  7 HPFS/NTFS/exFAT
/dev/sdc2       121012224 121077759     65536   32M ef EFI (FAT-12/16/32)

# mount /dev/sdc2 /mnt/flashefi/
# ls /mnt/flashefi/
 EFI   ENROLL_THIS_KEY_IN_MOKMANAGER.cer   grub  'System Volume Information'   tool   ventoy
# ls /mnt/flashefi/EFI/
BOOT
# ls /mnt/flashefi/EFI/BOOT/
BOOTAA64.EFI  BOOTIA32.EFI  BOOTMIPS.EFI  BOOTX64.EFI  grub.efi  grubia32.efi  grubia32_real.efi  grubx64_real.efi  mmia32.efi	MokManager.efi

 

Επεξ/σία 30 Απριλίου από j2k

[Georgie2]

Μου έχει συμβεί κι εμένα να χαθεί ο bootloader τού Arch, σε dual boot σύστημα (με τα Windows να είναι το άλλο λειτουργικό), σε παλιά μητρική ASUS με UEFI, Αποσύνδεσα τούς δίσκους για κάποιο λόγο, και παρ' όλο που αυτός με τα λειτουργικά μπήκε στην ίδια θέση, πουθενά ο booloader. Έκανα επανεγκατάσταση τού grub, αλλά δεν το κοίταξα το θέμα, μέχρι σήμερα.

Με αναζήτηση στο google βρήκα ότι ορισμένες υλοποιήσεις μητρικών έχουν την κακή συνήθεια να σβήνουν απ' την NVRAM bootloaders που για κάποιο λόγο τούς θεωρούν άκυρους. Ένα παράδειγμα εδώ.

Μία λύση, που μάλιστα δίνεται και σε forum για Debian, φαίνεται πως είναι η προσθήκη τής παραμέτρου --removable, κατά την εγκατάσταση τού grub.

Σ.Σ.: Παραθέτω ό,τι διάβασα. Δεν το έχω δοκιμάσει, και μού φαίνεται να θέλει και αρκετή προσοχή για να γίνει σωστά.

Επεξ/σία 30 Απριλίου από Georgie2

[j2k]

Mα το θεμα οτι αυτη η asrock μητρικη δεν βλεπει καν το removable media path τον εχω βαλει το grub στο removable media path

 ls /boot/efi/EFI/BOOT/
BOOT  BOOT.CSV	bootx64.efi  drivers_x64  fbx64.efi  grubx64.efi  icons  keys  mmx64.efi

 

Επεξ/σία 30 Απριλίου από j2k