Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #200773 > unrolled thread

all files moved to lost+found

Started byBeco <rcb@beco.cc>
First post2018-09-30 16:20 +0200
Last post2018-10-05 15:10 +0200
Articles 9 on this page of 29 — 8 participants

Back to article view | Back to linux.debian.user

Contents

  all files moved to lost+found Beco <rcb@beco.cc> - 2018-09-30 16:20 +0200
    Re: all files moved to lost+found Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-09-30 19:20 +0200
      Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-09-30 21:30 +0200
        Re: all files moved to lost+found Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-09-30 22:10 +0200
    Re: all files moved to lost+found David Christensen <dpchrist@holgerdanske.com> - 2018-09-30 20:30 +0200
      Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-09-30 21:30 +0200
        Re: all files moved to lost+found bw <bwtnguy@yahoo.com> - 2018-09-30 21:50 +0200
          Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-09-30 22:00 +0200
            Re: all files moved to lost+found Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-09-30 22:30 +0200
      Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-10-02 02:40 +0200
        Re: all files moved to lost+found David Christensen <dpchrist@holgerdanske.com> - 2018-10-02 04:10 +0200
          Re: all files moved to lost+found Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-10-02 05:50 +0200
            Re: all files moved to lost+found David Christensen <dpchrist@holgerdanske.com> - 2018-10-02 08:20 +0200
              Re: all files moved to lost+found Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-10-02 14:20 +0200
        Re: all files moved to lost+found Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-10-02 06:10 +0200
          Re: all files moved to lost+found David Christensen <dpchrist@holgerdanske.com> - 2018-10-02 08:40 +0200
            Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-10-04 05:10 +0200
              Re: all files moved to lost+found songbird <songbird@anthive.com> - 2018-10-04 13:40 +0200
                Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-10-05 03:00 +0200
                  Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-10-05 15:00 +0200
                    Re: all files moved to lost+found Gene Heskett <gheskett@shentel.net> - 2018-10-05 15:40 +0200
                      Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-10-10 06:20 +0200
                        Re: all files moved to lost+found Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-10-10 07:40 +0200
                          Re: all files moved to lost+found songbird <songbird@anthive.com> - 2018-10-10 23:40 +0200
                            Re: all files moved to lost+found Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-10-11 08:00 +0200
                              Re: all files moved to lost+found songbird <songbird@anthive.com> - 2018-10-11 14:50 +0200
                                Re: all files moved to lost+found Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-10-12 00:00 +0200
                        Re: all files moved to lost+found David Christensen <dpchrist@holgerdanske.com> - 2018-10-11 05:40 +0200
          Re: all files moved to lost+found Beco <rcb@beco.cc> - 2018-10-05 15:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#200929

FromGene Heskett <gheskett@shentel.net>
Date2018-10-05 15:40 +0200
Message-ID<wFyuK-26e-9@gated-at.bofh.it>
In reply to#200925
On Friday 05 October 2018 08:53:14 Beco wrote:

> Dear linux users,
>
> The memtest86+ came out clean.
>
> I run out of ideas to what was the problem.
>
> Wasn't it a very serious problem I would already stop writing emails.
> But to have the whole /home disappear, is something that changes your
> expectations for the whole linux experience.
>
> It has to have a simple explanation hidden somewhere (and
> testable/repeatable/provable, not just guesses)
>
> Thanks,
>
> Beco

In that event, I'd be checking the drive makers web site for firmware 
updates for YOUR drive(s)

Seagate is pretty good about that.

I'm not saying this is your problem, but it is something to investigate.

The last 1T drive I updated had already used up 25 sectors as 
re-allocated at < 5,000 spinning hours. After the update it was about 
25% faster, and 80,000+ spinning hours later, still had that same 25 
re-allocated sectors. Its a good drive yet but amanda needed more space, 
so it got replaced with a 2T drive. Stretch isn't stable yet,way too 
many networking problems so I'll probably wait till buster turns stable. 
Networking already Just Works from the reports I read here.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201104

FromBeco <rcb@beco.cc>
Date2018-10-10 06:20 +0200
Message-ID<wHe8x-3PV-3@gated-at.bofh.it>
In reply to#200929

[Multipart message — attachments visible in raw view] — view raw

Hello guys,

Just an update.

I was lead to believe that a problem with the UUID in the file:

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=e07e74f3-fa2f-blablabla

caused the error.

For some reason, this UUID was not reflecting the real UUID of the swap
file.


I was about to mark this as "solved" by that. But for my surprise, look at
this events (reported as an image here in imagebin, sorry about that):

https://ibin.co/4IZlwCvE6Ey0.png

After gcc fatal error saying the file (that is open in another terminal,
with vim, which I just compiled a few lines above successfully,) didn't
exist, I went to the other terminal, typed ":w" in vim, so to save it
again, and back to the compile terminal it found the file.

How come!?? It is amazing. This machine is doomed, or the system, not sure.
Something is really wrong here. I can lose files just like that!?

Thanks for any input.

Att.,
Beco.

PS. Maybe I should start a new installation from scratch, or maybe just to
be sure, start using the dual boot I've installed as Devuan, which I'm
still not fully using. It is just there, just in case. I don't know. Maybe
it is a KDE thing, because I tried to TEST all hardware (disk and memory).


PS. Ok, I was fast in screenshot, afraid to lose the error. But now that I
wrote this email easily, here it is, the same info in the image above, as
text. No need to see the image anyway.


[20181010.010115, !5088]$ gcc mequine.c -o mequine.x -Wall -Wextra -g -O0
mequine.c: In function ‘main’:
mequine.c:21:17: warning: implicit declaration of function ‘printcscc’ [
-Wimplicit-function-declaration]
                printcscc(s[6]);
                ^~~~~~~~~
[20181010.010304, !5088]$ gcc mequine.c -o mequine.x -Wall -Wextra -g -O0
gcc: error: mequine.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
[20181010.010328, !5088]$ gcc mequine.c -o mequine.x -Wall -Wextra -g -O0
[20181010.010345, !5088]$ springe
~/tmp/nofileScreenshot_20181010_010612.png
status:4IZlwCvE6Ey0
url:https://ibin.co/4IZlwCvE6Ey0.png

*>>>> It was a simple cycle: compile, error, fix, save, compile again (AND
THE FILE DISAPPEARED), save again, compile again (ALL GOOD).*




On Fri, 5 Oct 2018 at 10:33, Gene Heskett <gheskett@shentel.net> wrote:

> On Friday 05 October 2018 08:53:14 Beco wrote:
>
> > Dear linux users,
> >
> > The memtest86+ came out clean.
> >
> > I run out of ideas to what was the problem.
> >
> > Wasn't it a very serious problem I would already stop writing emails.
> > But to have the whole /home disappear, is something that changes your
> > expectations for the whole linux experience.
> >
> > It has to have a simple explanation hidden somewhere (and
> > testable/repeatable/provable, not just guesses)
> >
> > Thanks,
> >
> > Beco
>
> In that event, I'd be checking the drive makers web site for firmware
> updates for YOUR drive(s)
>
> Seagate is pretty good about that.
>
> I'm not saying this is your problem, but it is something to investigate.
>
> The last 1T drive I updated had already used up 25 sectors as
> re-allocated at < 5,000 spinning hours. After the update it was about
> 25% faster, and 80,000+ spinning hours later, still had that same 25
> re-allocated sectors. Its a good drive yet but amanda needed more space,
> so it got replaced with a 2T drive. Stretch isn't stable yet,way too
> many networking problems so I'll probably wait till buster turns stable.
> Networking already Just Works from the reports I read here.
>
> --
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>

-- 
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

[toc] | [prev] | [next] | [standalone]

#201105

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2018-10-10 07:40 +0200
Message-ID<wHfnX-4wf-3@gated-at.bofh.it>
In reply to#201104
Le 10/10/2018 à 06:18, Beco a écrit :
> 
> I was lead to believe that a problem with the UUID in the file:
> 
> $ cat /etc/initramfs-tools/conf.d/resume
> RESUME=UUID=e07e74f3-fa2f-blablabla
> 
> caused the error.
> 
> For some reason, this UUID was not reflecting the real UUID of the swap
> file.

The most common reason is that the swap was reformatted by another 
installation and its UUID changed. This cannot cause filesystem corruption.

[toc] | [prev] | [next] | [standalone]

#201134

Fromsongbird <songbird@anthive.com>
Date2018-10-10 23:40 +0200
Message-ID<wHun0-4Ml-7@gated-at.bofh.it>
In reply to#201105
Pascal Hambourg wrote:
...
> The most common reason is that the swap was reformatted by another 
> installation and its UUID changed. This cannot cause filesystem corruption.

  unless the user mistakenly reversed the partitions...
swap is always reformatted if used during an installation.


  songbird

[toc] | [prev] | [next] | [standalone]

#201153

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2018-10-11 08:00 +0200
Message-ID<wHCaS-RX-3@gated-at.bofh.it>
In reply to#201134
Le 10/10/2018 à 23:17, songbird a écrit :
> Pascal Hambourg wrote:
> ...
>> The most common reason is that the swap was reformatted by another
>> installation and its UUID changed. This cannot cause filesystem corruption.
> 
>    unless the user mistakenly reversed the partitions...

What do you mean ?

> swap is always reformatted if used during an installation.

Are you sure all distributions do this ?

[toc] | [prev] | [next] | [standalone]

#201165

Fromsongbird <songbird@anthive.com>
Date2018-10-11 14:50 +0200
Message-ID<wHIzE-4Ig-1@gated-at.bofh.it>
In reply to#201153
Pascal Hambourg wrote:
> Le 10/10/2018 à 23:17, songbird a écrit :
>> Pascal Hambourg wrote:
>> ...
>>> The most common reason is that the swap was reformatted by another
>>> installation and its UUID changed. This cannot cause filesystem corruption.
>> 
>>    unless the user mistakenly reversed the partitions...
>
> What do you mean ?

  if when the OP installed he mistakenly used the
file system directory of his home directories instead
of the swap partition.

  the UUID should not have changed...


>> swap is always reformatted if used during an installation.
>
> Are you sure all distributions do this ?

   we are on debian user here are we not?  the
OP is talking about debian.


  songbird

[toc] | [prev] | [next] | [standalone]

#201172

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2018-10-12 00:00 +0200
Message-ID<wHR9T-1fN-1@gated-at.bofh.it>
In reply to#201165
Le 11/10/2018 à 14:39, songbird a écrit :
> Pascal Hambourg wrote:
>> Le 10/10/2018 à 23:17, songbird a écrit :
>>> Pascal Hambourg wrote:
>>> ...
>>>> The most common reason is that the swap was reformatted by another
>>>> installation and its UUID changed. This cannot cause filesystem corruption.
>>>
>>>     unless the user mistakenly reversed the partitions...
>>
>> What do you mean ?
> 
>    if when the OP installed he mistakenly used the
> file system directory of his home directories instead
> of the swap partition.
> 
>    the UUID should not have changed...

I don't understand what you mean. The swap UUID changed. Not the /home UUID.

>>> swap is always reformatted if used during an installation.
>>
>> Are you sure all distributions do this ?
> 
>     we are on debian user here are we not?  the
> OP is talking about debian.

We are talking about another installation. The other distribution may 
not be Debian.

[toc] | [prev] | [next] | [standalone]

#201151

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2018-10-11 05:40 +0200
Message-ID<wHzZn-86j-3@gated-at.bofh.it>
In reply to#201104
On 10/9/18 9:18 PM, Beco wrote:
> PS. Maybe I should start a new installation from scratch, 

+1


Do a fresh install of Debian Stable using only official Debian packages, 
make as few configuration changes as possible (e.g. /etc/*), run the 
laptop as your primary desktop for a week, and see what happens:

1.  If the laptop is stable, then the most likely root cause was 
scrambled software.

2.  If the laptop is unstable, then the most likely root cause is 
immature Linux support.  In this case, re-install Windows and run that 
as your primary desktop for a week:

a.  If the laptop is stable, your hardware is good and the problem was 
immature Linux support.  Install a hypervisor and build a Debian VM.

b.  If the laptop is unstable, then root causes include hardware and 
immature Windows support.  Return or repair the laptop.


David

[toc] | [prev] | [next] | [standalone]

#200928

FromBeco <rcb@beco.cc>
Date2018-10-05 15:10 +0200
Message-ID<wFy1I-1Xz-15@gated-at.bofh.it>
In reply to#200812

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2 Oct 2018 at 01:07, Abdullah Ramazanoğlu <ar018@yahoo.com> wrote:

>
> But the journal is passing through on-disk controller, too. If the drive is
> mishandling its on-drive cache, then an FS corruption is still possible.
> Even
> if journal writes are "direct", the drive could be ignoring that (i.e.
> caches
> it nevertheless) without flushing it prior to power-off, corrupting the
> journal
> as well.
>
> If the FS survives through reboots, but falters when the laptop is power
> cycled, then a cache flush issue is still probable.
>
> Another test method might be hibernation. If resume from hibernation works,
> then that rules out on-disk caching problem.
>
> Regards
> --
> Abdullah Ramazanoğlu
>
>
>
Thanks Abdullah,

(Somehow your message went to spam)

I'll try hibernation test. Good idea. This behaviour has to have something
to do with cache. I don't see how this could happen otherwise.

Regards,
Beco




-- 
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web