Cześć.
Co trzeba zrobić żeby móc uruchamiać na zmianę te dwa systemy?
Dodatkowo jak poradzić sobie z aktualizacjami tych systemów tak aby nie psuły programu rozruchowego?
W skrócie problem wygląda tak:
Skoro chcesz mieć oba systemy fizycznie i na dodatek z dwóch “różnych bajek” (oparty o Archa i niezależny).
Trzeba kombinować z wpisami w /etc/grub.d, aby update-grub (a właściwie
grub-mkconfig -o /boot/grub/grub.cfg) wyzwalany przy każdym uaktualnieniu np. jądra systemu, albo paczek związanych z grub itd. nie psuł wpisów w grub.cfg.
Aktualnie jeden system miesza w konfigach menu GRUB drugiego systemu.
Weź najpierw poczytaj trochę o GRUB’ie, abyś miał ogólny zarys jak to właściwie działa:
grub-2-konfiguracja-linuksowego-bootloadera
Rozwiązaniem jest utworzenie chainloaderów. W sieci znajdziesz dużo opisów (np. tu: https://www.linuxquestions.org/questions/linux-software-2/grub2-chainloading-multiple-distros-4175439731/), więc nie będę tu tego tematu poruszał. Jeżeli robisz chainload to pamiętaj o wyłączeniu osprober’a, żeby systemy samodzielnie nie zostawały wyszukiwane i dodawane do menu.
Druga sprawa. Jeżeli uparłeś się na dwie dystrybucje obok siebie to znacznie lepszy będzie rEFInd do tego celu niż GRUB. (tzn. nie będziesz miał problemów wynikających z aktualizacji na przyszłość)
http://www.rodsbooks.com/refind/linux.html (+masa innych dokumentacji w internecie)
Jeżeli tylko testujesz dystrybucje to zastanów się nad wirtualizacją np. VirtualBox.
Proponuję łatwiejsze rozwiązanie. Mianowicie instalacja pierwszego systemu i całkowite odinstalowanie z jego poziomu gruba, następnie instalacja drugiego systemu który będzie nim zarządzał.
@anon741072 żaden z w.w. systemów nie generuje mu poprawnego pliku grub.cfg umożliwiającego bootowanie zarówno pierwszego jak i drugiego systemu.
Można tak zrobić, ale trzeba w pliku 40_custom dodać własny (statyczny) wpis (menuentry) do bootowania drugiego systemu (tego, który nie posiada GRUB’a).
Chyba grub-customizer załatwiłby ten problem, o ile jest dostępny w jakiejś dystrybucji. Z tego co pamiętam sam wykrywa wszystkie zainstalowane systemy na dyskach i tworzy wpisy w menu, którymi można łatwo zarządzać z poziomu graficznego gui.
Okazało się że problem był już poruszony na anglojęzycznym forum manjaro. Link
W openSUSE w pliku konfiguracyjnym grub.cfg należało poprawić jedną linijkę.
W sekcji dotyczącej uruchamiania Manjaro:
menuentry 'Manjaro Linux…
…
…
…
linux /boot/vmlinuz-4.9-x86_64 root=UUID=xxxxxxxxxxxxxxxxxxxx rw quiet…
initrd /boot/intel-ucode.img
trzeba zamienić ostatnią linię na taką:
initrd /boot/intel-ucode.img /boot/initramfs-4.9-x86_64.img
Ważne żeby numer kernela (u mnie jest to aktualnie 4.9, pogrubiłem) zgadzał się z tym jaki jest linijkę wyżej.
To oczywiście tylko częściowe rozwiązanie problemu. Dla mnie wystarczające.
Sposób naprawy manjarowego bootloadera podany na wspomnianym na początku forum niestety u mnie nie zadziałał.
Edycja pliku grub.cfg też gładko nie poszła. Posłużyłem się konsolowym edytorem Vim. Inne edytory tekstowe miały problem z otwarciem tego pliku. Edycja jego uprawnień też jest jakoś zablokowana.
P.s. @Domker, @anon741072 dziękuję za zaangażowanie i wskazówki.
Celowo jest zablokowana! Skrypt generuje ten plik przy każdym uaktualnianiu kernela bądź gruba i przy jeszcze paru innych okazjach.
Twoje zmiany są wprowadzone tymczasowo i znikną jak tylko wykona się update-grub (grub-mkconfig -o /boot/grub/grub.cfg)
Aby wprowadzić zmiany permanentnie musisz wyedytować plik skryptu, a nie konfig.
Sam orzekłeś, że “żaden z w.w. systemów nie generuje mu poprawnego pliku grub.cfg”.
Więc to błąd systemowy.
Jeżeli potrafisz dojść co i w którym ze skryptów należy zmienić aby otrzymać poprawny plik grub.cfg to bardzo proszę.
Ja niestety tego nie potrafię.
Spakuj i zapodaj skrypt:
/etc/grub.d/10_linux
A także plik “grub.cfg”:
sudo cp /boot/grub/grub.cfg $HOME/ && sudo chown $USER:$USER $HOME/grub.cfg && sudo chmod 644 $HOME/grub.cfg
(powyższe polecenie skopiuje do katalogu home użytkownika plik “grub.cfg” i zmieni mu właściciela na użytkownika, a także prawa dostępu na “-rw-r–r--”
Zobaczę pod wirtualką, co jest nie tak.
Bardzo proszę.
Skrypty z Manjaro: Manjaro grub.zip (6,6 KB)
Skrypty z openSUSE: SUSE grub.zip (7,6 KB)
Tutaj dokładna ścieżka to /boot/grub2/grub.cfg a polecenie zakończyło się błędem:
chown: błędna grupa: „krab:krab” (krab to moja nazwa użytkownika)
Ale poradziłem sobie inaczej.
Konfig z openSUSE zawiera moje prowizoryczne modyfikacje tak jak to opisałem w poście wyżej, więc aktualnie uruchamia Manjaro (tylko przypominam).
Faktycznie Suse stosuje w ścieżce grub2, a nie grub jak Manjaro.
Również nazwa użytkownika nie równa się nazwie grupy tam.
Zrobiłem plik różnicowy pomiędzy skryptami 10_linux z Suse i Manjaro.
“Minusy” linie ze skryptu Suse nieobecne w skrypcie Manajro
“Plusy” to linie które ma w zamian lub dodatkowo skrypt Manjaro
(różnica często jest nieznacząca - subtelna)
10_linux-diff.txt (12,2 KB)
To tak poglądowo tylko. Możesz zmienić z TXT na DIFF rozszerzenie to zobaczysz sobie z pokolorowaną składnią różnice.
Zmodyfikowałem skrypt 10_linux od Suse.
Wprowadziłem następujące zmiany do linijek:
263 =>>
+ initramfs_manjaro="`echo "${basename}" | sed -e 's,vmlinuz,initramfs,g'`"
271
- (wywalona)
271,272 =>>
+ "initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}" \
+ "${initramfs_manjaro}.img" ; do
351 do 361 =>>
+
+ for i in "${initramfs_manjaro}-fallback.img" "initramfs-${version}-fallback.img" ; do
+ if test -e "${dirname}/${i}" ; then
+ initrd="${i}"
+ gettext_printf "Found initrd fallback image: %s\n" "${dirname}/${initrd}" >&2
+ linux_entry "${OS}" "${version}" fallback \
+ "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
+ break
+ fi
+ done
+
10_linux_suse.zip (4,4 KB)
Zrób kopię pliku 10_linux od Suse - najlepiej do katalogu domowego lub /opt.
Zrób kopię pliku grub.cfg od Suse (w podobny sposób co podawałem tylko bez zmiany praw dostępu i właściciela)
Rozpakuj 10_linux_suse.zip i nadaj mu takiego samego właściciela jak w oryginalnym pliku (root:root ??) Dla właściciela zapis i odczyt, grupa: tylko odczyt, inni: tylko odczyt, prawo do uruchomienia (+x) Następnie go podmień z oryginalnym 10_linux.
Wpisz:
sudo grub-mkconfig -o /boot/grub2/grub.cfg
lub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
(nie pamiętam, które było obecne w suse)
To powinno wygenerować nowy plik grub.cfg ze skryptu.
W grub.cfg powinny być naniesione teraz zmiany jakie robiłeś wcześniej ręcznie.
Zobacz następnie czy Manjaro startuje.
Jak coś nie śmiga to przywróć kopie grub.cfg i 10_linux i wsio.
Nic to nie dało. Porównałem nowo utworzony plik grub.cfg z poprzednim i jest dokładnie to co było.
Dla porządku tylko:
Po przeniesieniu 10_linux system sam zmienił mu uprawnienia na takie jakie podałeś. Nic nie musiałem zmieniać.
Update robi się oczywiście poleceniem: sudo grub2-mkconfig -o /boot/grub2/grub.cfg
2x sprawdziłem, ale dla pewności podaję jak wyglądają u mnie teraz te skrypty:
SUSE grub.zip (7,6 KB)
Wygląda na to, że odpowiedzialny za wpis Manjaro w GRUB u Ciebie jest “30_os-prober”.
### BEGIN /etc/grub.d/30_os-prober ###
Podeślij 30_os-prober z Manjaro i OpenSuse. Zobaczę jakie tam są różnice.
Jedyna różnica jaka może mieć wpływ, ale niekoniecznie to:
212 ==> LINITRD="echo ${LINUX} | cut -d ‘:’ -f 5 | tr ‘^’ ’ ’"
Co innego generowanie “grub.cfg” na systemie, który masz online, a co innego do systemu offline.
Być może skrypty znajdują pierwszy satysfakcjonujący obraz, czyli “/boot/intel-ucode.img” i wstawiają to do konfiguracji, nie szukając, czy jest obecny jeszcze jakiś oprócz pierwszego napotkanego. (czyli kluczowy /boot/initramfs-x.xx-x86_64.img)
Być może strzałem w dziesiątkę będzie odinstalowanie paczki “intel-ucode” pod Manjaro.
sudo pacman -R intel-ucode
I ponowne wygenerowanie “grub.cfg” pod OpenSuse.
Paczka “intel-ucode” uaktualnia mikrokod procesora Intel i jest potrzebna można powiedzieć jednorazowo, a bynajmniej nie jest niezbędna do poprawnej pracy systemu.
Przerobiłem “30_os-prober” od OpenSuse. Możesz też sprawdzić, czy jest jakaś zmiana po tym.
Oczywiście zabezpiecz wcześniej oryginalny plik i “grub.cfg”.
suse_30_os-prober.zip (3,4 KB)
Generalnie popytałem odnośnie GRUBa kilka osób to GRUB systemów Archopodobnych niekoniecznie musi współpracować np. z OpenSUSE i na odwrót. Powinno za to działać bootowanie dystrybucji z tej samej “rodziny” np. Debian, Ubuntu, Mint lub
Arch, Manjaro, Antergos lub Fedora, Red Hat, CentOS itd. itp.
klatu
Podaj wyniki komend z OpenSUSE:
rpm -qa --scripts grub2
i Manjaro:
cat /var/lib/pacman/local/grub*/install
Dodatkowo jak poradzić sobie z aktualizacjami tych systemów tak aby nie psuły programu rozruchowego?
Jak przekombinujecie z kolegą Domker to sami wszystko rozwalicie …
No cześć.
Tu z SUSE:
postinstall scriptlet (using /bin/sh):
/sbin/install-info /usr/share/info/grub-dev.info /usr/share/info/dir || :
/sbin/install-info /usr/share/info/grub2.info /usr/share/info/dir || :
preuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]; then
/sbin/install-info --delete /usr/share/info/grub-dev.info /usr/share/info/dir || :
/sbin/install-info --delete /usr/share/info/grub2.info /usr/share/info/dir || :
if [ -f /etc/sysconfig/bootloader ]; then
. /etc/sysconfig/bootloader
fi
if [ “x${LOADER_TYPE}” = “xgrub” ]; then
exec >/dev/null 2>&1
if [ -f /boot/grub/menu.lst ]; then
# Remove grub2 testing entry in menu.lst if has any
for i in /boot/grub2/core.img /boot/grub2/i386-pc/core.img; do
if /usr/bin/grep -l "^\s*kernel\s*.*$i" /boot/grub/menu.lst; then
/sbin/update-bootloader --remove --image "$i" || true
fi
done
fi
# Cleanup config, to not confuse some tools determining bootloader in use
rm -f /boot/grub2/grub.cfg
# Cleanup installed files
# Unless grub2 provides grub2-uninstall, we don't remove any file because
# we have no idea what's been installed. (And a blind remove is dangerous
# to remove user's or other package's file accidently ..)
fi
fi
A z Manjaro nie podam bo po wywaleniu intelowych mikrokodów Manjaro dostało “kernel panic” i już nie wstało.
Edit:
Przywróciłem już Manjaro do życia więc zapodaję:
infodir="usr/share/info"
filelist=(‘grub.info’ ‘grub-dev.info’)
post_install() {
if [ -f /etc/default/grub.pacsave ]; then
echo "Copying /etc/default/grub.pacsave to /etc/default/grub"
install -D -m0644 /etc/default/grub.pacsave /etc/default/grub
if [ -f /boot/grub/grub.cfg.pacsave ]; then
echo "Copying /boot/grub/grub.cfg.pacsave to /boot/grub/grub.cfg"
install -D -m0644 /boot/grub/grub.cfg.pacsave /boot/grub/grub.cfg
fi
fi
for file in ${filelist[@]}; do
install-info ${infodir}/${file}.gz ${infodir}/dir 2> /dev/null
done
}
post_upgrade() {
for file in ${filelist[@]}; do
install-info ${infodir}/${file}.gz ${infodir}/dir 2> /dev/null
done
}
pre_remove() {
for file in ${filelist[@]}; do
install-info --delete ${infodir}/${file} ${infodir}/dir 2> /dev/null
done
}
Jak przekombinujecie z kolegą Domker to sami wszystko rozwalicie …
My tylko próbujemy naprawić to co ktoś inny zepsuł.
@Domker To ja Ci opowiem lepszy kawał. Mam na innej patrycji drugi openSUSE zainstalowany (jeden na btrfs, drugi ext, zresztą nieistotne). Oba podczas update’u gruba siebie widzą ale w gotowym grub.cfg nie ma po drugim śladu.
Taka to “rodzina”.
Proponuję w MBR dysku twardego zainstalować Gruba z Manjaro.
I teraz tak. W pliku /etc/default/grub Manjaro dodaj / włącz opcję:
GRUB_DISABLE_OS_PROBER=true
W pliku /etc/grub.d/40_custom dodaj taką sekcję:
menuentry “OpenSUSE” {
insmod ext2
search --set=root --label ETYKIETA_ROOTA_OPENSUSE --hint hd0,msdosX
configfile /boot/grub2/grub.cfg
}
Zamiast identyfikacji przez --label może użyć opcji --fs-uuid. To jest ten sam pierwszy dysk twardy “0”, dopasuj tylko numery partycji. Grub2 liczy dyski od zera, partycje od 1. Zapisz zmiany i wygeneruj nowy grub.cfg:
W OpenSUSE plik /boot/grub2/grub.cfg będzie okresowo aktualizowany itd, i do niego bezprośrednio będzie odwoływał się Grub w Manjaro. Powinno działać.
W skryptach poinstalacyjnych pakietów nie widać akcji typu “grub-install /dev/sda”.
Sprawdź czy w OpenSUSE jest dostępny do instalacji Grub 0.97. Jego można zainstalować w VBR (MBR partycji) i nie będzie problemu z aktualizacją. Wszystko wykonuj przez Yast2.
Wygląda na to, że pakiet jest dostępny:
https://software.opensuse.org/package/grub .
Wtedy wpis w pliku 40_custom może wyglądać podobnie jak w tym poście (ustal numer partycji):
http://www.linuxquestions.org/questions/debian-26/how-to-create-chainloading-in-grub2-917118/#post4542050 .
Próbować zawsze warto, ale z głową.
Trudno coś rozwalić jeżeli robi się kopie zapasowe tego, co się modyfikuje.
Poza tym reinstalacja paczki grub w tym przypadku też przywróci domyślną konfigurację.
Na początku proponowałem chainload, ale czasami warto “pogrzebać” głębiej 
Tak btw. to najprostsze rozwiązania są najlepsze. czyli rEFInd zamiast GRUB’a i problem z głowy.
A no dostało, bo w “grub.cfg” pozostał wpis z “intel-ucode.img” w “initrd”. 
Z resztą dla pewności sprawdziłem przed chwilą i system wstaje normalnie tylko trzeba pamiętać o grub-mkconfig po usunięciu intel-ucode. 