Λοιπόν, λύση στο πρόβλημα βρέθηκε, αλλά το ανεβάζω εδώ για να γλιτώσει κάποιος άτυχος ένα ολόκληρο ξενύχτι που έριξα εγώ για να βρω την άκρη. (Και για να μου πείτε τι άλλο θα μπορούσα να κάνω για να γλιτώσω αυτές τις χαμένες ώρες). Για να έχει ενδιαφέρον το ανάγνωσμα, θα το κάνω και σε μορφή quiz με τη λύση στο τέλος, για να δείτε αν θα μπορέσετε να βρείτε το πρόβλημα.
Σύντομο ιστορικό: Όταν από 256GB SSD έκανα μετάβαση σε 512GB SSD, είχα κλωνοποιήσει το dual boot setup με mint 19/win 10. Τότε ο δίσκος ήταν MBR. Έγινε το update σε 19.1 και κάποια στιγμή αποφάσισα να αλλάξω σε UEFI/GPT. Έγινε μετατροπή των win 10 σε UEFI (σχετικά εύκολα) και επειδή στο Linux δεν βρήκα εύκολο τρόπο να κάνω το αντίστοιχο, απλά έσβησα το linux partition και εγκατέστησα ξανά το 19.1. (σημειώνω εδώ ότι τα win 10 υπάρχουν για λόγους συμβατότητας με κάποια εργασιακά project, αλλά στην πράξη δεν χρησιμοποιούνται καθόλου. Μια φορά στο 6μηνο μπαίνω μόνο για update). Λοιπόν μετά την εγκατάσταση του Mint 19.1 από ένα multiboot στικάκι, o grub εγκαταστάθηκε κανονικά, μπορούσα να μπω win, αλλά στο mint δεν έμπαινε και με πετούσε σε περιβάλλον initramfs. Σκέφτηκα ότι κάτι δεν θα είχε κάτσει καλά στην κλωνοποίηση ή στην μετατροπή του δίσκου σε UEFI/GPT, αλλά δεν ασχολήθηκα να ψάξω τι ήταν αυτό, καθώς με το boot-repair-disk φτιάχηκε εύκολα το πρόβλημα.
Το update σε 19.2 έγινε κανονικά και απροβλημάτιστα.
Η ζωή συνεχίστηκε μέχρι την έλευση του mint 19.3. Το update δεν ήθελε να με περάσει σε kernel 5, οπότε λέω “δε μαμιέται” πάω για καθαρό install. Τρέχω λοιπον το live mint 19.3 από multiboot στικάκι, εγκαθιστώ και πάω να μπουτάρω. Να σου πάλι το ίδιο πρόβλημα. Από το grub menu μπορούσα να μπω win 10, αλλά αν επέλεγα mint 19.3 με πετούσε σε initramfs, χωρίς κάποιο μήνυμα να καταλάβω τι παίζει. Δεν προβληματίστηκα καθώς το πρόβλημα το είχα ξαναδεί. Τρέχω λοιπόν πάλι boot-repair-disk και… αυτή τη φορά το πρόβλημα δεν λύθηκε. Ξανά έμπαινα σε περιβάλλον initramfs
Και κάπου εδώ άρχισαν να με ζώνουν τα φίδια. Τι δεν δοκίμασα. Ξανά εγκατάσταση με ξεχωριστό /boot, με ξεχωριστό /efi, με αυτόματη εγκατάσταση (alongside windows), boot-repair-disk με διάφορους συνδυασμούς επιλογών, δοκίμασω να ξαναστήσω το bcd μέσα από win recovery (δεν δούλεψε), μέσα από live περιβάλλον να εγκαταστήσω ξανά grub με chainroot, δοκίμασα να ακολουθήσω σχεδόν κάθε οδηγό που υπάρχει online. Σε όλα αυτά συνυπολογίζεται και ο χρόνο από αλλεπάλληλα restarts σε διάφορα recovery περιβάλλοντα. Δυστυχώς δεν είχα σκοπό να ποστάρω την εμπειρία μου και δεν κράτησα αναλυτικό log των προσπαθείών και των μηνυμάτων που έπαιρνα. Το μόνο που έχω κρατήσει είναι το paste bin από το boot-repair-disk σε κάποια από τις προσπάθειές μου:
https://paste.ubuntu.com/p/GVrgmSsZtF/
Σε κάποια από τις προσπάθειες να περάσω καρφωτά τον grub μέσα από περιβάλλον live linux, ένα μήνυμα αποτυχίας που έλαβα αναφερόταν σε αδυναμία εύρεσης MBR. Και τι σχέση έχει το MBR με την εγκατάστασή μου OEO?
Και κάπου εκεί μετά από ξενύχτι, μου ήρθε η φλασιά και η λύση:
Για κάποιο λόγο το live mint θεωρούσε ότι ο δίσκος ήταν MBR και έκανε ό,τι να ‘ναι εγκατάσταση, γι’ αυτό και στο pastebin αναφέρεται ότι δεν μπορεί να βρεθεί το core.img. Πιθανότατα έφταιξε ο loader του multiboot usb που χρησιμοποιούσα (http://multibootusb.org/). Αμέσως φορμάρω το multiboot usb και φτιάχνω στη θέση του ένα live mint usb. Προχωράω σε εγκατάσταση… restart… και ω θεοί του Linux, παίζει κανονικά!!! Problem solved, 6 ώρες πειραματισμών και αϋπνίας έμαθα να μην εμπιστεύομαι τα multiboot usb utilities…Ποτέ δεν θα μάθω βέβαια αν θα μπορούσα με κάποια “χακιά” να το φτιάξω, αλλά σε αυτή την περίπτωση δεν θα ανακάλυπτα και το πρόβλημα που υπάρχει με το multiboot usb. Εκτός και αν είναι πρόβλημα μόνο του mint installer κάτι τέτοιο και όχι γενικό. Δυστυχώς δεν έχω τον χρόνο, ούτε και την όρεξη προφανώς, να στήσω παρόμοιο σενάριο και με κάποια άλλη διανομή για να δούμε αν θα ξαναγίνονταν τα ίδια.