On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
- Derrik
Worked. Thank you!
On 9/21/19 11:24 PM, ToddAndMargo via users wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
- Derrik
Worked. Thank you!
structures were not properly restored on un zipping back to a flash drive , so I had to stick with a raw dd
On 9/22/19 2:23 PM, ToddAndMargo via users wrote:
On 9/21/19 11:24 PM, ToddAndMargo via users wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
- Derrik
Worked. Thank you!
structures were not properly restored on un zipping back to a flash drive , so I had to stick with a raw dd
That would have nothing to do with gzip. Something else went wrong.
On 21Sep2019 23:24, ToddAndMargo ToddAndMargo@zoho.com wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
Worked. Thank you!
FFS. The gzip folks are back to this hubris? When it first came out they tried to usurp the .Z (compress) file extension unstead of using a nonrude '.gz' as they were quickly convinced to.
Please use "gzcat"; "zcat" is for compress/uncompress and if your vendor's installing gzcat as zcat they need a fresh complaint.
Also, for future reference, gunzip behaves as a filter if you don't supply a filename. So:
gunzip < thing.dd.gz | dd ...
and no zcat/gzcat special command usage required.
Cheers, Cameron Simpson cs@cskk.id.au
On 9/22/19 3:49 PM, Cameron Simpson wrote:
On 21Sep2019 23:24, ToddAndMargo ToddAndMargo@zoho.com wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
Worked. Thank you!
FFS. The gzip folks are back to this hubris? When it first came out they tried to usurp the .Z (compress) file extension unstead of using a nonrude '.gz' as they were quickly convinced to.
Please use "gzcat"; "zcat" is for compress/uncompress and if your vendor's installing gzcat as zcat they need a fresh complaint.
zcat from gzip works with .Z files made by compress as well so it's not a problem.
FFS. The gzip folks are back to this hubris? When it first came out they tried to usurp the .Z (compress) file extension unstead of using a nonrude '.gz' as they were quickly convinced to.
Please use "gzcat"; "zcat" is for compress/uncompress and if your vendor's installing gzcat as zcat they need a fresh complaint.
Assuming the OP is on a modern Fedora box, let see what I have on my system here...
$ cat /etc/redhat-release Fedora release 30 (Thirty) $ echo "test" > test.txt $ gzip test.txt $ gzcat test.txt.gz -bash: gzcat: command not found
$ zcat test.txt.gz test $ sudo dnf provides gzcat Error: No Matches found
$ sudo dnf provides zcat *gzip*-1.9-9.fc30.x86_64 : The GNU data compression program Repo : @System Matched from: Provide : /bin/zcat Filename : /usr/bin/zcat ...
Nope, it's zcat, even for gzip files, on modern Linux systems ( at least Redhat based ones ). I've not used gzcat since I retired my last Sun box over 10 years ago.
- Derrik
On 22Sep2019 15:55, Samuel Sieb samuel@sieb.net wrote:
On 9/22/19 3:49 PM, Cameron Simpson wrote:
On 21Sep2019 23:24, ToddAndMargo ToddAndMargo@zoho.com wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
Worked. Thank you!
FFS. The gzip folks are back to this hubris? When it first came out they tried to usurp the .Z (compress) file extension unstead of using a nonrude '.gz' as they were quickly convinced to.
Please use "gzcat"; "zcat" is for compress/uncompress and if your vendor's installing gzcat as zcat they need a fresh complaint.
zcat from gzip works with .Z files made by compress as well so it's not a problem.
That at least is good. - Cameron
On 9/22/19 3:46 PM, Samuel Sieb wrote:
On 9/22/19 2:23 PM, ToddAndMargo via users wrote:
On 9/21/19 11:24 PM, ToddAndMargo via users wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
- Derrik
Worked. Thank you!
structures were not properly restored on un zipping back to a flash drive , so I had to stick with a raw dd
That would have nothing to do with gzip. Something else went wrong.
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
On 9/22/19 5:33 PM, ToddAndMargo via users wrote:
On 9/22/19 3:46 PM, Samuel Sieb wrote:
On 9/22/19 2:23 PM, ToddAndMargo via users wrote:
On 9/21/19 11:24 PM, ToddAndMargo via users wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
- Derrik
Worked. Thank you!
structures were not properly restored on un zipping back to a flash drive , so I had to stick with a raw dd
That would have nothing to do with gzip. Something else went wrong.
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
It doesn't work like that. Whatever gets streamed into gzip is what gets streamed out. If there is any difference, that would be a very serious bug in gzip. It should be no different from a straight dd as long as you are doing the read and write the same way.
On 9/22/19 5:33 PM, ToddAndMargo via users wrote:
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
Can you provide the exact commands you used?
On 9/22/19 6:06 PM, Samuel Sieb wrote:
On 9/22/19 5:33 PM, ToddAndMargo via users wrote:
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
Can you provide the exact commands you used?
# dd status=progress bs=4096 if=/dev/sdx of=DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
# gunzip --to-stdout backup.date.dd.gz | dd status=progress bs=4096 of=/dev/sdx
sdx was sdb in this instance
On 9/22/19 6:00 PM, Samuel Sieb wrote:
On 9/22/19 5:33 PM, ToddAndMargo via users wrote:
On 9/22/19 3:46 PM, Samuel Sieb wrote:
On 9/22/19 2:23 PM, ToddAndMargo via users wrote:
On 9/21/19 11:24 PM, ToddAndMargo via users wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
- Derrik
Worked. Thank you!
structures were not properly restored on un zipping back to a flash drive , so I had to stick with a raw dd
That would have nothing to do with gzip. Something else went wrong.
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
It doesn't work like that. Whatever gets streamed into gzip is what gets streamed out. If there is any difference, that would be a very serious bug in gzip. It should be no different from a straight dd as long as you are doing the read and write the same way.
I am sure the data was exact. The location it put it is another issue.
On 9/22/19 10:07 PM, ToddAndMargo via users wrote:
On 9/22/19 6:06 PM, Samuel Sieb wrote:
On 9/22/19 5:33 PM, ToddAndMargo via users wrote:
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
Can you provide the exact commands you used?
# dd status=progress bs=4096 if=/dev/sdx of=DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
# gunzip --to-stdout backup.date.dd.gz | dd status=progress bs=4096 of=/dev/sdx
Those can't be the actual commands you used because there is no compression involved in the first command, so the second one would give you an error.
On 9/23/19 1:07 PM, ToddAndMargo via users wrote:
On 9/22/19 6:06 PM, Samuel Sieb wrote:
On 9/22/19 5:33 PM, ToddAndMargo via users wrote:
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
Can you provide the exact commands you used?
# dd status=progress bs=4096 if=/dev/sdx of=DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
??? Do you think that giving a file an extension of gz will automatically result in it being gzipped?
# dd status=progress bs=4096 if=/dev/sdg of=DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
# file DeadStick.FC30_2019-09-23.dd.gz DeadStick.FC30_2019-09-23.dd.gz: DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x4,4,1), end-CHS (0x3ff,254,2), startsector 2048, 15685632 sectors
It isn't gzipped.
Have to then
# mv DeadStick.FC30_2019-09-23.dd.gz DeadStick.FC30_2019-09-23.dd # gzip DeadStick.FC30_2019-09-23.dd
# file DeadStick.FC30_2019-09-23.dd.gz DeadStick.FC30_2019-09-23.dd.gz: gzip compressed data, was "DeadStick.FC30_2019-09-23.dd", last modified: Mon Sep 23 05:24:19 2019, from Unix, original size 3737124864
and now it is.
# gunzip --to-stdout backup.date.dd.gz | dd status=progress bs=4096 of=/dev/sdx
???
You've created a file named one thing and are using a different name?
And, if your file wasn't gzipped and you tried to ungzip it you'd get
# gunzip DeadStick.FC30_2019-09-23.dd.gz
gzip: DeadStick.FC30_2019-09-23.dd.gz: not in gzip format
So, did you really provide the "exact" commands you used?
On 9/22/19 10:33 PM, Ed Greshko wrote:
On 9/23/19 1:07 PM, ToddAndMargo via users wrote:
On 9/22/19 6:06 PM, Samuel Sieb wrote:
On 9/22/19 5:33 PM, ToddAndMargo via users wrote:
The same dd restored perfects to another stick. I do believe want went wrong as the partition structures not being written in the right places. So gzip is out. Rats!
Can you provide the exact commands you used?
# dd status=progress bs=4096 if=/dev/sdx of=DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
??? Do you think that giving a file an extension of gz will automatically result in it being gzipped?
Booboo in my notes, now fixed. Thank you!
# dd status=progress bs=4096 if=/dev/sdg of=DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
# file DeadStick.FC30_2019-09-23.dd.gz DeadStick.FC30_2019-09-23.dd.gz: DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x4,4,1), end-CHS (0x3ff,254,2), startsector 2048, 15685632 sectors
It isn't gzipped.
Have to then
# mv DeadStick.FC30_2019-09-23.dd.gz DeadStick.FC30_2019-09-23.dd # gzip DeadStick.FC30_2019-09-23.dd
# file DeadStick.FC30_2019-09-23.dd.gz DeadStick.FC30_2019-09-23.dd.gz: gzip compressed data, was "DeadStick.FC30_2019-09-23.dd", last modified: Mon Sep 23 05:24:19 2019, from Unix, original size 3737124864
and now it is.
# gunzip --to-stdout backup.date.dd.gz | dd status=progress bs=4096 of=/dev/sdx
???
You've created a file named one thing and are using a different name?
It was from my notes.
And, if your file wasn't gzipped and you tried to ungzip it you'd get
# gunzip DeadStick.FC30_2019-09-23.dd.gz
gzip: DeadStick.FC30_2019-09-23.dd.gz: not in gzip format
So, did you really provide the "exact" commands you used?
Digging through my history (which I did not think I still had):
# dd status=progress bs=4096 if=/dev/sdb | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
This is a 64 GB stick. It compressed down to 4 GB, which made senses most of the stick is zeros
# gunzip --to-stdout DeadStick.FC30_2019-09-06.dd.gz | dd status=progress bs=4096 of=/dev/sdb
On Mon, Sep 23, 2019 at 12:50 AM Cameron Simpson cs@cskk.id.au wrote:
On 21Sep2019 23:24, ToddAndMargo ToddAndMargo@zoho.com wrote:
On 9/21/19 10:02 PM, Derrik Walker v2.0 wrote:
Try replacing gunzip with zcat.
Worked. Thank you!
FFS. The gzip folks are back to this hubris? When it first came out they tried to usurp the .Z (compress) file extension unstead of using a nonrude '.gz' as they were quickly convinced to.
Please use "gzcat"; "zcat" is for compress/uncompress and if your vendor's installing gzcat as zcat they need a fresh complaint.
From "gzip(1)": On some systems, zcat may be installed as gzcat to preserve the original link to compress.
[ On the BSDs, both are installed as links to gzip ]
On 9/22/19 11:33 PM, ToddAndMargo via users wrote:
Digging through my history (which I did not think I still had):
# dd status=progress bs=4096 if=/dev/sdb | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
This is a 64 GB stick. It compressed down to 4 GB, which made senses most of the stick is zeros
# gunzip --to-stdout DeadStick.FC30_2019-09-06.dd.gz | dd status=progress bs=4096 of=/dev/sdb
If those are the exact commands you used then the one you wrote to should be identical. What is the problem? If the stick you write to is not the exact same one as the one you read from, the size might not be exactly the same which could cause a problem. You would need to compare the output from dd in both cases.
On 9/23/19 12:45 AM, Samuel Sieb wrote:
On 9/22/19 11:33 PM, ToddAndMargo via users wrote:
Digging through my history (which I did not think I still had):
# dd status=progress bs=4096 if=/dev/sdb | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
This is a 64 GB stick. It compressed down to 4 GB, which made senses most of the stick is zeros
# gunzip --to-stdout DeadStick.FC30_2019-09-06.dd.gz | dd status=progress bs=4096 of=/dev/sdb
If those are the exact commands you used then the one you wrote to should be identical. What is the problem? If the stick you write to is not the exact same one as the one you read from, the size might not be exactly the same which could cause a problem. You would need to compare the output from dd in both cases.
The stick is a dual Legacy, EUFI dual boot install of Fedora 30, x64.
On boot, the new stick recognized EUFI boot, gave me a choice of kernels, then dropped to the emergency prompt.
When I redid it with only a dd and no gzip, joy,
Me things I got everything back, but not in the right physical locations.
On 9/23/19 4:39 PM, ToddAndMargo via users wrote:
On 9/23/19 12:45 AM, Samuel Sieb wrote:
On 9/22/19 11:33 PM, ToddAndMargo via users wrote:
Digging through my history (which I did not think I still had):
# dd status=progress bs=4096 if=/dev/sdb | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
This is a 64 GB stick. It compressed down to 4 GB, which made senses most of the stick is zeros
# gunzip --to-stdout DeadStick.FC30_2019-09-06.dd.gz | dd status=progress bs=4096 of=/dev/sdb
If those are the exact commands you used then the one you wrote to should be identical. What is the problem? If the stick you write to is not the exact same one as the one you read from, the size might not be exactly the same which could cause a problem. You would need to compare the output from dd in both cases.
The stick is a dual Legacy, EUFI dual boot install of Fedora 30, x64.
On boot, the new stick recognized EUFI boot, gave me a choice of kernels, then dropped to the emergency prompt.
When I redid it with only a dd and no gzip, joy,
Me things I got everything back, but not in the right physical locations.
Simple test. But no issues here
# parted /dev/sdg GNU Parted 3.2 Using /dev/sdg Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: JetFlash Transcend 8GB (scsi) Disk /dev/sdg: 8032MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1 1049kB 8032MB 8031MB primary ext4
(parted)
# mount /dev/sdg1 /mnt # ls /mnt lost+found # touch /mnt/x # umount /mnt
# dd status=progress bs=4096 if=/dev/sdg | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
# ll DeadStick.FC30_2019-09-23.dd.gz -rw-r--r--. 1 root root 24337880 Sep 23 18:37 DeadStick.FC30_2019-09-23.dd.gz
# parted /dev/sdg GNU Parted 3.2 Using /dev/sdg Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) rm 1
(parted) print Model: JetFlash Transcend 8GB (scsi) Disk /dev/sdg: 8032MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags
(parted) quit Information: You may need to update /etc/fstab.
# mount /dev/sdg1 /mnt mount: /mnt: special device /dev/sdg1 does not exist.
# gunzip -c DeadStick.FC30_2019-09-23.dd.gz | dd status=progress bs=4096 of=/dev/sdg
# mount /dev/sdg1 /mnt # ls /mnt lost+found x
On 9/23/19 5:17 AM, Ed Greshko wrote:
On 9/23/19 4:39 PM, ToddAndMargo via users wrote:
On 9/23/19 12:45 AM, Samuel Sieb wrote:
On 9/22/19 11:33 PM, ToddAndMargo via users wrote:
Digging through my history (which I did not think I still had):
# dd status=progress bs=4096 if=/dev/sdb | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
This is a 64 GB stick. It compressed down to 4 GB, which made senses most of the stick is zeros
# gunzip --to-stdout DeadStick.FC30_2019-09-06.dd.gz | dd status=progress bs=4096 of=/dev/sdb
If those are the exact commands you used then the one you wrote to should be identical. What is the problem? If the stick you write to is not the exact same one as the one you read from, the size might not be exactly the same which could cause a problem. You would need to compare the output from dd in both cases.
The stick is a dual Legacy, EUFI dual boot install of Fedora 30, x64.
On boot, the new stick recognized EUFI boot, gave me a choice of kernels, then dropped to the emergency prompt.
When I redid it with only a dd and no gzip, joy,
Me things I got everything back, but not in the right physical locations.
Simple test. But no issues here
# parted /dev/sdg GNU Parted 3.2 Using /dev/sdg Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: JetFlash Transcend 8GB (scsi) Disk /dev/sdg: 8032MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1 1049kB 8032MB 8031MB primary ext4
(parted)
# mount /dev/sdg1 /mnt # ls /mnt lost+found # touch /mnt/x # umount /mnt
# dd status=progress bs=4096 if=/dev/sdg | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
# ll DeadStick.FC30_2019-09-23.dd.gz -rw-r--r--. 1 root root 24337880 Sep 23 18:37 DeadStick.FC30_2019-09-23.dd.gz
# parted /dev/sdg GNU Parted 3.2 Using /dev/sdg Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) rm 1
(parted) print Model: JetFlash Transcend 8GB (scsi) Disk /dev/sdg: 8032MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags
(parted) quit Information: You may need to update /etc/fstab.
# mount /dev/sdg1 /mnt mount: /mnt: special device /dev/sdg1 does not exist.
# gunzip -c DeadStick.FC30_2019-09-23.dd.gz | dd status=progress bs=4096 of=/dev/sdg
# mount /dev/sdg1 /mnt # ls /mnt lost+found x
You need to complicate up your partition structure and try it again.
# parted /dev/sdb GNU Parted 3.2 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: Samsung Type-C (scsi) Disk /dev/sdb: 64.2GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:
Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 212MB 210MB fat16 EFI System Partition boot, esp 3 212MB 1286MB 1074MB ext4 4 1286MB 61.9GB 60.7GB ext4 5 61.9GB 64.2GB 2220MB linux-swap(v1) swap
(parted) quit
On 9/24/19 9:14 AM, ToddAndMargo via users wrote:
You need to complicate up your partition structure and try it again.
# parted /dev/sdb GNU Parted 3.2 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: Samsung Type-C (scsi) Disk /dev/sdb: 64.2GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:
Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 212MB 210MB fat16 EFI System Partition boot, esp 3 212MB 1286MB 1074MB ext4 4 1286MB 61.9GB 60.7GB ext4 5 61.9GB 64.2GB 2220MB linux-swap(v1) swap
(parted) quit
OK.... I only have a cheap 8GB flash drive available for this purpose.
# parted /dev/sdg GNU Parted 3.2 Using /dev/sdg Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: JetFlash Transcend 8GB (scsi) Disk /dev/sdg: 8032MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:
Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB ext4 2 2097kB 222MB 220MB fat16 boot, esp 3 222MB 1348MB 1126MB ext4 4 1348MB 5543MB 4194MB ext4 5 5543MB 8031MB 2488MB linux-swap(v1) swap
# mount /dev/sdg3 /mnt # ls /mnt lost+found world
# umount /mnt
# dd status=progress bs=4096 if=/dev/sdg | gzip -v > DeadStick.FC30_$(date +%Y-%m-%d).dd.gz
[root@meimei ~]# parted /dev/sdg GNU Parted 3.2 Using /dev/sdg Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel gpt Warning: The existing disk label on /dev/sdg will be destroyed and all data on this disk will be lost. Do you want to continue? Yes/No? y (parted) print Model: JetFlash Transcend 8GB (scsi) Disk /dev/sdg: 8032MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:
Number Start End Size File system Name Flags
(parted) quit Information: You may need to update /etc/fstab.
# gunzip -c DeadStick.FC30_2019-09-24.dd.gz | dd status=progress bs=4096 of=/dev/sdg
# mount /dev/sdg3 /mnt # ls /mnt lost+found world
-
Cameron Simpson -
Derrik Walker v2.0 -
Ed Greshko -
Samuel Sieb -
ToddAndMargo -
Tom H