On 14 februarie 2015 11:46:46 EET, Florin Popovici <[email protected]> wrote: >2015-02-13 14:54 GMT+02:00
>Intr-adevar, initramfs-ul de la kernelul nou nu era bun :) > Ca sa citez din clasici, "been there, done that" >Anyway, ca sa incheiem povestea. >Am gasit ceva interesant in /var/log/messages: […] kernel: EXT4-fs error (device vda2): >ext4_free_inode: bit already cleared for inode 46758 >Feb 13 00:08:13 eg-PB-proc3 kernel: EXT4-fs error (device vda2): >ext4_claim_inode: reserved inode or inode > inodes count - block_group […] > >Deci se pare ca a fost ceva problema de consistenta cu FS-ul (vda2 e / >). Exact ce ti-am zis :) yum saracul e nevinovat de data asta. Cind fs-ul se duce in bozii...Ar fi ifost util (si interesant) de aflat de ce a crezut yum ca e totul OK si a continuat, in loc sa se opreasca. Uzual in cazuri din astea se opreste si anunta eroare. (E usor de verificat asta facind inainte de update un chattr +i pe un fisier pe care yum si-ar dori sa il inlocuiasca.) > >Intre timp am refacut masina -- nici macar de la zero, am reusit s-o >recuperez: montat discul intr-o alta, fsck, restore din backup. >A mai fost nevoie apoi si de chroot && grub-install, ca era stricat >pana si >grub. (se agata dupa "Booting from hard disk", cred ca la stage1 ca nu >aparea promptul de Grub sa selectez kernelul). Cind se duce pe cimpii fs-ul (oricare ar fi motivul - RAM busit, hdd defect, overclocking exagerat), fara o verificare completa a intregului continut (macar cu r@pm -qaV) nu mai poti avea incredere in informatia citita/scrisa pe disc. Potential absolut orice bit poate fi alterat. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
