[Megoldva] Grub (& kernel & initramfs) reinstall Fedora 36

Sziasztok! Gondom akadt a Fedora indulásával. Ez a hibaüzi: https://drive.google.com/file/d/1pNjIidRUAnUsUUzQBqgH0KrEN9rYn3Zi/view?usp=sharing

Grub reinstall kellene? Jól gondolom? 
Fedora Wiki ide vonatkozó része, UEFI-t illetően: https://drive.google.com/file/d/1uof3LbEaDzzid_-CspEIFsvrMJBGCEIm/view?usp=sharing
Eddigi Debian/Ubuntu/Arch ismereteim szerint. Ilyen esetben kell az aktuális rendszer Live ISO-ja, majd abban chroot és utána a megfelelő csatolások után. Grub reinstall.

Viszont itt csak két parancsot látok, ami kitöröl két .cfg fájlt két partíció két könyvtárából. Nem ír a fáma arról, hogy ezt Live rendszer alól, vagy helyreállítási konzolról vagy a Grub minimális környezetéből.
Aztán a csomagkezelővel reinstallálni a szükséges dolgokat.
Amit nem értek az ez: 

# dnf reinstall shim-* grub2-efi-* grub2-common

A shim-* és -efi-* kifejezések mit takarnak?
Ezek helyettesítenék a chroot folyamatot? 

Hozzászólások

A reinstall az chroot alól fog menni itt is - az érintett csomagok pre/post install scriptjei rakják helyre a grub-ot.

Az shim az uefi boot loader, a secure boothoz kell, a grub-efi a grubot vértezi fel az efi támogatással. Valószínűleg Neked elég az x64, nem feltétlen szükséges a 32 bites is.

Szerintem az efivars-ba helyesen került ez be, mert a Grub elindul. Ugyanakkor vagy a Grub, vagy a kernel nincs jól feltelepedve. Pendrive-ról rescue boot, 1-est válassz, ez felcsatol mindent, utána chroot /mnt/sysimage - fejből írom, de kiírja, mit kell tenned -, majd nézd meg, mi van ott, s mi nincs. Gondolom, grub2-install /dev/sda2, de azért ennek nézz utána lsblk és efféle parancsokkal, itt nem szabad eszetlenkedni. Hirtelenjében azt sem tudom, hol van a grub, de ha az EFI partíció sda1-en, akkor meglehet, hogy a /boot sda2. Én mindig külön teszem az EFI-t, /boot-ot, /-t, /home-ot, így nálam lehet egészen más, mint nálad. Layout-tól függ.

Az idézett csillagok életveszélyesek, mert a shell csak akkor adja át literálisként azt a csillagot, ha az adott alkönyvtárban nincs mire kifejteni a globbing kifejezést. Tehát helyesen a parancs:

dnf reinstall shim-\* grub2-efi-\* grub2-common

A vaktában parancsok kiadőgatása ritkán segít, értsd meg a problémát. Egy példa.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Derítsd ki, hol van a grub, annak dolgai. Az is kérdés a grub stage1, vagy mifene, hova kerül, de ennyire nem értek hozzá, ezt lehet, megoldja a shimx6h.efi. Ha jól értem, nem systemd-boot-ot használsz. Nekem az nem volt feléleszthető, ezért te is így jársz jobban szerintem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A GRUB szerintem is jól van telepítve, különben az sem indulna el. Inkább azt kéne nézni, hogy mit ír ki előtte, mert amit betett a kolléga screenshotot, az nem hibaüzenet, hanem egy szabványos minimal GRUB shell, de azt nem írja, hogy miért indult ez el.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Fedora doksi, grub2 prompt része szerint.
https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/

Be kellene tölteni 2 kernel modult. Nálam nincs LVM és XFS sem. Aztán kilistázni a lemezeket, partíciókat. Megkeresni a root partíciót és beállítani.
Most eddig jutottam:
https://drive.google.com/file/d/1pvOGcAlQTG3XC1sa1OrqC5l8iZjQjHCL/view?usp=sharing

Az is tiszta és világos, hogy meg kéne adni a vmlinuz és az initrd helyét, pontos nevét. Aztán indítani.

Itt ebben a minimal környezetben, hogyan tudom megnézni a két komponens pontos nevét?
Kell-e nekem a LVM és XFS kernel modul.

Én megpróbálnám az 5.17.7-tel is, és utána ha nem megy, akkor cd/pendrive boot, mount, chroot, hálózat csiholás és az elején írt csomagok újrarakása.

Illetve még egy kört megérhet a "linux ..." mögé egy "rescue" paramétert odarakni.

Mit akarsz? Ez már megy! Volt nekem is ilyen állapotom valaha, nem tudom már, hogyan élesztettem fel. Lehet, érdemes volna újra generáltatni vele az initrd-t a dracut paranccsal.

dracut --force

Persze a mostanit nevezd át pl. valami.orig névre, hogy meglegyen. Ha a selinuxot akarod rendbetenni, akkor ne tiltsd, azaz vagy selinux=1, vagy ne adj  meg semmit, és reboot előtt tedd ezt:

: >/.autorelabel

Elszüttyög majd vele egy darabig, 10-15 perc alatt meg szokott lenni. Ugye, abból a gyökérben lévő 0 hosszúságú file-ból tudja, hogy kell a relabeling, a végén letörli, s újra boot-ol majd.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

1-est ír a kernel paraméterek végére, s akkor elindul 1-es futási szinten. Az emlékeim szerint single user, root only, konzol. A másik, hogy rescue pendrive-ról, chroot-ol, majd onnan futtatja a dracut-ot. A filerendszer gyökerébe feltenni egy nulla hosszúságú file-t, az meg tényleg nem ellenfél, oda még chroot sem kell.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

a (hd0,gpt3)/boot/grub2-ben ott van a grub.cfg? akkor:

normal (hd0,gpt3)/boot/grub2/grub.cfg

Most elmegyek, gyorsan egy gondolat. Ha jól sejtem, nincs rootfs-ed, s ezért nincs /usr/bin-ed sem. Azod van, amit a dracut becsomagolt az initrd-be. Fogalmam sincs, abban mi van, de szerintem lehet custom initrd-t csinálni pendrive-ról boot-olva dracut-tal, természetesen chroot után.

Arra törekedj, hogy legyen rootfs-ed, illetve szerintem csinálj új initrd-t úgy, hogy előbb a jelenlegiről csinálj mentést. Lehet, hogy az initrd-d beteg. Azt gondolom, tudod, hogy az nitrd hardware specifikus, tehát ha más környezetből raktad át a HDD-t vagy SSD-t ebbe a képbe, akkor azért nem megy, s ehhez a géphez kell generáltatni egy initrd-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ez még nem az OS rootja, hanem az initramfs, ezért nincs itt ilyesmi. kell az a néhány mount parancs fentröl + chroot, de networkhoz ez meg keves lehet. amit csinálnék chroot után, az grub2-install /dev/sda, dracut es lehet egy grub2-mkconfig -o /boo/grub2/grub.cfg

Valami van, de nem az igazi.
https://drive.google.com/file/d/1qoORmM6WmZgOzo_OH86IvoOVFCLyUyTe/view?usp=sharing

A chroot sikeres szerintem, mert ha exit-el kilépek belőle és vissza chroot-olok. A kurzor fel-le billentyűkre csak azokat a parancsokat kapom vissza mindkét környezetben, amiket előtte kiadtam.
Milyen plusz opciókat kéne még adni a grub2-install parancsnak? Fedora docs sem említ többet.

Lehívtam a --help-et, de hogyan görgetek vissza ebben a konzolban? Sajnos nem ismerem.

Belepistultam a live-chroot-ba, nem akar összejönni. Konkrét leírást nem találtam f36-hoz. Régebbiek vannak, de mind eltérően csinálja. Próbáltam értelmezni, össze ollózni. Hagyom most egy kicsit.

Ha tudtok linket f36-hoz, azt szívesen veszem.
Köszi mindenkinek, aki eddig segített.

Holnap neki futok tiszta fejjel. Az is érdekes, hogy a live /mnt-be egyik leírás készít egy /sysimage könyvtárat majd abba csatolja a /dev/sda3-at. Viszont ugyan ide az efi partíciót is /mnt/sysimage/boot/efi alá. Ilyen két könyvtár nincs is a /mnt/sysimage-ben.
Aztán van aki sudo su-val kezd a live-ban. Chroot előtt van aki csatolja a /run-t is. Mindegyik leírás csatol egy /dev/mapper/fedora_localhost--live-root könyvtárat is különféle helyekre. Vagy közvetlen a /mnt-be, vagy közvetlen a /mnt/sysimage-be.

Az lenne a lényeg chroot-nál, hogy a döglött rendszer gyökér és efi partíciójára végzünk műveletet a live rendszer rendszer könyvtáraival, eszközeivel. A chroot-ba kell mountolni a /dev /proc /sys és /run? könyvtárakat a liveból, hiszen ezek működnek.
Jól gondolom, tudom?

Mondjuk lehet bonyolítja a helyzetet, hogy nem default lvm-es Fedora-m van. Hanem csak sima root-ext4.

Elvileg chroot-ban nem kell ilyen /run /proc /sys mappákat csatolni. Csak a root, boot legyen felcsatolva, szokásosan /mnt-be, mindegy is, hogy relatíve hova, mert ahogy chroot-olsz bele, úgy / lesz belőle. Ugyanez a boot-tal. A GRUB-ot konfigold át, hogy megtalálja a root partíciót, a legjobb erre PARTUUID-t használni, bár azt nem tudom, hogy mi nálad konkrétan a felállás, van-e LVM, btrfs-kötet átnyúlva több meghajtón, egyéb bonyolító tényezők, mert akkor máshogy kell megadni.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Arch alatt nem kell. Gentoo alatt kell, de csak a komplett telepítéshez, ha később már telepített, eltört rendszert birizgálsz, meg csak bootloadert javítasz, akkor nem kell ilyen /sys és /proc. Elég csak annyit felcsatolni hogy a csomagkezelő működjön meg szerkeszteni tudj fájlokat.

Persze, fel is csatolhatod meg bind-elheted őket, kárt nem okozol vele, csak nettó felesleges lépés lehet adott esetben. A gondot nálad nem ennek a hiánya okozza, hanem hogy nem tudtad kideríteni, hogy pontosan hol van a root fs, melyik eszköz, melyik partíciója, vagy ha LVM, stb. kötet, akkor meg hogyan kell rá hivatkozni. Fedora keveréseit konkrétan nem ismerem, hogy default telepítésben mit hoz össze, azt tudom, hogy default btrfs, és van initramfs, de hogy LVM vagy valami más bonyolítás van-e, meg hogy a shim, stb. hogy szól bele, mit raknak az EFI és esetleg mit külön egy másik boot partícióra, stb., arra passz, Fedorát nem használok, néha csináltam róla próbatelepítést, de azok már nincsenek meg, és nem tört el bennük soha a bootolás, így nem néztem meg ezt a részét. Ezeket kéne tisztáznod most, hogy mi a kiépítése az egész rendszernek, milyen lemezeken, milyen partíciók, milyen megoldás, mit tesz a rendszer az EFI-re, stb., ezt világosan kell látni, topológiaszerűen, utána tudod lekérdezni az ennek alapul fekvő adatokat (blkid, lsblk, pvdisplay, stb. segítségével), amik utána kellenek a grub.cfg-be. Anélkül nem fog menni, mert nem találja a root-ot, amire adott esetben nem annyira egyértelmű hivatkozni, ha sok köztes rétegen kell hozzá átmenni.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

"Az lenne a lényeg chroot-nál, hogy a döglött rendszer gyökér és efi partíciójára végzünk műveletet a live rendszer rendszer könyvtáraival, eszközeivel." - Nem. a live eszközei addig és csak addig kellenek, amíg az éles root és egyebeket össze nem rakod egy /mnt/qtyafule könyvtár alá (plusz bind mount-olva a /proc, /dev, /sys, /run ), makd chroot /mnt/qtyafue /bin/bash - és onnantól kezdve (már a bash is) az eredeti OS-ből jön kvázi minden.
Onnantól kezdve ip vagy épp ifconfig és route parancs használatával csiholsz hálózatot (ha csak wifi van, akkor az pirinyót macerásabb), dnf vagy épp yum használatával csomagokat pakolsz fel/törölsz/kalapálsz ki, estébé.

"Mondjuk lehet bonyolítja a helyzetet, hogy nem default lvm-es Fedora-m van. Hanem csak sima root-ext4." - Nem bonyolítja - kimarad egy vgchange -ay amin_a_root_fs_van_vg, és a mount esetén kevesebbet kell gépelni (dev/sda3 a /dev/mapper/amin_a_root_fs_van_vg-satöbbi helyett).

Akkor feküdjön fel szépen erre az ágyra, hunyja le a szemét, a kezeit kulcsolja össze a mellkasán, és kezdjen beszélni a múltjáról! :) Hogyan került ez az operációs rendszer ebbe az állapotba? Mi történt?

Amit tennék:

- boot-olj be pendrive-ról rescue módban. Válaszd az 1-es menüpontot, ő a /mnt/sysimage alá csatolja a rootfs-edet, s azon belül a boot/efi alá azt az fs-t - vélhetően sda1 -, amelyen az EFI alkönyvtár is van

- ahogy javasolja is, csinálj egy chroot /mnt/sysimage parancsot. Ezek után adj ki egy

dnf check

parancsot. Ha visszatér 0 exit code-dal - echo $? -, akkor már lehet örülni, ha nem, akkor el fogja mesélni, milyen inkonzisztenciát talált az rpm adatbázisban, mely csomagok vannak csak félig feltelepítve, miegymás.

Hasznos, ha van midnight commandered, de el lehet lenni nélküle.

Nézd meg, hogy az aktuális kernel image és a hozzá tartozó initrd a chroot-olás után a /boot alatt van-e, vagy a $BOOT/MACHINE-ID/KERNEL-VERSION alatt, ahol a $BOOT a /boot, a MACHINE-ID egy hosszú hexadecimális szám, s egyébként a /etc/machine-id file-ban található ez a szám, a KERNEL-VERSION meg az uname -r parancs kimenete.

Ha a kernel image ez utóbbiban van, töröld le a /boot/`cat /etc/machine-id` alkönyvtárat a tartalmával együtt, de utána mondd neki mindenképp, hogy

dnf reinstall kernel\*

Én még mondanék neki egy

grub2-mkconfig -o /boot/grub2/grub.cfg

Ha ezekkel megvagy, nézd meg a lemezen a szabad helyet:

df -h

Utána sync, exit, exit, ekkor újra indul, s nézzük, mire mentünk az egésszel. Az első exit a chroot-ból lép ki, a második a shellből, de az rescue esetén reboot lesz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kezdem magam tök hülyének érezni. :-) Komolyan, de röhögöm is magam.
A live grubjában 3 opció van:
-f36 workstation start (nagyjából ez a rendes, default live boot),
-ugymint az előző csak előtte lecsekkolja a médiát,
-Troubleshouting (ez basic graphics mode-ban indítja a live boot-ot)

Arra gondoltam, hogy találok valahol egy rescue mód indítást, de neem. Akkor hogyan indítsuk a live-ot rescue módban? Itt kerestem először.
https://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-rescuemode-boot.html

Oké, annyit kisilabizáltam, hogy valamelyik rendszer indítási módban 'e' választásával a megfelelő helyre odatenni a rescue kapcsolót a linux sorába. Oda tettem itt is ott is, de csak grafikus módban indul. Nincs semmilyen 1-es opció meg semmi.

Most komolyan tényleg ennyire retardált vagyok, vagy a wiki-docs leírások köszönő viszonyban sincsenek a valósággal?
Azért is értetlenkedek, mert wiki alapján megugrok egy pure Arch installt, meg sok mindent megoldok docs-wiki olvasás alapján.
 

Csöpögtetett infókkal csak találgatni lehet - pláne úgy, hogy nem az látszik, hogy meg akarná érteni, hogy mi is történik, hogy is működik a  boot.

Ha van egy shellje (van), amiben össze lehet rakni a beteg OS-ből egy chroot-os környezetet, és működik a chroot is, akkor már csak netet kell csiholnia (ip, esetleg ifconfig meg route), a beteg/érintett csomagokat újrarakni, grub2-t újraküldeni a megfelelő blokkos eszközre, sync;sync;sync; exit exit, boot és kész.

Buguntun sikerült belerongyolni grub promptba - kb. 1 óra alatt ki lett reszelve.

Igen, ezt írom neki én is. Mindegy hogy csinálja, csak legyen felcsatolva a / és a /boot és így chrootoljon a felcsatolásba, és innen tudja javítani a GRUB-ot. Az mindegy, hogy live, vagy rescue mód, meg hogy a /sys, /proc, stb. fel van-e csatolva, azok max. extrák, amik ilyenkor nem szükségesek. Ami a kollégánál a gondot okozza, hogy nem látja át a rendszer boottopológiáját, és elveszett az erdőben. Mindegy, ezen egyszer mindenki átesik, végigszívja, mire megérti, hogy hogyan működik az UEFI boot, shim, GRUB, LVM, stb., onnantól már nem nehéz. Pont ez a haszna egy kézi, Wiki alapján történő Arch telepítésnek, hogy ezt már az ember az első telepítésekor kézzel végigszívja, de pont azért onnan egy életre megtanulja, megéri, és többi egyik disztrón sem fog neki gondot okozni, ha eltörik a bootloader, azonnal fogja tudni, hogy mit nézzen, hol javítson.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Írta hogyan csinálja. Most nem kötözködni akarok, én abba a részébe kapcsolódtam be, hogy annak ellenére, hogy nem úgy csináltad, ahogy ő írta, attól még mindig kivitelezhető lenne a te live módszereddel is, csak akkor a rendszer nem magától csatolja fel a partíciókat előre megadott helyre, hanem neked kell megtenni, és kézileg chrootolni. Semmivel nem nehezebb, alig néhány sor, utána már ugyanarról szól az egész, vonatkozó csomagok (grub és kernel) újratelepítése, GRUB újrakonfigolása (benne az általad kinézett adatok a root partícióhoz), és exit && exit && reboot.

Én úgy csinálnám, ahogy már írtam, hogy chrootolás után elkezdeném lekérdezni, hogy hol a root, lsblk-val, blkid-vel, pvdisplay parancsokkal, attól függ, hogy a Fedora mit hogy telepít, hol van a root, hogy kell rá hivatkozni (tipikusan fájlrendszer UUID-vel, vagy PARTUUID-vel, de LVM, LUKS, RAID, stb. bonyolíthat). Egyébként pont ez a baj nagyon felhasználóbarát, komplex, bloat, corporate disztróknál, hogy mindent agyonbonyolítanak a háttérben, hogy elfedjék a komplexitást, de ezzel pont, hogy komplexebbé teszik, ha valami hibát kell megoldani, és mikor már gondban vagy, nem fogod látni, hogy a giccsinstallerük mit hova tett, mit telepített, mit állított át, sokkal nagyobb munka mindent kinyomozni. Ezért nincs az Archnak és a Gentoo-nak installere, nem azért, hogy a userrel kitoljanak, meg gépelgethessen a hülyéje vég nélkül a tty-ba, terminálba, hanem hogy ne fedjék el a rendszer működését, és ha a felhasználó végigcsinálja a telepítést kézileg, akkor pontosan fogja tudni, hogy mit hova tett, mit állított, mivel ő maga csinálta, nincsenek meglepetések bekészítve. Meg ha ő telepíti a rendszert, akkor csak az a csomag, stb. lesz fent, ami tényleg kell neki, tényleg szüksége van rá, és nem döntik el helyette, hogy mi kell a rendszerbe.

Ezért ajánlom azt is, hogy most ezzel a grub-témával mindenképp küzdj meg, ne válaszd a könnyelmű, újratelepítem a rendszert kezdetű utat, mert akkor nem fogod megtanulni, hogy hogyan oldd meg ezeket a problémákat, és ha a jövőben is beüt egy ilyen gond, akkor se fogod tudni megoldani. Tudom, pain in the ass, de ez a tanulópénz, ezt nehogy azt hidd, hogy mi nem fizettük meg anno, akár én, akár locsemege vagy a többiek. Ezeken az alap tűzkeresztségeken, mint a grub helyreállítása, fstab eltolása, partíció létrehozása utáni első felcsatoláskor a jogosultságok hiánya, csomagkezelőben a függőségek eltolása tárolón kívül telepített csomagokkal, GPU driverrel küzdés, X.org-os eltolt konfig helyrehozása, hiányzó csomag vagy függőség keresése, fordítási problémák megoldása, rosszul paraméterezett dd-vel való véletlen felülírás, rosszul kiadott rm -r paranccsal való szerencsétlen törlés, stb., mindenki átesik, aki tényleg foglalkozott Linuxszal, és nem csak elméletileg, könyvből ismeri. Ezek ilyen minden disztrón klasszikusak voltak és lesznek.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Semmi baj, nem használtál Fedorát, én meg Fedora Core 1-től. :)

Letöltenivalók:

https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/36/Everythin…
https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/36/Everythin…

Ellenőrzöd:

sha256sum -c Fedora-Everything-36-1.5-x86_64-CHECKSUM

Bedugsz egy pendrive-ot, megnézed melyik eszköz, majd kiírod az image-et:

su -
<root jelszó>
lsblk
dd if=Fedora-Everything-netinst-x86_64-36-1.5.iso of=/dev/sde bs=1M; sync

A példában az sde a pendrive, ezt értelemszerűen tedd, és nagyon figyelj!

Bootolsz róla, lesz a Troubleshooting menü, abba bemész, azon belül Rescue mode. Konzolon indul, feltesz egy kérdést, hogy mindent mount-oljon rw, mount-oljon ro, vagy skip a mount-ra, s csak adjon shellt. Itt az 1 a helyes válasz, rw mount kell. Ott még kiírja a chroot /mnt/sysimage ötletét, van egy root shell promptot, tied a világ. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Na ez az amit nem találok az f36 telepítő iso-ból készített pendrájv bootolása után. Az utóbbi bejegyzésemben sem látom egyértelműnek a latest version rescue-ra vonatkozó útmutatását. A Troubleshooting menüben csak csökkentett grafikus módú indítás van. Nem találom azt sem, hogy hol választhatnám ki az inst.rescue módot vagy hová szerkesszem be. 

Ez gyakorlatilag mi? Amit linkeltél? Egy speciális Fedora javító iso vagy dev iso? 

Szerintem ahhoz, amit most csinálni szeretnél, nem. De ha mégis, akkor azt hiszem, nmcli-vel fog menni, de ne vacakolj a wifivel, mert megőszülsz, mire megcsinálod, s reboot után kezdheted az egészet elölről. Lehetőleg drótos neted legyen, ha egyáltalán kell bármilyen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nagyon eltűntél. Megjavult, feladtad, vagy most nincs időd rá?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vasárnap említetted egy válaszodban, hogy az initrd-is lehet ujra kell generálni. Igen ez egy másik gépről áthozott mentés.

Terveztem már régóta a Fedora-ra váltást, most éppen kapóra jött egy "feladat" is. Aztán nekifogtam. Újra húzni nagyon egyszerű lenne. Kernellel, grubbal, ilyen mélységű problémáim még nem voltak. Konzolban se sokat kellett matatni.

Ezért is ennyi a kérdés és a doksik naprakészsége is.

Na, ezzel már megyünk valamerre, de még mindig nem elég. Annyi máris lejön, hogy nincs LVM, meg RAID, hanem csak sima egyben partíció mindennek, root, home, stb., egyedül a boot van feltehetőleg külön az EFI partíción. Ami még kéne, az a blkid parancs, ami kiírja az egyes partíciókhoz a fájlrendszer UUID-t, és PARTUUID-t. Annyi nem elég, hogy /dev/sda3, mert az sda eszközelnevezés változhat, ha boot előtt csatolva felejtesz mondjuk egy külső lemezmeghajtót, pendrive-ot, mindenféleképpen valami UUID kéne (elvileg label-lel is megoldható, de azt most hagyjuk, nem fog jelen esetben segíteni), és azt kéne betenni a /boot/grub/grub.cfg-be, vagy ahol ez a file van, és ennek alapján újragenerálni grub-mkconfig-gal a tényleges GRUB konfigot. Biztonság kedvéért egy dnf reinstall kernel is lemehet, nem azért, mert a mostani kerneleddel valami baj lenne, hanem a kernelinstall után a csomagkezelő még lefuttat install scripteket, ami segíthet újraírni a vonatkozó GRUB bejegyzést, és helyre hozhatja a bootolást. Nem garantált, de egy próbát megér.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az sem elég, a (hd0, blabla) az csak addig kell a rendszernek, amíg a GRUB elindul. Viszont a GRUB által indított kernelnek paraméterként továbbra is kell, hogy a rootot, initrd/initramfs, vagy amit a Fedora default installban igényel, hogy azt a kernel hol keresse! Ahhoz nem lesz elég csupán a hd0 akármi, hanem UUID-vel szokott lenni megadva (initrd-nél és initramfs-nél, CPU microcode-nál, stb.-nél meg pontos fájlnév elérési úttal).

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

a ping megy, akkor a /etc/resolv.conf-ba ird be a dns servert, akár 8.8.8.8. és müködnek majd a repok.

(mount -o remount,rw csak initramfs-ben kell kb, mert ott ugyan a switchroot előtt már fel van már csatolva a /mnt/sysroot alá a root, de read-only módban. amikor te mountolod, akkor alapbol rw lesz)

Igen. De egyébként Fedorán is lehet statikus resolv.conf-ot használni emlékeim szerint, mintha olvastam volna doksiban. A mikéntjét fejből nem tudom. Amúgy nyakamat rá, hogy ha végre megcsinálná az initrd-t, elindulna a gépe, ahhoz meg nem kell hálózat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Már mindent ezerszer újra telepítettél, bár én még olyannal nem találkoztam, hogy egy csomagból kitömörített file hibásan került volna a háttértárra. Az egyedüli értelme a rekonfigurálás lehet. De már azt is megcsináltad többféleképpen. Egyfelől a kernel reinstall is futtatja a dracut-ot, s generál initrd-t. Nézd meg, működik-e, s ha nem, akkor ne favágó módon vagdalkozz, hanem a hibaüzenetek értelmezésével, a boot folyamat végiggondolásával próbáld kitalálni, mi lehet a probléma, s ennek megfelelően avatkozz be. (Boot folyamatról jut eszembe, nem rég implementáltam C-ben 32 bites MIPS architektúrára embedded mikrokontrolleres környezetben firmware upgrade-et biztosító boot loadert. :) )

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sikerült a netinstall iso-ból is bootolni a rescue módot. De a chroot és a csatolások nem úgy működtek ahogy említetted. Meg netet is kellet volna csiholni a dróthoz, de azt most inkább elteszem későbbre.
Megpróbáltam sima live-on chroot-olni, úgy gondolom sikerült. Összeollóztam a javaslataitokból, látható a prompt változásból a chroot parancs kiadása után.
Viszont most úgy gondolom, hogy a csomagkezelővel van valami. A repo lista valós, igen azokat én adtam hozzá még mentés előtt a másik hardveren. Ezt kéne rendbe tenni szerintem, aztán a folytatás.

Ha láttok valami okosságot a pastebin bejegyzés alapján, ne kíméljetek. Kezd összeállni a kép a fejemben. Egyre jobb találatokat kapok a Fedora docs-hoz is. Szorgalmasan olvasom.

Még egy kérdés a végére. A /run tényleg nem fontos a chroot-hoz?

Néztem, miket írtál. Nem figyelsz rám eléggé. Nem azt írtam, hogy dnf check update, csak azt, hogy dnf check. Update nélkül. Ezért dobott neked hibaüzenetet.

A másik, hogy az elmondottak alapján az initrd-d kehes. Csinálj, kérlek egy initrd-t, de ha frissebb kernelt teszel fel, akkor megcsinálja saját maga.

A /run-ra nem tudom a pontos választ. Ha van türelmed, bind mounttal csatold fel chroot előtt az új rootfs run-ja alá a /run-t, abból baj nem lehet, hasonlóképpen a /proc, /sys, aztán mehet a chroot. Az initrd-t a chroot-olt környezetben csináld, de szerintem chroot nélkül is meg tudja csinálni, mert emlékeim szerint a dracut paramétereként megadható kernel verzió is, nem csak a futó kernelhez tud initrd-t csinálni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ellenben - nem néztem meg -, nem kizárt, hogy a bind mount-okat a rescue megcsinálja. Számomra ez logikus lépés lenne. Egyrészt kényelmessé tenné az életet, másrészt csak a chroot /mnt/sysimage parancsot ajánlja a rövid helpben, amelyet ott kiír. Meg kellene nézni, de semmi kedvem rescue live-ot boot-olni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezért írtam, hogy jöhetnek elő mágikus hibák, ha pl. rendszert telepítesz, vagy chrootolt rendszert használsz huzamosabban (értsd: chrootban használod a rendszert egész nap). De ha már meglévő rendszeren csak annyit csinálsz, hogy kernel, grub, stb. csomagját telepíted újra (ahhoz pl. hogy a kernelimage rákerüljön a boot partícióra/kötetre, meg hogy újragenerálódjon az initrd, initramfs, stb.), meg csak egy grubot konfigolsz újra, ahhoz nem kell mindenféle /dev, /proc, /sys bind. Meg lehet épp csinálni a biztonság kedvéért, ártani nem árt, de a kolléga esetében nem ez a gond.

Egyébként meg gyakorlatból mondom, hogy ez az elvileg kell sem áll meg, mert pl. a systemd ilyen tekintetben is gondoskodik sok mindenről saját maga, nem igényel annyi bindet egyébként sem, mint egy másik, egyszerűbb initrendszer. Már pedig a Fedora is systemd-s. Ilyen /proc, /sys bindenek inkább akkor kell rugózni, akkor szokott jobban kelleni, ha nem systemd-s rendszerbe chrootolsz.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Szerkesztve: 2022. 05. 26., cs – 19:05

Van annak érdemileg nagy jelentősége, hogy sudo su-val vagy su-val váltok root-ra live rendszeren? Mindkettőnél a whoami kimenet root.

Vagy esetleg végig sudo-val csinálnám a folyamatot?

Te most viccelsz? Ez kb. olyan kérdés volt, mintha afelől érdeklődtél volna, ha rossz a RAM, s a kiírt adat helyett valami véletlen szám kerül viszaolvasásra ugyanarról a címről, az okozhat-e rendellenes működést. Igen, okozhat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sikerült!
Uraim! Mindenki a vendégem egy körre vagy kettőre.
Gyanús volt, hogy a grub2-mkconfig után nem volt semmilyen foud vagy Fedora bejegyzés, ami megjelenne a grub menüben.
Itt olvasgattam kicsit és ránéztem az én rendszeremben is.
https://linuxhint.com/grub2_mkconfig_tutorial/

Megpróbáltam e szerint kiadni a parancsot, persze már csak ezt a chroot-ban. Mivel a többi elvileg sikeres volt. Kezdtem örülni a found Fedora 36 Workstation bejegyzésnek.

Reboot és aztán mosoly.

Hálás köszönet mindenkinek.

Eddig erre az útvonalra volt kiadva:/boot/grub2/grub.cfg
Most megpróbáltam így:               /boot /efi/EFI/fedora/grub.cfg
A linkelt oldalon a srác a végefelé a CentOS-es résznél írja.
https://linuxhint.com/grub2_mkconfig_tutorial/

A szétesett fájlrendszer meg végső ötlet volt, hogy fsck-val támadni esetleg.

Ez eléggé triviális és banánhéj volt. Nekem egyébként mindkét elérési úton van grub.cfg-m, ráadásul eltérő tartalommal, s fogalmam sincs, melyiket használja. Nem érte el az ingerküszöbömet, amíg elindul a gép.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Örülök, hogy sikerült. Ez dupla sikerélmény, mert nem csak hogy most oldottad meg, hanem ha a jövőben ilyen gondod lesz akármilyen systemd+EFI+GRUB-os disztrón, most már csukott szemmel tudni fogod, hogy hogyan kell helyrehozni.

fsck-val még nekimehetsz, ahhoz még chroot se kell, de lehet csak következő bootoláskor fog lefutni. Egy próbát megér, hogy ez a része is rendben legyen, annak ellenére, hogy szerintem ez nem lesz gond nálad, mármint a fájlrendszer konzisztenciája. Ha inkonzisztenciát érzékel felcsatoláskor a rendszer a boot során, automatán triggerelődik egy fsck is, meg minden x. bootkor is lefuthat egy.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)