[gentoo-user] Note: USE=ffmpeg alsa-plugins-1.1.6 won't build with recent ffmpeg

2018-12-17 Thread akater
Apparently, this is due to removal of deprecated audio resampling
functions but I didn't check thoroughly.

https://www.ffmpeg.org/doxygen/2.4/group__lavc__resample.html

Whatever the issue is, it is not reflected in ebuild yet. Just FYI.


signature.asc
Description: PGP signature


Re: [gentoo-user] data recovery advice needed

2018-12-17 Thread Jack

On 2018.12.17 17:32, Heiko Baums wrote:

Am Sat, 15 Dec 2018 18:33:35 -0500
schrieb Jack :

Some months ago, I borked a laptop HDD by trying to move a partition  
in a way that left both the old and new partitions invalid.  (For my  
sanity, I've forced the details out of my memory, but the old and  
new locations overlapped, and I think the move might have been  
interrupted.  My own fault, I know.)


Have you written anything on this HDD after moving those partitions?  
And did you move the partitions or did you repartition the HDD?
At this point, unfortunately, my memory is hazy.  I did not  
repartition, but the damage made accessing anything difficult (see  
details below).  The additional problem is that now I'm getting  
physical read errors on the drive, so to be safe, I'd need to get  
another drive large enough to use ddrescue, and then go digging.


You could try to find the beginning of the old partitions with  
hexedit and set a pointer to this position with losetup. Set the  
offset to this position. Linux actually doesn't need partitions to  
access the HDD and/or mount file systems. Partitions just make it a  
lot easier.
At this point, I think I've forgotten the details, but using the  
example of a 300G drive with 100G empty and then a 200G partition, when  
I moved the partition to the beginning of the disk (using gparted, as I  
remember) once it moved more than the first 100G of the partition, it  
overwrote the beginning of the original partition, and once it  
overwrote any of the directory structure it still needed to know where  
stuff was, game over.   The first 100G of the "new" partition is  
essentially intact, but the damage to the beginning of the "old"  
partition makes it difficult to start.  I suppose I could go looking  
for any intact directory inodes and see whether it's intact enough to  
find anything of interest.  (There are really only a few files I would  
still like to recover - but as they are in fact .VDI files, it's likely  
all or nothing, because I don't think just part of one of them will be  
at all useful.)  In fact, it would be more acurate to say there was  
another 100G before all of that, and that partition is still intact,  
except for the read errors.


And keep in mind that partitions are written to the partition table  
at the beginning of the drive. Repartitioning usually doesn't  
overwrite any data. So if you haven't written anything onto the new  
partitions (incl. formatting the new partitions) all the data is most  
likely still there.
The "new" partition is incomplete, but essentially intact, as much of  
it is there.  The beginning of the "old" partition is overwitten with  
stuff from somewhere in the middle of the partition being moved.


So you could also try to recover your old partition table. Maybe the  
backup of your old super block is still intact. Unfortunately I can't  
remember how to find it out. Maybe with fdisk resp. gdisk or with  
testdisk.
I know the location of all the partition starts and ends, so that's not  
the issue.  I just need lots more empty space to put the copies so I  
can safely go digging.


But there is a chance that the behavior of moving partitions is a bit  
different than repartitioning the HDD, so that the data is actually  
already overwritten by moving those partitions.

Exactly.


On the other hand, if you had really moved the partitions the  
partitioning tool you used should have seen that both partitions  
would overlap and shouldn't have done this.
I think I mentioned that.  I'm going to have to do some testing, and  
probably learn that gparted is smarter than I thought, which means I've  
clearly forgotten something else stupid that I did.  Otherwise, I'll  
file a bug against gparted.


That said, no matter which problem you have with an HDD, always stay  
calm and think first before you do anything. In most cases you can  
recover your data. But the first step is to stop working  
(particularly writing) with this HDD. The second step is - as the  
others already mentioned - to make a copy with dd or ddrescue.
All that would be good and "easy" (for some definition) if the disk  
itself were not in process of failing.


I had a lot of HDD crashes, logical and physical ones. And once I  
even didn't have a backup. I never lost any data so far, not even a  
bit.

I'd call that "famous last words" :-)


Heiko

Jack


Re: [gentoo-user] data recovery advice needed

2018-12-17 Thread Heiko Baums
Am Sat, 15 Dec 2018 18:33:35 -0500
schrieb Jack :

> Some months ago, I borked a laptop HDD by trying to move a partition
> in a way that left both the old and new partitions invalid.  (For my  
> sanity, I've forced the details out of my memory, but the old and
> new locations overlapped, and I think the move might have been  
> interrupted.  My own fault, I know.)

Have you written anything on this HDD after moving those partitions?
And did you move the partitions or did you repartition the HDD?

You could try to find the beginning of the old partitions with hexedit
and set a pointer to this position with losetup. Set the offset to this
position. Linux actually doesn't need partitions to access the HDD
and/or mount file systems. Partitions just make it a lot easier.

And keep in mind that partitions are written to the partition table at
the beginning of the drive. Repartitioning usually doesn't overwrite
any data. So if you haven't written anything onto the new partitions
(incl. formatting the new partitions) all the data is most likely still
there.

So you could also try to recover your old partition table. Maybe the
backup of your old super block is still intact. Unfortunately I can't
remember how to find it out. Maybe with fdisk resp. gdisk or with
testdisk.

But there is a chance that the behavior of moving partitions is a bit
different than repartitioning the HDD, so that the data is actually
already overwritten by moving those partitions.

On the other hand, if you had really moved the partitions the
partitioning tool you used should have seen that both partitions
would overlap and shouldn't have done this.

That said, no matter which problem you have with an HDD, always stay
calm and think first before you do anything. In most cases you can
recover your data. But the first step is to stop working (particularly
writing) with this HDD. The second step is - as the others already
mentioned - to make a copy with dd or ddrescue.

I had a lot of HDD crashes, logical and physical ones. And once I even
didn't have a backup. I never lost any data so far, not even a bit.

Heiko



Re: [gentoo-user] data recovery advice needed

2018-12-17 Thread Grant Taylor

On 12/17/2018 12:42 PM, Rich Freeman wrote:
There is of course no guarantee that it will EVER successfully read all 
your data.  You might be able to tell it to skip blocks and move on. 
Obviously all it can do is keep asking the drive to try again.  If you 
want better than that then you're talking clean room rescue measures.


As long as the drive isn't going into physical failure; bearings, 
thermal death, etc, you may be okay.


I'm a fan of SpinRite.  I've had SpinRite recover things that everything 
else said was impossible to recover.  SpinRite addresses media issues 
and helps the drive detect that there is a problem.  SpinRite also has a 
mode, DynaStat, that it will try many many many times to read a given 
sector using all sorts of tricks, head seek patterns, etc.  (You can 
also alter it's default behavior to try more or fewer times.)


There is no trial copy of SpinRite.  But GRC does have a good return 
policy.  If you buy SpinRite to recover your drive, and are unsatisfied, 
they will very very extremely likely give you your money back.  (There 
is a tiny fraction of a chance that they won't refund your money if you 
don't try the things they ask to make sure that you aren't using 
SpinRite properly.)  So, it's not like you are out money if it doesn't 
work.  (I think it's MSRP of ~$90.)


Aside:  It sounds like your drive might think that it has problems 
reading the media, which is SpinRite's domain.


Make sure the drive is not overheating.  Even a lowly 80 mm case fan 
will move more than enough air to keep the average drive cool enough, 
even during heavy use / data recovery.


Once you know that you have good magnetic media, then you can start 
playing to reconstruct your partition.


So, SpinRite is an option before places like DriveSavers (or what ever 
name they go by).  Even they have a no-guarantee of recovery policy.


If you're trying to rescue your bittorrent collection I'd suggest 
moving on.


I misread "bittorrent" as "bitcoin".  That /might/ be another story. 
Depending on how many BTC you have.




--
Grant. . . .
unix || die



Re: [gentoo-user] data recovery advice needed

2018-12-17 Thread Grant Taylor

On 12/17/2018 12:32 PM, Jack wrote:
The other drive failed over a shorter period of time, even though SMART 
testing said all was OK.


IMHO, by the time that S.M.A.R.T. complains, most chances of data 
retrieval are gone.


I treat S.M.A.R.T. errors as a confirmation that the drive realizes that 
there is an imminent or past tense catastrophic failure.




--
Grant. . . .
unix || die



Re: [gentoo-user] data recovery advice needed

2018-12-17 Thread Rich Freeman
On Mon, Dec 17, 2018 at 2:32 PM Jack  wrote:
>
> ddrescue has now been running for almost 22 hours, and it's been 47
> seconds less than that since its last successful read.

There is of course no guarantee that it will EVER successfully read
all your data.  You might be able to tell it to skip blocks and move
on.  Obviously all it can do is keep asking the drive to try again.
If you want better than that then you're talking clean room rescue
measures.

> I did one run of testdisk on one partition on the drive months ago.
> One problem is that the extension on the recovered files is not
> necessarily the original extension (even if the file is actually
> recoverable) and there seem to be some file types is doesn't (or didn't
> then) know about.  I may well try it again after much more reading on
> tuning its behavior.

Even in the best of circumstances this sort of approach is
painstaking.  If that drive has the only photos of your kid's birth it
might be worth the trouble to you.  If you're trying to rescue your
bittorrent collection I'd suggest moving on.

Or you can try to pay somebody to do it for you.  There is a reason
those recovery companies charge an arm and a leg.  People who are
desperate enough to need their services don't have many other
options...

-- 
Rich



Re: [gentoo-user] data recovery advice needed

2018-12-17 Thread Jack
Thanks to both Rich and Grant for suggestions.  Part of my issue is  
that I currently have two different failing/failed HDDs to deal with,  
and one of them has two different problems.  At this point, although  
there are files I would really love to recover from each of them, it's  
not critical, so I'm taking my time.  I'll post more details or at  
least status upste later, depending on how things work out.


On 2018.12.15 19:19, Rich Freeman wrote:
On Sat, Dec 15, 2018 at 6:33 PM Jack  
 wrote:

>
So, I removed that HDD for safekeeping (completely reinstalled the  
laptop on a new drive) and now I'm trying to recover data from an  
intact partition on the old drive, the problem being that the drive  
is giving some read errors, so I want to minimize access, lest it  
die completely.


Ok, step 1 - make a copy of the drive before you go messing with it.  
I suggest using ddrescue for this.  Basically it works like dd  
(creates an image of the drive), but it is persistent in the face of  
read errors.
ddrescue has now been running for almost 22 hours, and it's been 47  
seconds less than that since its last successful read.   The odd thing  
(to me, although it probably should not be) is that the first issue  
with this drive was my own stupidity for trying to move a partition in  
a way I should have known would not work.  (Simplified if inaccurate  
description is a 300GB drive with 100GB free and then a 200GB  
partition, which I tried to move to the beginning of the drive.)  That  
garbled the partition, but the drive itself still worked fine.  Since  
then, the drive itself has started giving lots of read errors, thus the  
slow progress of ddrescue.)  The other drive failed over a shorter  
period of time, even though SMART testing said all was OK.  One of the  
failures led to fsck "fixing"lots of stuff, but truncating or otherwise  
effectively destroying lots of files.  It's a SATA drive, now connected  
to a laptop (only place I have enough recovery space on a good drive)  
by a SAS to USB adaptor.


Once you have a copy of the drive you can now start experimenting.  
Obviously keep that copy safe and if you want to write to it create  
another copy.

understood and agreed.


As far as fixing dates goes - the touch suggestion might work but  
honestly unless you're in a super hurry I'd just do another copy.
once the ddrescue works, any approach will work.  However, neither is  
likely to be very helpful with the number of read failures I'm getting.


If you've lost any kind of drive metadata such that files are missing  
completely there are utilities that can scan disk blocks looking for  
things like text files, or jpegs.  That is going to be a massive  
headache but if you've lost something indispensible it is an option.
I did one run of testdisk on one partition on the drive months ago.   
One problem is that the extension on the recovered files is not  
necessarily the original extension (even if the file is actually  
recoverable) and there seem to be some file types is doesn't (or didn't  
then) know about.  I may well try it again after much more reading on  
tuning its behavior.


Ultimately your goal is going to be to get the files you care about  
off the drive.  Then you can just copy/rsync them to a completely  
fresh filesystem - I wouldn't go trying to copy the old filesystem  
using dd if it has been subject to read errors or especially partial  
overwrites of metadata.  You want the metadata to be clean.

right.


And then once you have your data back on a disk give some thought to  
your backup strategy.  If you care about data enough to be going  
through trouble to rescue it, you should probably have a backup of  
it. When I was messing around with btrfs and the filesystem ate my  
data I wasn't messing around with hex editors - I just wiped the  
filesystem and rsynced from a backup.  Sure, it takes time, but you  
know the filesystem is completely clean when you're done.
Someone (on this list?) had a signature "There are two kinds of people:  
those who do backups and those who have never had a hard drive fail."   
I guess there's actually a third.


--
Rich

Jack


Re: [gentoo-user] Linux 4.19.8 kernel panics with netfilter/iptables

2018-12-17 Thread Ralph Seichter
* Hasan Ç.:

> I can share my results.

Have you been able to run some tests yet?

-Ralph