[opensuse] Very basic dd question
I ask this kinda stupid question only because I really don't want to experiment with my only running computer. A friend has a bunch of very old Windows crap and wanted to know if I could "clone" a couple of his drives so he gave me 2 good drives and several "target" drives - all laptop ide, I think - anyway, I have one usb adapter that I can use, so the question is will the following work to clone a drive? dd if= /dev/sdb (the usb drive) of=/user/[my user home]/temp/bck If so, what would I need to tell it to make a bootable clone? Just reverse the commands? The drive is 540MB so space isn't an issue... And yes, disk partitioning software does see the usb drive and when it is plugged in the system allows me to open it in Dolphin. Thanks, Fred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Feb 28, 2017 at 3:00 PM, Stevens <fred-n-sandy@myrhinomail.com> wrote:
I ask this kinda stupid question only because I really don't want to experiment with my only running computer.
A friend has a bunch of very old Windows crap and wanted to know if I could "clone" a couple of his drives so he gave me 2 good drives and several "target" drives - all laptop ide, I think - anyway, I have one usb adapter that I can use, so the question is will the following work to clone a drive? dd if= /dev/sdb (the usb drive) of=/user/[my user home]/temp/bck
If so, what would I need to tell it to make a bootable clone? Just reverse the commands? The drive is 540MB so space isn't an issue...
And yes, disk partitioning software does see the usb drive and when it is plugged in the system allows me to open it in Dolphin.
Thanks, Fred
Yes, that will work as long as you run it as root, but if it's that old, you might have a bad sector or two. At a minimum use this: dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync bs=512 will slow things down, but make sure that if you have an error, only the truly bad sectors will be lost. A sector is 512 bytes and they are either good or bad. noerror says not to stop just because you hit a failed sector sync says that if you have a bad sector, fill that part of your backup with zeros. As to the restore, it can be as simple as: cat [whatever] > /dev/sdb; sync fyi: I make these kinds of drive backups as part of my job, thus my knowledge of the little known args. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer composed on 2017-02-28 15:24 (UTC-0500):
Yes, that will work as long as you run it as root, but if it's that old, you might have a bad sector or two.
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
bs=512 will slow things down, but make sure that if you have an error, only the truly bad sectors will be lost. A sector is 512 bytes and they are either good or bad.
noerror says not to stop just because you hit a failed sector
sync says that if you have a bad sector, fill that part of your backup with zeros.
Any reason not to use dd_rescue instead of dd in the first place? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2017 02:37 PM, Felix Miata wrote:
Greg Freemyer composed on 2017-02-28 15:24 (UTC-0500):
Yes, that will work as long as you run it as root, but if it's that old, you might have a bad sector or two.
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
bs=512 will slow things down, but make sure that if you have an error, only the truly bad sectors will be lost. A sector is 512 bytes and they are either good or bad.
noerror says not to stop just because you hit a failed sector
sync says that if you have a bad sector, fill that part of your backup with zeros.
Any reason not to use dd_rescue instead of dd in the first place?
My being totally unfamiliar with dd_rescue probably enters into it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stevens composed on 2017-02-28 14:59 (UTC-0600):
Felix Miata wrote:
Any reason not to use dd_rescue instead of dd in the first place?
My being totally unfamiliar with dd_rescue probably enters into it.
It's in OSS, and not really any more complicated to get familiar with than dd. http://forensicswiki.org/wiki/Dd_rescue -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2017 03:10 PM, Felix Miata wrote:
Stevens composed on 2017-02-28 14:59 (UTC-0600):
Felix Miata wrote:
Any reason not to use dd_rescue instead of dd in the first place?
My being totally unfamiliar with dd_rescue probably enters into it.
It's in OSS, and not really any more complicated to get familiar with than dd.
Felix, that is all well and good but it looks like another mountain to climb and still does not answer the original question, which Greg answered with his post. If I get time AND if I get a spare machine AND if I am still inspired to figure this out then, I may dig into dd_rescue and add another skill to my set. Thanks for trying to help me. I keep those posts that interest me; this is one of those. Fred -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/02/17 20:59, Stevens wrote:
On 02/28/2017 02:37 PM, Felix Miata wrote:
Greg Freemyer composed on 2017-02-28 15:24 (UTC-0500):
Yes, that will work as long as you run it as root, but if it's that old, you might have a bad sector or two.
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
bs=512 will slow things down, but make sure that if you have an error, only the truly bad sectors will be lost. A sector is 512 bytes and they are either good or bad.
noerror says not to stop just because you hit a failed sector
sync says that if you have a bad sector, fill that part of your backup with zeros.
Any reason not to use dd_rescue instead of dd in the first place?
My being totally unfamiliar with dd_rescue probably enters into it.
As far as I am aware, basic ddrescue syntax is identical to dd. HOWEVER. If you have problems with dd it will leave you up a gum tree. Especially if copying something like a disk drive. The classic problem with dd aiui, is that if it fails to read, lets say, sector 10 on your old drive, it simply skips that when writing to the new drive, so the old sector 11 becomes the new sector 10. Cue everything after your failed read being scrambled. That's why the default is to abort after a failed read! Just use ddrescue as if it were dd, and (a) your chances of a successful copy are a lot higher - it has loads of tricks for dealing with dodgy reads, and (b) the copy you end up with will be as perfect as possible - holes where there were failed reads etc. It will also give you a log of any failed reads if you ask it, so you can (if your fu is good enough) work out what files have been damaged. Hopefully, on the raid list we will soon have a script that will take that log and force soft read failures on the new drive where there was a hard failure on the old one. That will cause any attempt to read a corrupt file to bomb. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2017 03:20 PM, Wols Lists wrote:
On 28/02/17 20:59, Stevens wrote:
On 02/28/2017 02:37 PM, Felix Miata wrote:
Greg Freemyer composed on 2017-02-28 15:24 (UTC-0500):
Yes, that will work as long as you run it as root, but if it's that old, you might have a bad sector or two.
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
bs=512 will slow things down, but make sure that if you have an error, only the truly bad sectors will be lost. A sector is 512 bytes and they are either good or bad.
noerror says not to stop just because you hit a failed sector
sync says that if you have a bad sector, fill that part of your backup with zeros.
Any reason not to use dd_rescue instead of dd in the first place?
My being totally unfamiliar with dd_rescue probably enters into it.
As far as I am aware, basic ddrescue syntax is identical to dd.
HOWEVER. If you have problems with dd it will leave you up a gum tree. Especially if copying something like a disk drive.
The classic problem with dd aiui, is that if it fails to read, lets say, sector 10 on your old drive, it simply skips that when writing to the new drive, so the old sector 11 becomes the new sector 10. Cue everything after your failed read being scrambled. That's why the default is to abort after a failed read!
Just use ddrescue as if it were dd, and (a) your chances of a successful copy are a lot higher - it has loads of tricks for dealing with dodgy reads, and (b) the copy you end up with will be as perfect as possible - holes where there were failed reads etc.
It will also give you a log of any failed reads if you ask it, so you can (if your fu is good enough) work out what files have been damaged. Hopefully, on the raid list we will soon have a script that will take that log and force soft read failures on the new drive where there was a hard failure on the old one. That will cause any attempt to read a corrupt file to bomb.
Cheers, Wol
Wol - Greg said that the sync option puts zeros where there was a bad sector. Is that not the same as what you are saying about dd_rescue's action? I mean, it would seem to maintain the sector count. I do not know, I have not used either. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Feb 28, 2017 at 4:31 PM, Stevens <fred-n-sandy@myrhinomail.com> wrote:
On 02/28/2017 03:20 PM, Wols Lists wrote:
On 28/02/17 20:59, Stevens wrote:
On 02/28/2017 02:37 PM, Felix Miata wrote:
Greg Freemyer composed on 2017-02-28 15:24 (UTC-0500):
Yes, that will work as long as you run it as root, but if it's that old, you might have a bad sector or two.
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
bs=512 will slow things down, but make sure that if you have an error, only the truly bad sectors will be lost. A sector is 512 bytes and they are either good or bad.
noerror says not to stop just because you hit a failed sector
sync says that if you have a bad sector, fill that part of your backup with zeros.
Any reason not to use dd_rescue instead of dd in the first place?
My being totally unfamiliar with dd_rescue probably enters into it.
As far as I am aware, basic ddrescue syntax is identical to dd.
HOWEVER. If you have problems with dd it will leave you up a gum tree. Especially if copying something like a disk drive.
The classic problem with dd aiui, is that if it fails to read, lets say, sector 10 on your old drive, it simply skips that when writing to the new drive, so the old sector 11 becomes the new sector 10. Cue everything after your failed read being scrambled. That's why the default is to abort after a failed read!
Just use ddrescue as if it were dd, and (a) your chances of a successful copy are a lot higher - it has loads of tricks for dealing with dodgy reads, and (b) the copy you end up with will be as perfect as possible - holes where there were failed reads etc.
It will also give you a log of any failed reads if you ask it, so you can (if your fu is good enough) work out what files have been damaged. Hopefully, on the raid list we will soon have a script that will take that log and force soft read failures on the new drive where there was a hard failure on the old one. That will cause any attempt to read a corrupt file to bomb.
Cheers, Wol
Wol - Greg said that the sync option puts zeros where there was a bad sector. Is that not the same as what you are saying about dd_rescue's action? I mean, it would seem to maintain the sector count. I do not know, I have not used either.
Fred, With the command I gave, the fundamental difference is dd always starts at the beginning (or whatever offset you provide) and linearly works to get to the end. It definitely only makes one linear pass at all the data(sectors) you've requested. dd_rescue and ddrescue are both designed to work with dieing disks. I forget which is which, but one of them at least when it hits a bad block will jump ahead and leave a gap, Then when it finishes the first pass (including gaps), it comes back and tries to get all the missing pieces. It can make 5 or 10 passes (or more) trying to get a complete copy. The log is used to keep track of what it still needs to get, so you keep passing the same log file to it every time you call it for the same disk. One of them comes with a batch script to automate the process. I don't use that one; I prefer to control what it is doing myself. If you give either the right arguments, they will even fill in the missing pieces by reading the sectors backwards. They really are great tools, but at least in my mind they both have a lot of complex feature set. As I said, I reserve them both for seriously problematic drives such as one having had a head crash, not ones with just a few bad sectors. Think about a drive with several large contiguous sections of bad sectors. dd will not handle that well. I've been working seriously with client disks for 10 years and I doubt if I've had to invoke either ddrescue or dd_rescue more than a dozen times combined. One big reason for that is that if a disk is in that bad of shape, I send it out to a professional recovery lab most of the time. Having ddrescue beat a disk to death can just make the situation worse. If the head is banging into the platter, it is much better to have a real lab swap out the bad components and do the recovery the right way. But real labs charge real money to do that (~$1.5K to attempt a recovery of drive with serious physical problems, sometimes more). Note: I started my own company 4 years ago. Since then I "imaged" (via dd or similar) hundreds of drives, maybe a thousand. I have not had to send a single drive out for recovery and I doubt I've had to use ddrescue/dd_rescue more than once or twice. Note 2: I don't actually use dd most of the time. I use dc3dd or ewfacquire, but both of them only do a linear sector read like dd does. The advantage is they record extra metadata that helps with confirming the image (copy) hasn't become corrupt over time. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-03-01 00:06, Greg Freemyer wrote:
dd_rescue and ddrescue are both designed to work with dieing disks. I forget which is which, but one of them at least when it hits a bad block will jump ahead and leave a gap, Then when it finishes the first pass (including gaps), it comes back and tries to get all the missing pieces. It can make 5 or 10 passes (or more) trying to get a complete copy. The log is used to keep track of what it still needs to get, so you keep passing the same log file to it every time you call it for the same disk. One of them comes with a batch script to automate the process. I don't use that one; I prefer to control what it is doing myself.
That will be dd_rhelp. It is a bash script: er@minas-tirith:~> dd_rhelp --help dd_rhelp ver. 0.3.0 Options: --help Print this message --version Print version information {filename|device} The source file (it can be a block device) {output-file} The destination file info Specifying "info" as third argument will display summary informations on ongoing recovery and exit without taking any actions. Note: A log file will be created, and named '<output-file>.log'. This is a dd_rescue log file (which is human readable). This log file is important as dd_rhelp feeds itself with its contents to manage correctly dd_rescue. Without this log file, dd_rescue won't support resume capability. Send bug reports, or comments to vaab@free.fr. cer@minas-tirith:~> The idea is, I think, to call dd_rhelp instead of dd_rescue, same syntax: dd_rhelp input output and forget. Maybe what I said about dd_rescue automatically going round only applies to dd_rhelp.
I've been working seriously with client disks for 10 years and I doubt if I've had to invoke either ddrescue or dd_rescue more than a dozen times combined.
I use them because I can abort and continue, and to prevent lost time if there is a bad sector.
One big reason for that is that if a disk is in that bad of shape, I send it out to a professional recovery lab most of the time. Having ddrescue beat a disk to death can just make the situation worse.
Interesting point. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 2017-02-28 22:31, Stevens wrote:
On 02/28/2017 03:20 PM, Wols Lists wrote:
On 28/02/17 20:59, Stevens wrote:
On 02/28/2017 02:37 PM, Felix Miata wrote:
Any reason not to use dd_rescue instead of dd in the first place?
My being totally unfamiliar with dd_rescue probably enters into it.
As far as I am aware, basic ddrescue syntax is identical to dd.
HOWEVER. If you have problems with dd it will leave you up a gum tree. Especially if copying something like a disk drive.
The classic problem with dd aiui, is that if it fails to read, lets say, sector 10 on your old drive, it simply skips that when writing to the new drive, so the old sector 11 becomes the new sector 10. Cue everything after your failed read being scrambled. That's why the default is to abort after a failed read!
Just use ddrescue as if it were dd, and (a) your chances of a successful copy are a lot higher - it has loads of tricks for dealing with dodgy reads, and (b) the copy you end up with will be as perfect as possible - holes where there were failed reads etc.
It will also give you a log of any failed reads if you ask it, so you can (if your fu is good enough) work out what files have been damaged. Hopefully, on the raid list we will soon have a script that will take that log and force soft read failures on the new drive where there was a hard failure on the old one. That will cause any attempt to read a corrupt file to bomb.
Wol - Greg said that the sync option puts zeros where there was a bad sector. Is that not the same as what you are saying about dd_rescue's action? I mean, it would seem to maintain the sector count. I do not know, I have not used either.
That's because dd_rescue uses dd to do the actual job :-) I concur on recommending dd_rescue for this job, for several reasons. It is really easy to use (more than dd). And it brings several advantages. You can do the same that dd_rescue does, by calling dd several times with the appropriate options. dd_rescue simply automates the process for you. If it finds an error, it initially skips it, with the goal of copying as most as possible of the source. Later, it tries to narrow on the error zone trying to copy as most as it can. If there are no errors, then if finishes and you are done. If there are errors, you let it run for a sensible time and abort it when tired of waiting: it will have copied all that was possible. It will display the percent, anyway. In theory, leaving enough time it should finish. Another advantage is that you can abort the process and restart it later from the point it left. Another similar tool is gnu-ddrescue (program ddrescue). This tool was developed later after seeing the success of dd_rescue (I think). It does the same thing with slightly different syntax. I have not made up my mind to which is best. Let's use dd_rescue. syntax: dd_rescue [options] infile outfile so: dd_rescue /dev/sdb /home/you/backups/firstone.img As with dd, be very careful about what destination you tell it to use. Tell it to write to a disk, and it will overwrite it, not caring or warning if it contains data, even if it is the system disk. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 28/02/17 21:31, Stevens wrote:
Wol - Greg said that the sync option puts zeros where there was a bad sector. Is that not the same as what you are saying about dd_rescue's action? I mean, it would seem to maintain the sector count. I do not know, I have not used either.
I've never used ddrescue either. I was unaware of the sync option to dd. I'm guessing :-) that the scenario I describe is what happens if you forget the sync. Either way, it sounds like using ddrescue instead of dd when recovering a hard disk is always the safer option, and you *can* use it as a drop-in even if there are better ways. Certainly the advice of the raid people is *always* use ddrescue when recovering a duff disk, never dd. And with the project I'm trying to get written, ddrescue will let you flag those bad sectors on the *new* disk, which from the raid point of view is a massive help in recovering your data. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Feb 28, 2017 at 3:37 PM, Felix Miata <mrmazda@earthlink.net> wrote:
Greg Freemyer composed on 2017-02-28 15:24 (UTC-0500):
Yes, that will work as long as you run it as root, but if it's that old, you might have a bad sector or two.
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
bs=512 will slow things down, but make sure that if you have an error, only the truly bad sectors will be lost. A sector is 512 bytes and they are either good or bad.
noerror says not to stop just because you hit a failed sector
sync says that if you have a bad sector, fill that part of your backup with zeros.
Any reason not to use dd_rescue instead of dd in the first place?
For whatever reason, I reserve ddrescue / dd_rescue for when I'm seeing major problems with dd. When that happens, I first have to remember which of the 2 different tools I prefer to use (yes they have different logic and syntax). Then I have to think about adding the args unique to it. I almost always would use a log file. I also use various skips and reverse reads. I'm not sure I've ever even tried it on a mostly perfect drive. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-28 22:34, Greg Freemyer wrote:
On Tue, Feb 28, 2017 at 3:37 PM, Felix Miata <> wrote:
Greg Freemyer composed on 2017-02-28 15:24 (UTC-0500):
Any reason not to use dd_rescue instead of dd in the first place?
For whatever reason, I reserve ddrescue / dd_rescue for when I'm seeing major problems with dd.
When that happens, I first have to remember which of the 2 different tools I prefer to use (yes they have different logic and syntax).
Then I have to think about adding the args unique to it. I almost always would use a log file. I also use various skips and reverse reads.
I'm not sure I've ever even tried it on a mostly perfect drive.
I have :-) My backup script images several partitions calling one of the two, I forget which, once for each partition. The main idea is that I can abort and restart my script, and the tools will skip already finished partitions, continuing at the right place :-) It takes a long time to image a 500GB disk over USB2... -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On Tue, Feb 28, 2017 at 6:48 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
I'm not sure I've ever even tried it on a mostly perfect drive.
I have :-)
My backup script images several partitions calling one of the two, I forget which, once for each partition. The main idea is that I can abort and restart my script, and the tools will skip already finished partitions, continuing at the right place :-)
It takes a long time to image a 500GB disk over USB2...
That is an interesting use case. As to the time, I once had to do that over USB1. As I recall it took a couple days! Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-03-01 02:23, Greg Freemyer wrote:
On Tue, Feb 28, 2017 at 6:48 PM, Carlos E. R. <> wrote:
I'm not sure I've ever even tried it on a mostly perfect drive.
I have :-)
My backup script images several partitions calling one of the two, I forget which, once for each partition. The main idea is that I can abort and restart my script, and the tools will skip already finished partitions, continuing at the right place :-)
It takes a long time to image a 500GB disk over USB2...
That is an interesting use case.
And I'm considering using btrfs or zfs with compression... But my rescue media does not support zfs, not possible to add. And btrfs... well.
As to the time, I once had to do that over USB1. As I recall it took a couple days!
Ow! It hurts only to think about it! -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 02/28/2017 09:24 PM, Greg Freemyer wrote:
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
As per [1] (which is referenced from 'dd --help' in newer versions), please also add "iflag=fullblock". [1] http://www.gnu.org/software/coreutils/dd Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 1, 2017 at 1:30 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 02/28/2017 09:24 PM, Greg Freemyer wrote:
At a minimum use this:
dd if=/dev/sdb of=[whatever] bs=512 conv=noerror,sync
As per [1] (which is referenced from 'dd --help' in newer versions), please also add "iflag=fullblock".
[1] http://www.gnu.org/software/coreutils/dd
Have a nice day, Berny
Berny, Since you are the true openSUSE dd expert: Leap 42.2 has the "status=progress" arg shown on that page. That is a favorite argument of mine and I only discovered in Jan. So much better than the old way of having to send it a signal. Thank you for whatever involvement you had in bringing that first to dd, and second to Leap 42.2 Has it been around a long time? Or is it a new addition to the openSUSE family with Leap 42.2? Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/01/2017 12:46 PM, Greg Freemyer wrote:
Leap 42.2 has the "status=progress" arg shown on that page. That is a favorite argument of mine and I only discovered in Jan. So much better than the old way of having to send it a signal.
Thank you for whatever involvement you had in bringing that first to dd, and second to Leap 42.2
Has it been around a long time? Or is it a new addition to the openSUSE family with Leap 42.2?
dd supports "status=progress" since coreutils-8.24, so available upstream since July 2015. Kudos for this feature go to Frederico Simoncelli: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=af2a4ed2 In this case, my involvement was limited to updating the openSUSE package to 8.24. This is the more recent history of coreutils@opensuse: oS version coreutils version openSUSE:11.4 8.9 openSUSE:12.1 8.14 openSUSE:12.2 8.16 openSUSE:12.3 8.17 openSUSE:13.1 8.21 openSUSE:13.2 8.23 Leap42.1 8.22 Leap42.2 8.25 Leap42.3 8.25 oS:TW 8.26 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Mar 1, 2017 at 9:14 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 03/01/2017 12:46 PM, Greg Freemyer wrote:
Leap 42.2 has the "status=progress" arg shown on that page. That is a favorite argument of mine and I only discovered in Jan. So much better than the old way of having to send it a signal.
Thank you for whatever involvement you had in bringing that first to dd, and second to Leap 42.2
Has it been around a long time? Or is it a new addition to the openSUSE family with Leap 42.2?
dd supports "status=progress" since coreutils-8.24, so available upstream since July 2015. Kudos for this feature go to Frederico Simoncelli: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=af2a4ed2
In this case, my involvement was limited to updating the openSUSE package to 8.24. This is the more recent history of coreutils@opensuse:
oS version coreutils version openSUSE:11.4 8.9 openSUSE:12.1 8.14 openSUSE:12.2 8.16 openSUSE:12.3 8.17 openSUSE:13.1 8.21 openSUSE:13.2 8.23 Leap42.1 8.22 Leap42.2 8.25 Leap42.3 8.25 oS:TW 8.26
Good to know I'm fairly current in my knowledge. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Bernhard Voelker -
Carlos E. R. -
Felix Miata -
Greg Freemyer -
Stevens -
Wols Lists