Fórum Root.cz
Hlavní témata => Software => Téma založeno: Peter Fodrek 27. 05. 2021, 16:01:41
-
Vážené kolegyne, vážení kolegovia!
Stala sa mi podivná vec s ext4 a poprosil by som o radu
na openSUSE Tumbleweed zmizli všetky súbory z oddielu mapovaného na adresár /usr
Tým pádom sa stal systém nepoužiteľným...
Po reštarte nevedel nájsť ani /bin/sh ani init.
v SystemRescueCD (viem dnes už bez CD, ale toto je stará osvedčená verzia), fsck -pvcf na všetky oddiely sa súbory sa "objavili" na všetkých pripojených oddielocjh (tam, kde majú byť pre chroot ./suse /bin/bash, ktoré mi v minulosti fugovalo) Práva sú OK(755) ls -la /usr/bin/bash je ok. cp so súborom ide, file zo SystemRescueCD hlási ELF 64 bit x86 dynamicky linkovaný ldd zo SystemRescueCD hlási, že nie je dynamicky linkovaný a teda nedá zoznam potrebných knižníc a sputenie ./suse/usr/sbin/bash dá file not found. Ale chroot padne na file not found a som teda mimo možnosti použiť yast, zypper.. . Bash z System rescue CD potrebuje ncurses5 ale na disku je ncurses 6.2, takže sa nespustí ale nedá file not found ldconfig nejede, keďž chroot spadne na bash-i. pridanie položky . do LD_LIBRARY_PATH pre chroot nefunguje, lebo nevie, čím to interpretovať.
zdrojáky rozpúaracovaného projektu v C a Qt5 ostali nedotknuté ale nemám ich čím skompilovať inde.
Vie mi niekto poradiť, čo sa mohlo stať a ako to opraviť, prosím... Ja už strácam nápady.
S vďakou za radu
Peter Fodrek.
-
A neni to nahodou primountovany s 'noexec' ?
-
Pokud me pamet neklame, tak *file not found* byva i problem kdyz chces pustit 64bit exac z 32bit kernelu.
-
A neni to nahodou primountovany s 'noexec' ?
Ale to by musel byť ten parameter v partition table alebo v metadátach EXT4 a tie som nepozeral, ale nezdá a mi, že by tam bol taký parameter.
Mountuje to ako initrd s openSuse aj zo SystemRescueCD bez dodatočných parametrov pri mounte.
Jediné, čo ma napadá je nastavený Execute In Place parameter pre partíciu na rotačnom disku..
Ale vďaka toto je nápad. Ale už som tak dlho nerobil s parametrami EXT4fs, že si to musím znovu naštudovať, ak mi niekto priamo neporadí tu. Asi je ideálne skúšať obe veci naraz, poprosiť o radu a hľadať paralelne inde
-
Pokud me pamet neklame, tak *file not found* byva i problem kdyz chces pustit 64bit exac z 32bit kernelu.
To asi nie
SystemRescueCD 4.9.0 kernel 4.4.28-amd64
openSUSE
štandardný kernel 5.13.0rc3 (rc1 aj rc2 to neurobili aj rc3 viac ako 24 hodín)
fallback kernel 5.12.4-1
a robia to všetky 3 kernely... Teda ešte som neskúšal boot dista s SystemRescueCD kernelom, ktorý ale robí to isté...
-
SystemRescueCD 4.9.0 kernel 4.4.28-amd64
no to máte dost starý systemrescuecd, tam sice bývaly jádra 32 a 64 bit, ale userspace byl jen 32bit, to asi vadí, že nenajde knihovny atd.
novější systemrescuecd má 64bit userspace, tím by to mělo jít
-
SystemRescueCD 4.9.0 kernel 4.4.28-amd64
no to máte dost starý systemrescuecd, tam sice bývaly jádra 32 a 64 bit, ale userspace byl jen 32bit, to asi vadí, že nenajde knihovny atd.
novější systemrescuecd má 64bit userspace, tím by to mělo jít
vďaka skúsim
-
pri dumpe2fs ma zarazili 7 vecí:
A 399 groups
B. mount count: 1 (pri nepripojenom fs)
C. filesytem revision 1(dynamic)
D filesystem state: clean
E. filesytem flag: signed_directory_hash
F. filesystem featues: ........extra_isize
G. First inode: 11
nevidí tam niekto, čo mňa len mätie?
Ten Nonzero mount count pre mountom partície ma desí a netuším ako sa ho zbaviť= google zatiaľ nepomáha
Ešte raz vďaka
-
pri dumpe2fs ma zarazili 7 vecí:
A 399 groups
B. mount count: 1 (pri nepripojenom fs)
C. filesytem revision 1(dynamic)
D filesystem state: clean
E. filesytem flag: signed_directory_hash
F. filesystem featues: ........extra_isize
G. First inode: 11
nevidí tam niekto, čo mňa len mätie?
Ten Nonzero mount count pre mountom partície ma desí a netuším ako sa ho zbaviť= google zatiaľ nepomáha
Ešte raz vďaka
to nic není
mount count je jen počítadlo, kdy pustit automaticky e2fsck
viz Maximum mount count
ale od ext3 se Maximum mount count=0 a periodický test po několika mountech se už nepoužívá
-
A proc se vlastne snazis neco poustet ze sveho disku nebo tam delat chroot, kdyz vis ze tam neni /usr ?
Prvni pravidlo zachrany je - nesahat do poskozeneho. A druhy je zalohovat.. nejspis to mas hodne roz*****e takze bootni live distro / live cd (gentoo admincd ?), a odzalohuj si /etc, /root a /home, pripadne /opt a jine.. a udelej reinstall.
Protoze i kdyby jsi s e2fsck /dev/susedisk pochodil, to neni nastroj ktery by ti navratil /usr, ale vytvori zmet anonymnich souboru v lost+found.
-
A proc se vlastne snazis neco poustet ze sveho disku nebo tam delat chroot, kdyz vis ze tam neni /usr ?
Prvni pravidlo zachrany je - nesahat do poskozeneho. A druhy je zalohovat.. nejspis to mas hodne roz*****e takze bootni live distro / live cd (gentoo admincd ?), a odzalohuj si /etc, /root a /home, pripadne /opt a jine.. a udelej reinstall.
Protoze i kdyby jsi s e2fsck /dev/susedisk pochodil, to neni nastroj ktery by ti navratil /usr, ale vytvori zmet anonymnich souboru v lost+found.
Ale oni tam tie súbory sú
ja mám zvlášť partície pre
2x swap
/
/home
/usr
/var/log
/boot
/boot/efi
na /home a /boot nikdy nebol problém.
/boot/efi bol 1x plný
/var/log bol pomerne často plný
pre /usr/bin/bash mám overené, že na blok sedí veľkosť, podľa screenshotu z času, keď to fungovalo..
Reinštalácia je prejavom rezignácie alebo osobnej neschopnosti. Prosba o radu na odstránia osobného zacyklenia je prostriedok osobného odborného rastu(učiť sa môžete len od lepších od Vás) lebo sa človek dozvie, čo sa oplatí zvažovať.
-
Tak to, ze nesel bin/sh ani /init, nesouvisi s tim, zda mas usr ci nikoliv. Jsem nedavno delal jedno harakiri (nfsboot a prenastaveni site za behu, ze ktereho to bezi) a stacilo zkopirovat /bin /lib64 /sbin do tmpfs (ramdisku) a slo do toho udelat chroot.
Tvuj problem bych videl na to, ze nejde namountovat rootfs = nemas pak /bin/sh ani /sbin/init.
Tj. pouzivas nevhodny jadro, pro spousteni sveho OS.
BFU reseni: v bootloaderu vybrat nejakou starsi polozku, protoze vetsinou se novej kernel pridava, neprepisuje starej, a pri pregenerovani grub.conf se tam ty starsi veci objevi.
-
sputenie ./suse/usr/sbin/bash dá file not found
Protože se to snaží linkovat dynamickým linkerem který to hledá v tom systemrescuecd. Udělej na to strings, zjistíš jaký dynamický linker to potřebuje (u mě na Debianu je to /lib64/ld-linux-x86-64.so.2), a ověř, že ten jde spustit (./suse/lib64/ld-linux-x86-64.so.2, u mě to vypíše help).
Dále chroot do kompletně rozbitého systému provedeš tak, že tam hodíš staticky linkovaný busybox a uděláš "chroot ./suse /bin/busybox sh". Staticky linkovaný busybox pro všechny možné architektury stáhneš tady: https://packages.debian.org/buster/busybox-static
Následně můžeš zkusit pustit opět linker (/lib64/ld-linux-x86-64.so.2) a pak ručně přes něj bash (/lib64/ld-linux-x86-64.so.2 /bin/bash) nebo jiný program.
Bash z System rescue CD potrebuje ncurses5 ale na disku je ncurses 6.2, takže sa nespustí
Ano, je nesmysl spouštět dynamicky linkovaný bash z toho suse pomocí knihoven a linkeru ze systemrescuecd…
-
Ale oni tam tie súbory sú
...
pre /usr/bin/bash mám overené, že na blok sedí veľkosť, podľa screenshotu z času, keď to fungovalo..
Má suse něco jako debsums, že to zkontroluje checksumy nainstalovaných souborů? Velikost nic neznamená, jenom že to správně obnovilo metadata - ale v těch blocích můžou být libovolné nesmysly.
Reinštalácia je prejavom rezignácie alebo osobnej neschopnosti.
Souhlasím, reinstalace je blbost. Já bych odlil soubory pryč, udělal znovu filesystém (jestli to bylo takhle brutálně rozpadlé, tak bych tomu nevěřil i když fsck tvrdí že to opravil), nalil soubory zpátky, zkontroloval checksumy a ty poškozené nahradil správnými kopiemi z balíčkovacího systému.
-
Dále chroot do kompletně rozbitého systému provedeš tak, že tam hodíš staticky linkovaný busybox a uděláš "chroot ./suse /bin/busybox sh". Staticky linkovaný busybox pro všechny možné architektury stáhneš tady: https://packages.debian.org/buster/busybox-static
Vďaka uvažoval som nad staticky linknutým bash-om, ale bussybox je lepší..
-
Ale oni tam tie súbory sú
...
pre /usr/bin/bash mám overené, že na blok sedí veľkosť, podľa screenshotu z času, keď to fungovalo..
Má suse něco jako debsums, že to zkontroluje checksumy nainstalovaných souborů? Velikost nic neznamená, jenom že to správně obnovilo metadata - ale v těch blocích můžou být libovolné nesmysly.
jasne, file a ldd overí len magic bytes/magic block. readelf mi možno dá niečo podrobnejšie a ani to nemusí bzť dostatočné.
-
Tak to, ze nesel bin/sh ani /init, nesouvisi s tim, zda mas usr ci nikoliv. Jsem nedavno delal jedno harakiri (nfsboot a prenastaveni site za behu, ze ktereho to bezi) a stacilo zkopirovat /bin /lib64 /sbin do tmpfs (ramdisku) a slo do toho udelat chroot.
Tvuj problem bych videl na to, ze nejde namountovat rootfs = nemas pak /bin/sh ani /sbin/init.
initrd zbehne OK. problem nastane pri prepnuti na "real root" a hned po nom,
Ono to vyzera "len na" padnuty ld.so.cache. Lenze bez chrootu som ho neobnoval (volanim ldconfig). este skusim niekde splasit staticky linkovany bash alebo busybox sh
[root@sysrescue ~]# ls -la suse/bin/sh
-rwxr-xr-x 1 root root 1152112 May 27 10:00 suse/bin/sh
[root@sysrescue ~]# chroot suse /bin/sh
chroot: failed to run command ‘/bin/sh’: No such file or directory
[root@sysrescue ~]# suse/bin/sh
suse/bin/sh: /usr/lib/libreadline.so.8: no version information available (required by suse/bin/sh)
sh-5.1#
exit
[root@sysrescue ~]# find suse -iname libreadline.so*
suse/usr/lib/libreadline.so.8.1
suse/usr/lib/debug/usr/lib/libreadline.so.8.1-8.1-2.1.i386.debug
suse/usr/lib/debug/usr/lib64/libreadline.so.8.1-8.1-2.1.x86_64.debug
suse/usr/lib/libreadline.so.8
suse/usr/lib64/libreadline.so
suse/usr/lib64/libreadline.so.8
suse/usr/lib64/libreadline.so.8.1
suse/lib64/libreadline.so.5
suse/lib64/libreadline.so.6.3
suse/lib64/libreadline.so.6
suse/lib64/libreadline.so.5.2
suse/lib/libreadline.so.5
suse/lib/libreadline.so.6.3
suse/lib/libreadline.so.6
suse/lib/libreadline.so.5.2
-
Nevím, co víc ti na to říct.
[root@sysrescue ~]# chroot suse /bin/sh
chroot: failed to run command ‘/bin/sh’: No such file or directory
Ano, to víme, možná někde chybí ld, měl ses tam chrootnout s busyboxem a zkusit ldd a ld zevnitř. Nebo pustit ld chrootem.
[root@sysrescue ~]# suse/bin/sh
suse/bin/sh: /usr/lib/libreadline.so.8: no version information available (required by suse/bin/sh)
sh-5.1#
exit
[root@sysrescue ~]# find suse -iname libreadline.so*
suse/usr/lib/libreadline.so.8.1
To už taky víme. Jak má ld v sysresccd vědět, že má knihovny hledat v suse/usr/lib/? Cesty ke knihovnám jsou defaultně absolutní a systémové. Když už, možná by mu to šlo napovědět přes LD_LIBRARY_PATH.