Dateien/ordner nach löschen und reboot wieder da

  • Hallo
    Hab seit gestern ein sehr seltsames Prob, dass mir so in meinem Linux-Leben noch nicht untergekommen ist:

    (1.)
    Ich lösche ein Verzeichnis z.B.
    rm -v -r /var/www/wb
    Die Dateien werden während des Löschens gelistet und nach dem Löschen ist das Verzeichnis auch wirklich "verschwunden" .. Ein
    ls -la /var/www/
    lässt daran kein Zweifel.


    (2.)
    Ich erstelle eine Datei


    (3.)
    Ich reboote den Rechner

    (4.)
    Das "gelöschte" Verzeichnis aus (1) ist wieder da
    Die in (2.) erstellte Datei ist wieder verschwunden ....

    Der Rechner verhält sich plötzlich so, als hätte ich auf einer RAM-Disk gearbeitet
    Das Verhalten betrifft nur das root-Filesystem. Auf der gemounteten externen USB-HD gibt es die Probleme nicht

    Hat jemand eine Idee?
    Dankeschööööööön!


    -------------------------------------------------

    Rasberry 2 mit 128GB SD Card

    Rasbian
    uname -a
    Linux ExtremBeere 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux

    Filesystem Size Used Avail Use% Mounted on
    /dev/root 118G 2.5G 111G 3% /
    devtmpfs 459M 0 459M 0% /dev
    tmpfs 463M 0 463M 0% /dev/shm
    tmpfs 463M 6.2M 457M 2% /run
    tmpfs 5.0M 4.0K 5.0M 1% /run/lock
    tmpfs 463M 0 463M 0% /sys/fs/cgroup
    /dev/mmcblk0p1 60M 21M 40M 35% /boot
    /dev/sda1 641G 58G 551G 10% /data

    root@ExtremBeere:/var/www# mount
    /dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=469544k,nr_inodes=117386,mode=755)
    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    proc on /proc type proc (rw,relatime)
    tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
    tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
    cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
    cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
    cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
    cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
    cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
    cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
    cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
    systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
    debugfs on /sys/kernel/debug type debugfs (rw,relatime)
    mqueue on /dev/mqueue type mqueue (rw,relatime)
    configfs on /sys/kernel/config type configfs (rw,relatime)
    /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    /dev/sda1 on /data type ext4 (rw,relatime,data=ordered)

    Einmal editiert, zuletzt von Fischi (1. Juli 2016 um 10:02)

  • Ja, hatte das auch schon, SD hat sich auf read -only gestellt.
    Musste SD auf neue kopiert und damit gingst dann wieder.

    Frank

    Nach 35 Jahren im IT business hab ich mit Raspi mal selbst zum Programmieren begonnen...
    Habe auch einen 3D-Drucker, eine CNC-Fräse und etwas Elektronik-Bastelei als Hobby

    Einmal editiert, zuletzt von fjoke (1. Juli 2016 um 10:34)

  • Danke!
    Eine eigenständige "Reparatur" beim Boot, via
    touch /forcefsck
    ist ja auf Grund des eigenartigen Verhaltens nicht möglich, weil das File /forcefsck ja zum Zeitpunkt des Neustarts nicht mehr existiert. Ich werd die SD mal meinem Linux-Notebook zum Filesystemcheck vor die Füße werfen
    Automatisch zusammengefügt:


    Ja, hatte das auch schon, SD hat sich auf read -only gestellt.
    Musste SD auf neue kopiert und damit gingst dann wieder.

    Wie man ja bei mir sieht, ist die SD nicht auf readonly

    Einmal editiert, zuletzt von Fischi (1. Juli 2016 um 10:37)

  • Wie lange hast du die SD-Karte schon?
    Nebenbei: Du arbeitest schon auf einer RAM-Disk, allerdings auf NVRAM (nicht volatil (flüchtig))

    Gesendet von meinem D5803 mit Tapatalk

    Einmal editiert, zuletzt von Kaihaas (3. Juli 2016 um 06:24)

  • Wie gesagt, die Karte ist definitiv defekt. Sie lässt sich auf anderen Linux-Kisten meist nicht einmal mounten. Ein fsck scheitert ebenfalls. Warum aber Raspbian die Karte nicht als read only mountet ist mir völlig unklar - das Problem ist dadurch erst bei einem Reboot aufgefallen.

    Hab die Karte inzwischen ersetzt. Die Karte war erst ca. 1/2 Jahr alt (Samsung) - bisher hatte ich auch /var auch auf der SD-Karte.

    Bei meiner neuen Installation habe ich nun eine externe USB-Platte nach /var gemountet... Mein Rasberry inkl. owncloud und ttrss ist so beieindruckend um Längen schneller und auf Karte finden nun nur noch sehr wenige bis fast gar keine Schreibprozesse mehr statt ... Ich vermute die extensiven Schreibzugriffe von owncloud und ttrss sind letztlich dafür verantwortlich, dass die Lifetime der Karte so extrem kurz war

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!