[MEGOLDVA] Javító telepítés

Debian GNU/Linux

Van egy Debian VM, ami bootoláskor meghal ismeretlen probléma miatt. Nem tudni mi történt, de tippre valamilyen rendszere file, vagy mappa vagy ezekből több is sérülhetett. Esetleg van arra mód, hogy egy alap Debian-t rátelepíteni a meglévőre, hogy a rendszerfileokat újra rakja, de a configok megmaradjanak? Kvázi egy frissítő telepítés lenne. A teljes újrahúzás lenne az utolsó megoldás, mert az elég hosszadalmas lenne az egészet beállítani.

  • 1194 megtekintés

( bennyh | 2023. 06. 28., sze – 09:17 )

Szerkesztve: 2023. 06. 28., sze – 09:17

Az nem opció, hogy becsatolni a VM képet és átmásolni a config könyvtárakat egy friss szűz Debian példányba? Ez talán jobban kivitelezhető, mint Windows alatt. Laikusként azt gondolnám, pl az etc-ből ki lehetne mazsolázni, ami kell.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( x-daemon | 2023. 06. 28., sze – 09:35 )

felcsatolod valahova

a felcsatolt /var/lib/dpkg tartalmazza hogy mi van telepitve, innen kilistazod a telepitett csomagokat

letoltod a csomagokat

dpkg-val kicsomagolod a csomagokat a felcsatolt helyre

neked aztan fura humorod van...

( pe2hu | 2023. 06. 28., sze – 10:18 )

Nem rendszer frissítés után nem indul? Egy korábbi kernellel nem boot-ol be a rendszer?

Abba futottam bele múltkor, hogy új kernel csomag telepítése közben betelt a root fájlrendszer és a telepítő elbaszta az initramfs fájlt, de természetesen a boot könyvtárba bemásolta a hibás fájlt és a grub menübe felvette az új kernel-hez tartozó bejegyzést mint alapértelmezettet.

Az elmúlt 3 napban csak a bind9-es rendszerfrissítés volt, de azután már volt boot. Most felhúzok mellé egy új linuxot, és megpróbálom felcsatolni mellé a régit, és rsync-el áthúzni a teljes rendszert a régiről az újra, kivéve persze a dev proc sys tmp run meg ilyen maapákat, azaz újról marad meg. Ha bejön, akkor örülök, ha nem, akkor újraépítem az egész szervert, és el van baszva az egész napom.

( shyciii | 2023. 06. 28., sze – 10:29 )

Mivel nem tudom mi történhetet, így nem tudom, hogy gyorsabb lenne-e. Az biztos hogy frissítés nem tehette tönkre. fsck-t a debian telepítőről futattva nem talált winyó sérülést. Szerintem rendszerfileok, mappák törlődhettek vagy mi lehet. Ezért gondoltam a rátelepítést, de azt nem lehet ahogy nézem. Rsync-el ez kiküszöbölhető lenne, így ezért gondoltam hogy ezt megpróbálom.

Mit ersz, egy friss telepitesu /etc es /var -val? Marmint, azt mondod, hogy nem akarod ujrarakni, mert minden beallitast ujra be kell allitani. Ha pont ezt a kettot visszamasolod egy ures rendszerbol, akkor miert lesz egyszerubb, mint a teljesen ures rendszer? Hiszen, mindent be kell allitgatni ujra, plussz a /var alatt levo tobbi dolog, igy meg sem lesz.

( zrubi v | 2023. 06. 28., sze – 10:34 )

Szerkesztve: 2023. 06. 28., sze – 10:35

röviden: nem nincs olyan amit keresel. - de értelme sincs.

 

bővebben:

Ez nem vindóz, itt nincs semmi magic, amit csak egy újratelepítés old meg...

Ha a kernel bootolás közben hal meg, esetleg panik-kal, akkor máris erősen leszűkítetted a problémakört, és szinte biztos, hogy kizárhatod a "rendszerfájlok" hibáit - bármit is értesz ez alatt.

 

Ha kernel panik-kal végződik a boot, akkor egy telepítő/rescue CD-vel (konkrétan annak kernelével) várhatóan bootolható a rendszered, és megkeresheted/megjavíthatod a problémát...

Hogy mi a probléma, ahhoz persze nem adtál elég infót - így ebben segíteni senki sem tud neked.

kellene minimum a screen dump amit látsz.

zrubi.hu

( locsemege v | 2023. 06. 28., sze – 10:42 )

Szerkesztve: 2023. 06. 28., sze – 10:44

Debianban nem vagyok otthon, de Fedorán csináltam már eredményesen igen vakmerő dolgokat, így aztán belekotyogok.

Azt írod, nem boot-ol be, lehal kernelpánikkal. Ez nem úgy tűnik, mintha rendszerfile-ok sérültek volna, mert odáig el sem jut. Ez a kernel, initramfs, grub - vagy ami a bootmanager -, boot paraméterek, fstab, systemd környéke lehet elsődlegesen. Ne vandálkodd szét az operációs rendszert a file-ok felülírásával!

Boot-olnék egy másik Debiant, felcsatolnám ezt a VM-et, aztán chroot, majd dracut --force akármi, illetve nem tudom, Debian hogyan csinál initrd-t. Az sem baj, ha a kernel panic hibaüzenetét elolvasod, hogy mégis mi a fene baja van. A nem boot-ol az érthető, de miért nem. Megnézném azt is, hogy az fstab bejegyzései helyesek-e. UUID-dal legjobb hivatkozni. Hasonlóképpen a bootmanager konfigjában a kernelparaméterek között a felcsatolandó rootfs megfelelő hivatkozással szerepeljen. Ha nem, ki kell javítani.

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

( shyciii | 2023. 06. 28., sze – 11:11 )

Szerkesztve: 2023. 06. 28., sze – 11:14

Nah feltettem mellé egy másik Debian-t (Proxmox VM). Felmountoltam a hibás winyót, és azt látom, hogy pl hiányzik a bin mappa (illetve a linkje a user/bin-hez), home mappa, lib, lib32, lib64 linkjei a /usr/libekhez, szal olyan mintha valamelyik rednszergazda véletlenül beletörölt volna.

Dev mappa tartalma is igen gyér.

initrd.img -t sem látom a gyökérben

Igen, de azokat az udev és környéke rakja oda futás közben, a /dev szinte biztosan nem is egy "igazi" filerendszer.

Egyébként bár a jó ég tudja mit csináltál de valószínűleg egy dpkg --get-selections, utána meg egy apt install --reinstall a csomagok gondolkozás nélküli újrapakolásán valószínű segít.

"Viszont a sokáig tart mindent újra beállítani"-n gondolkodj el, kéne legyen olyan backup, amiből nem, vagy olyan eljárás, ami tudja reprodukálni az állapotot.

Csinálj symlinket /bin névvel a /usr/bin-re. Bár, ha a /home is hiányzik, itt valami nagy baj van. Netről elérhető volt? Nem lehet, hogy felnyomták ezt a gépet? Ha ennyire vacak állapotban van, akkor viszont lehet, hogy tiszta telepítés kellene, de nagyon tiszta új image létrehozásától, partícionálástól, formázástól kezdve, aztán mentésből megcsinálni a konfigot.

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

( shyciii | 2023. 06. 28., sze – 12:07 )

nem lehet chroot-olni. Ahogy kiadom a chroot /mnt /bin/bash -t rögtön kiírja hogy no such or directory. Gondolom hiányzik neki a library-k linkjei a gyökérből, mert maga a könyvtár megvan

Ahogy írtad, nagyon szét van esve, ezzel valami nagy baj történt. A /dev nyilván üres, vagy majdnem üres, azt az udev röptében álmodja be, akkor jön létre az eszközfile, amikor például bedugsz egy pendrive-ot. Ez tehát normális. Az viszont nem, ha baj van a /etc-vel, hiányzik a /bin, de még symlinkként sincs jelen a /usr/bin-re.

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

A chroot úgy működik, hogy előbb megcsinálja a chroot-ot, majd a már chroot-olt környezetben futtatja a programot, amit megadtál neki - vagy ha ezt nem tetted, akkor a shell-t.
De mindenképpen chroot-on belül - ahol viszont a /bin/bash a /bin mappa hiányában nyomokban sem található. Nem is sikerül elindítania...

( shyciii | 2023. 06. 28., sze – 12:43 )

Nah úgy néz ki, hogy egyik segéd rendszergazda a saját notijra felmountolta a root könyvtárát, és véletlenül rm -rf -et nyomott arra a könyvtárra ahova mountolta root joggal...

Szal erről ennyit. Megy fel az egész újra.

vi-t amúgy sem kell megtanulni, van SUDO_EDITOR és EDITOR nevű környezeti változó, meg van például nano vagy mcedit. ;) Én mc-ből szoktam shell linkkel másolni, ami tulajdonképpen egy ssh tunneling.

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

( shyciii | 2023. 06. 28., sze – 13:09 )

Kösz srácok a segítséget! és bocs, hogy felesleges volt az egész, mert teljesen el lett kurva.

( shyciii | 2023. 06. 28., sze – 17:50 )

No helyreállítottam a szervert. Minden szolgáltatás, adat elérhető (email, web, admin panelek mysql lófaszom is). backup is megy róla, icinga is. Teszteltem is külön-külön mindent bizbaszt. Szal akkor ennyi.

Köszönöm mindenkinek a segítő, és vicces hózzászólást is :)