[opensuse] Creating the distro USB stick with a simple 'cp'
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, A chap at the forums had failed to create the usb stick for installation following several published procedures. But he succeeded with this one: # cp image.iso /dev/sdX # sync And that's it! No more 'dd', or imagewrite, whatever. Just a cp to the raw device, umounted. Someone can explain why it works? Or why it should not work? Do we want to plublish this method on our wiki (for 13.1)? :-) He took the idea from here: http://superuser.com/questions/620877/cp-command-to-make-bootable-iso-image-... The forum thread is here: View this thread: http://forums.opensuse.org/showthread.php?t=489025 - -- Cheers Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIBWQIACgkQja8UbcUWM1x06gD/cj8JJr6bLSMtkilnAt3nuiBi rMVA+GtNft2TbekxMZYA/0qBRgRHy+jQBtAiQzAM1RcwDMQYENdV322PbGeeWHDT =Jxbn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/6/2013 1:13 PM, Carlos E. R. wrote:
Hi,
A chap at the forums had failed to create the usb stick for installation following several published procedures. But he succeeded with this one:
# cp image.iso /dev/sdX # sync
And that's it! No more 'dd', or imagewrite, whatever. Just a cp to the raw device, umounted.
Someone can explain why it works? Or why it should not work?
It worked because what ever Operating System he plugged it into knew how to mount an ISO as a loop-back device. In other words, it shouldn't have worked, but it did on his machine and may on yours, but probably won't on many others. In a perfect world he would not get to write onto a device mounted via loop, but who knows. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-06 a las 13:19 -0700, John Andersen escribió:
On 8/6/2013 1:13 PM, Carlos E. R. wrote:
Someone can explain why it works? Or why it should not work?
It worked because what ever Operating System he plugged it into knew how to mount an ISO as a loop-back device.
In other words, it shouldn't have worked, but it did on his machine and may on yours, but probably won't on many others.
In a perfect world he would not get to write onto a device mounted via loop, but who knows.
The ISO was not mounted at all, loop or otherwise. Loop is not involved in this. The stick was not mounted at all, either. It is a raw copy, despite the appeareances, not a file copy. At least, it works on Debian, Ubuntu, and openSUSE. I just did the reverse operation: # umount /media/openSUSE\ 12.3\ Live/ # time cp /dev/sdd image_cp real 1m46.887s user 0m0.069s sys 0m11.177s # # time dd if=/dev/sdd of=image_dd 3919872+0 records in 3919872+0 records out 2006974464 bytes (2.0 GB) copied, 103.094 s, 19.5 MB/s real 1m43.488s user 0m1.127s sys 0m24.280s # # cmp image_cp image_dd # Same image, success. interestingly, cp uses less CPU time. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIBYI8ACgkQja8UbcUWM1zBVwD/dgF2MewDr75c+/s4lqcZIvNn k+x1K2MmbcowxnsyyRcA/i8X1GdfxHbVkGahzPWgpJt0Vq7lnLpufgqgt+qJW+9O =qcvc -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
В Tue, 6 Aug 2013 22:13:38 +0200 (CEST)
"Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
A chap at the forums had failed to create the usb stick for installation following several published procedures. But he succeeded with this one:
# cp image.iso /dev/sdX # sync
And that's it! No more 'dd',
Well, dd is cp on steroids. There is no difference between "dd if=image.iso of=/dev/sdX" and "cp image.iso /dev/sdX" as long as no special alignment or block size is needed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIBstAACgkQR6LMutpd94z/UgCgoM6TKDMmKtao2MfniJQpu8e+ 4K8AoMYQjowlhg+7razDYqz2mUYXoFKn =EeUu -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-07 a las 06:36 +0400, Andrey Borzenkov escribió:
В Tue, 6 Aug 2013 22:13:38 +0200 (CEST) "Carlos E. R." <> пишет:
# cp image.iso /dev/sdX # sync
And that's it! No more 'dd',
Well, dd is cp on steroids. There is no difference between "dd if=image.iso of=/dev/sdX" and "cp image.iso /dev/sdX" as long as no special alignment or block size is needed.
Ok... Then I think we can go ahead and add this method to our wiki. The syntax is a bit easier than with dd. The danger is about the same, a mistake in the device name, PUFF! - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlICGa4ACgkQja8UbcUWM1wmjwD/drPpJg6wpUC/XykRwIzTUKz3 RWfT6Sh1lTTWxiNGbxEA/iCIgdb5GGzDo1BQI7uez4MsdxGtu26ASeBKd0a1lsNe =8XUC -----END PGP SIGNATURE-----
"Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-07 a las 06:36 +0400, Andrey Borzenkov escribió:
В Tue, 6 Aug 2013 22:13:38 +0200 (CEST) "Carlos E. R." <> пишет:
# cp image.iso /dev/sdX # sync
And that's it! No more 'dd',
Well, dd is cp on steroids. There is no difference between "dd if=image.iso of=/dev/sdX" and "cp image.iso /dev/sdX" as long as no special alignment or block size is needed.
Ok...
Then I think we can go ahead and add this method to our wiki. The syntax is a bit easier than with dd. The danger is about the same, a mistake in the device name, PUFF!
- -- Cheers
Carlos, In my professional world we work with media images (an iso is a specific type of media images). To keep them manageable we often break them into segments of 2 gb or less: image.001, image.002, etc. The well known/tested restore command is cat image.* > /dev/sdx At least to me that is more natural than cp. I suggest you put cat on the wiki, but not cp. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-07 a las 08:13 -0400, Greg Freemyer escribió:
"Carlos E. R." <> wrote:
The well known/tested restore command is
cat image.* > /dev/sdx
Yes... I forgot I had used that, time ago.
At least to me that is more natural than cp. I suggest you put cat on the wiki, but not cp.
Or both :-) What I wonder is why only dd is in the current instructions. Well, and imagewriter. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlICiUYACgkQja8UbcUWM1zOpwEAkBaQK5SCWcDlmgwcOBTi52bq GCjynoeoUJ3I9chKh9wA+wbQQOoelykaVlAQi6o0iuSqvS+oA8tGwDi6qkAlrONA =A3+3 -----END PGP SIGNATURE-----
On 8/7/2013 2:55 AM, Carlos E. R. wrote:
# cp image.iso /dev/sdX # sync
And that's it! No more 'dd',
Well, dd is cp on steroids. There is no difference between "dd if=image.iso of=/dev/sdX" and "cp image.iso /dev/sdX" as long as no special alignment or block size is needed.
I think that this is a largely unknown feature of CP (or Cat) and you have to dig pretty deeply in the man page to find even the hint that it would work. In fact a device as a target for cp is really only addressed in man 1p cp because it seems to be a largely forgotten posix feature, where by if the destination function doesn't exist cp tries to obtain a file descriptor via an open function. See item 3b in that man page. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-07 a las 08:13 -0400, Greg Freemyer escribió:
"Carlos E. R." <> wrote:
The well known/tested restore command is
cat image.* > /dev/sdx
Yes... I forgot I had used that, time ago.
At least to me that is more natural than cp. I suggest you put cat on the wiki, but not cp.
Or both :-)
What I wonder is why only dd is in the current instructions.
Because 'dd' is the tool typically used for that sort of thing. 'cp' and 'cat' in that context are at least a bit unusual. Besides, there isn't really much gained by adding two alternatives .... -- Per Jessen, Zürich (18.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
Carlos E. R. wrote:
What I wonder is why only dd is in the current instructions.
Because 'dd' is the tool typically used for that sort of thing. 'cp' and 'cat' in that context are at least a bit unusual. Besides, there isn't really much gained by adding two alternatives ....
Well, one poster at the forum failed to create the stick by any of our published methods, and succeeded using 'cp'. I guess that he mistyped something, but I can't be sure. The cp syntax is a tiny bit easier, perhaps... :-? - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIDaCQACgkQtTMYHG2NR9Ux+wCeP71zA1gfd+bqxeMA12SfJmAN pl0An0FiIw+BYTFqhkyYSX68MTvJFLko =5lSU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-07 a las 08:13 -0400, Greg Freemyer escribió:
"Carlos E. R." <> wrote:
The well known/tested restore command is
cat image.* > /dev/sdx
Yes... I forgot I had used that, time ago.
At least to me that is more natural than cp. I suggest you put cat on the wiki, but not cp.
Or both :-)
What I wonder is why only dd is in the current instructions.
Because 'dd' is the tool typically used for that sort of thing. 'cp' and 'cat' in that context are at least a bit unusual. Besides, there isn't really much gained by adding two alternatives ....
I argue cat can concatenate files if needed so it offers a unique feature. Maintaining large media images in segmented files offers storage (and other) flexibility and is what I routinely do, so cat is my solution of choice. Thumb drives are growing and so are susestudio download images. A recent one I built was 16gb. (I hope something went wrong, but that's what it said.) Fyi:one reason I like more manageable file sizes is I tend to verify their md5 hash every time I copy them. Even with disk to disk copying errors can be introduced on occasion. Re- copying a 2gb file is easier than a 640gb file. (I am a currently working with a set of 7 640gb media images). Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/07/2013 08:51 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-07 a las 08:13 -0400, Greg Freemyer escribió:
"Carlos E. R." <> wrote:
The well known/tested restore command is
cat image.* > /dev/sdx
Yes... I forgot I had used that, time ago.
At least to me that is more natural than cp. I suggest you put cat on the wiki, but not cp.
Or both :-) _____________
- cat image.* > /dev/sdx works just fine with openSuse also Mint But, does not work for Knoppix : any ideas why not ? thanks best regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
ellanios82 wrote:
On 08/07/2013 08:51 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-08-07 a las 08:13 -0400, Greg Freemyer escribió:
"Carlos E. R." <> wrote:
The well known/tested restore command is
cat image.* > /dev/sdx
Yes... I forgot I had used that, time ago.
At least to me that is more natural than cp. I suggest you put cat on the wiki, but not cp.
Or both :-) _____________
- cat image.* > /dev/sdx works just fine with openSuse also Mint
But, does not work for Knoppix : any ideas why not ?
Well, what _does_ it do on Knoppix? -- Per Jessen, Zürich (19.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/08/2013 05:31 PM, Per Jessen wrote: > ellanios82 wrote: > >> On 08/07/2013 08:51 PM, Carlos E. R. wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> >>> >>> El 2013-08-07 a las 08:13 -0400, Greg Freemyer escribió: >>>> "Carlos E. R." <> wrote: >>>> The well known/tested restore command is >>>> >>>> cat image.* > /dev/sdx >>> Yes... I forgot I had used that, time ago. >>> >>> >>>> At least to me that is more natural than cp. I suggest you put cat >>>> on the wiki, but not cp. >>> Or both :-) >>> _____________ >> - cat image.* > /dev/sdx works just fine with openSuse also Mint >> >> But, does not work for Knoppix : any ideas why not ? > Well, what _does_ it do on Knoppix? ________________________ On Knoppix one selects Boot Device : USB SanDisk - after consulting its self for a few moments, the PC shows Yast created Boot Menu for boot from Hard Disk ............ best regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-08-08 at 20:14 +0300, ellanios82 wrote:
On 08/08/2013 05:31 PM, Per Jessen wrote:
ellanios82 wrote:
- cat image.* > /dev/sdx works just fine with openSuse also Mint
But, does not work for Knoppix : any ideas why not ? Well, what _does_ it do on Knoppix?
On Knoppix one selects Boot Device : USB SanDisk
- after consulting its self for a few moments, the PC shows Yast created Boot Menu for boot from Hard Disk
I don't think that can be an answer to the question. :-? How can you get "Yast created Boot Menu" in a Knoppix system? - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIEL5kACgkQtTMYHG2NR9UOpgCfeg5s/zkPlS865crQLM+kiZox FU8An21BrUSFgUOQGp70f8D9N04WpQAa =rIaI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2013 02:53 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 20:14 +0300, ellanios82 wrote:
On 08/08/2013 05:31 PM, Per Jessen wrote:
ellanios82 wrote:
- cat image.* > /dev/sdx works just fine with openSuse also Mint
But, does not work for Knoppix : any ideas why not ? Well, what _does_ it do on Knoppix?
On Knoppix one selects Boot Device : USB SanDisk
- after consulting its self for a few moments, the PC shows Yast created Boot Menu for boot from Hard Disk
I don't think that can be an answer to the question. :-?
How can you get "Yast created Boot Menu" in a Knoppix system?
~ put another way . . . it is not possible to boot Knoppix from USB : after attempt to boot from USB one is returned to openSUSE 12.3 boot menu ...................... best regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2013-08-09 at 08:47 +0300, ellanios82 wrote:
~ put another way . . . it is not possible to boot Knoppix from USB : after attempt to boot from USB one is returned to openSUSE 12.3 boot menu
Ok, but the proposal of using cp or cat to create the stick is for the openSUSE stick, not any other. The question is if you run the cp or cat sequence on an already running Knoppix machine (or whatever Linux) can create an openSUSE stick, or if it fails. It is never suggested you create a Knoppix stick. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIE3KcACgkQtTMYHG2NR9WfPgCfaNmxH+44bvKhqF1VWhmigd+c /9YAn3DFZjkoXD1H7wzcUa5xic+s6V18 =I73E -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
ellanios82 wrote:
~ put another way . . . it is not possible to boot Knoppix from USB : after attempt to boot from USB one is returned to openSUSE 12.3 boot menu
If you want to create a USB stick to boot Knoppix, follow the instructions in the lower part of http://www.knopper.net/knoppix/knoppix-flash-en.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2013 03:24 PM, Dave Howorth wrote:
ellanios82 wrote:
~ put another way . . . it is not possible to boot Knoppix from USB : after attempt to boot from USB one is returned to openSUSE 12.3 boot menu If you want to create a USB stick to boot Knoppix, follow the instructions in the lower part of http://www.knopper.net/knoppix/knoppix-flash-en.html
- many thanks . . . it is not that i wish to run Knoppix, but, rather that one is puzzled, why it should be that one is able to create a bootable usb stick for openSUSE and Mint using methods like dd , cat , cp but these methods do not work for makinga bootable usb stick for Knoppix . . . just wondering what might be so different with Knoppix best regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2013-08-10 at 08:55 +0300, ellanios82 wrote:
but these methods do not work for makinga bootable usb stick for Knoppix . . . just wondering what might be so different with Knoppix
Because the openSUSE image is prepared as directly bootable. Others have to add themselves a booting mechanism. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIH9XsACgkQtTMYHG2NR9X8wgCeOtJvT397Q5Gq7u6gFVgKTlXI k/4AnReeIqXKcPuHbiKG35jeM5as3akz =i+Hn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/7/2013 8:13 AM, Greg Freemyer wrote:
To keep them manageable we often break them into segments of 2 gb or less: image.001, image.002, etc.
The well known/tested restore command is
cat image.* > /dev/sdx
You really rely on the shell globbing expansion to set the proper order of the pieces? -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
Carlos E. R. wrote:
What I wonder is why only dd is in the current instructions.
Because 'dd' is the tool typically used for that sort of thing. 'cp' and 'cat' in that context are at least a bit unusual. Besides, there isn't really much gained by adding two alternatives ....
Well, one poster at the forum failed to create the stick by any of our published methods, and succeeded using 'cp'. I guess that he mistyped something, but I can't be sure.
The cp syntax is a tiny bit easier, perhaps... :-?
The fact that using the wrong tool for a given job happened to work once, even while a particular user failed for unknown reasons to use the right tool, does not change the fact that it is really the wrong tool for that job. A user may fail to get lumber home in a truck with a manual transmission because he doesn't know how to work a clutch and manual gears, and succeed by sticking it on top of his car which has an automatic transmission, yet the car was still the wrong tool for that job and you should never actually write down documentation that mis-educates new people about the best way to transport lumber. cp "happened to work" in this case because of the particulars of the version of cp, the os, etc. But writing raw images to device nodes in an exact, reproducible, predictable manner is not an advertised function of cp. So if it worked, it was by happenstance. Even if it worked 500 times on every version of linux available right now, that is still happenstance. All those versions of linux still probably derive their version of cp from the same gnu base, with the only differences being age. While dd is specifically made to do exactly that. It doesn't just happen to work for that also. Probably the main difference behind the scenes is the assurance that dd will write one byte after another contiguously, no skipping around to use free blocks wherever they may be. Cp apparently just happens to end up doing that too if the target is not a file, but, it's still not how cp is documented, and relying on undocumented behaviour like that is simply a bad habit. Relying on behavior that is inconsistent with the norm is also a bad habit that will tend to mess up and confuse people later. It's better to get the proper understanding of what cp does in the normal case and leave it at that. For instance, the new user does this cp operation and sees that it works. Later they may be surprised to discover the hard way after who knows how much head banging and wasted time, that cp does not write contiguous blocks even though it did when writing to a device. Call it simply "best practices" if you want a shorter way to explain why one tool is used and not another. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Aug 13, 2013 at 4:05 PM, Brian K. White
On 8/7/2013 8:13 AM, Greg Freemyer wrote:
To keep them manageable we often break them into segments of 2 gb or less: image.001, image.002, etc.
The well known/tested restore command is
cat image.* > /dev/sdx
You really rely on the shell globbing expansion to set the proper order of the pieces?
It's a documented / well defined ordering. The pieces are named such that they fit glob expansion ordering rules. image.001, image.002, ..., image.999 So yes. fyi: I do manually review all the pieces to make sure there are not any extraneous files that might get picked up. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/2013 1:27 PM, Brian K. White wrote:
The fact that using the wrong tool for a given job happened to work once,
I would like to see some evidence that CP is in fact the wrong tool. Seems to me this functionality (cp file to a device) is referenced at least in passing in man (1p) cp. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/2013 5:04 PM, John Andersen wrote:
On 8/13/2013 1:27 PM, Brian K. White wrote:
The fact that using the wrong tool for a given job happened to work once,
I would like to see some evidence that CP is in fact the wrong tool.
Seems to me this functionality (cp file to a device) is referenced at least in passing in man (1p) cp.
It's "wrong" for at least this reason: Today user is told: "Here is how you write a disk image: cp img.file /dev/node" Tomorrow user want's to copy or write a similar disk image to a file for use in a vm or to recover a physical disk. He tries "cp /dev/node image.file" and it does not work. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/13/2013 04:27 PM, Brian K. White wrote:
On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
/snip/
But writing raw images to device nodes in an exact, reproducible, predictable manner is not an advertised function of cp. So if it worked, it was by happenstance. Even if it worked 500 times on every version of linux available right now, that is still happenstance. All those versions of linux still probably derive their version of cp from the same gnu base, with the only differences being age.
While dd is specifically made to do exactly that. It doesn't just happen to work for that also.
Probably the main difference behind the scenes is the assurance that dd will write one byte after another contiguously, no skipping around to use free blocks wherever they may be.
/snip/ I was recently advised to use rsync to do something like this. I tried it on a test--a portable drive--and it didn't work. Maybe I did it wrong, I don't know. What I want to do is to copy partitions (one at a time) to another drive with a different set of partitions, just a bit bigger. (And numbered differently, leaving out some that will not be used in the future. One reason is that the present drive partitioning scheme has unusable spaces where I cannot expand into them. I want to make a clean partitioning setup on another drive--actually an SSD, in the final cut. Will DD do that, or will it choke on having partitions of a different size, and different number? (IE., what is now sda8 may become sdb5, and so on, and then when that drive is mounted as the only drive, it will, I hope, be sda5.) --doug -- Blessed are the peacemakers..for they shall be shot at from both sides. --A.M.Greeley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/2013 6:16 PM, Doug wrote:
On 08/13/2013 04:27 PM, Brian K. White wrote:
On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
/snip/
But writing raw images to device nodes in an exact, reproducible, predictable manner is not an advertised function of cp. So if it worked, it was by happenstance. Even if it worked 500 times on every version of linux available right now, that is still happenstance. All those versions of linux still probably derive their version of cp from the same gnu base, with the only differences being age.
While dd is specifically made to do exactly that. It doesn't just happen to work for that also.
Probably the main difference behind the scenes is the assurance that dd will write one byte after another contiguously, no skipping around to use free blocks wherever they may be.
/snip/
I was recently advised to use rsync to do something like this. I tried it on a test--a portable drive--and it didn't work. Maybe I did it wrong, I don't know. What I want to do is to copy partitions (one at a time) to another drive with a different set of partitions, just a bit bigger. (And numbered differently, leaving out some that will not be used in the future. One reason is that the present drive partitioning scheme has unusable spaces where I cannot expand into them. I want to make a clean partitioning setup on another drive--actually an SSD, in the final cut.
Will DD do that, or will it choke on having partitions of a different size, and different number? (IE., what is now sda8 may become sdb5, and so on, and then when that drive is mounted as the only drive, it will, I hope, be sda5.)
--doug
You can proceed a few different ways. The best way is probably create new empty filesystems manually on the new partitions, then use rsync to copy all your files over to them. The advantage here is that rsync is resumable (if you abort in the middle, it doesn't have to start over from the beginning), and it works for any kind of fs as long as you can mount that fs in linux. Another way is dd the old fs to the new partition, then use whichever utilities are appropriate for the fs type to grow the fs to fill the new space. Not all fs's are growable but the common current linux ones are. At least ext3, ext4, reiser. They don't all use the same command, ie there isn't a growfs command. ext3/4 has resize2fs, reiser has resize_reiserfs, xfs probably has something, btrfs probably has something, etc. This all also assumes you aren't using lvm. This way might work if you had a non-linux fs from some other OS where you can't mount or resize the fs from linux, but you can dd any block of disk bytes, and then maybe the other OS can resize it's own fs itself later. Generally, copying a fs to a larger partition or whole device (no partition table) does not affect the fs at all, it still works fine exactly as before. But it also does not use the extra space. You have to resize the fs to use the extra space. Not all fs types can be resized. Some can be resized but maybe there is no linux utility to do it, or not a safe one anyways. Some can only be grown and never shrunk, some can be grown or shrunk. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/2013 2:12 PM, Brian K. White wrote:
On 8/13/2013 5:04 PM, John Andersen wrote:
On 8/13/2013 1:27 PM, Brian K. White wrote:
The fact that using the wrong tool for a given job happened to work once,
I would like to see some evidence that CP is in fact the wrong tool.
Seems to me this functionality (cp file to a device) is referenced at least in passing in man (1p) cp.
It's "wrong" for at least this reason:
Today user is told: "Here is how you write a disk image: cp img.file /dev/node"
Tomorrow user want's to copy or write a similar disk image to a file for use in a vm or to recover a physical disk. He tries "cp /dev/node image.file" and it does not work.
But it Does Work. Grab some random cdrom, figure out what your cdrom drive is Enter # cp /dev/sr0 big.iso # mount big.iso /mnt -o loop Works perfectly. So its RIGHT, and further, its posix. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/2013 7:15 PM, John Andersen wrote:
On 8/13/2013 2:12 PM, Brian K. White wrote:
On 8/13/2013 5:04 PM, John Andersen wrote:
On 8/13/2013 1:27 PM, Brian K. White wrote:
The fact that using the wrong tool for a given job happened to work once,
I would like to see some evidence that CP is in fact the wrong tool.
Seems to me this functionality (cp file to a device) is referenced at least in passing in man (1p) cp.
It's "wrong" for at least this reason:
Today user is told: "Here is how you write a disk image: cp img.file /dev/node"
Tomorrow user want's to copy or write a similar disk image to a file for use in a vm or to recover a physical disk. He tries "cp /dev/node image.file" and it does not work.
But it Does Work.
Grab some random cdrom, figure out what your cdrom drive is Enter
# cp /dev/sr0 big.iso # mount big.iso /mnt -o loop
Works perfectly.
So its RIGHT, and further, its posix.
No it does not work. That particular example may work, but copying a file does not in any way guarantee that disk blocks are used in any specific order. Sometimes that doesn't matter, sometimes it does. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/13/2013 06:39 PM, Brian K. White wrote:
On 8/13/2013 6:16 PM, Doug wrote:
On 08/13/2013 04:27 PM, Brian K. White wrote:
On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
/snip/
I was recently advised to use rsync to do something like this. I tried it on a test--a portable drive--and it didn't work. Maybe I did it wrong, I don't know.
Nothing copied. This was my first (and only) experience trying to use rsync.
What I want to do is to copy partitions (one at a time) to another drive with a different set of partitions, just a bit bigger. (And numbered differently, leaving out some that will not be used in the future. One reason is that the present drive partitioning scheme has unusable spaces where I cannot expand into them. I want to make a clean partitioning setup on another drive--actually an SSD, in the final cut.
Will DD do that, or will it choke on having partitions of a different size, and different number? (IE., what is now sda8 may become sdb5, and so on, and then when that drive is mounted as the only drive, it will, I hope, be sda5.)
--doug
You can proceed a few different ways.
The best way is probably create new empty filesystems manually on the new partitions, then use rsync to copy all your files over to them. The advantage here is that rsync is resumable (if you abort in the middle, it doesn't have to start over from the beginning), and it works for any kind of fs as long as you can mount that fs in linux.
Another way is dd the old fs to the new partition, then use whichever utilities are appropriate for the fs type to grow the fs to fill the new space. Not all fs's are growable but the common current linux ones are. At least ext3, ext4, reiser. They don't all use the same command, ie there isn't a growfs command. ext3/4 has resize2fs, reiser has resize_reiserfs, xfs probably has something, btrfs probably has something, etc. This all also assumes you aren't using lvm. This way might work if you had a non-linux fs from some other OS where you can't mount or resize the fs from linux, but you can dd any block of disk bytes, and then maybe the other OS can resize it's own fs itself later.
Generally, copying a fs to a larger partition or whole device (no partition table) does not affect the fs at all, it still works fine exactly as before. But it also does not use the extra space. You have to resize the fs to use the extra space. Not all fs types can be resized. Some can be resized but maybe there is no linux utility to do it, or not a safe one anyways. Some can only be grown and never shrunk, some can be grown or shrunk.
I was intending to format the partitions on the new drive with ext4 (for Linux) and NTFS (for Windows 8) so that the DDd files would arrive on formatted space, and the rest of the partition would be usable, being formatted and empty. I get the impression that I'm missing something here--please explain. Is there a difference between what you call a file system, and what I call a formatted partition? If so, what? Thanx--doug -- Blessed are the peacemakers..for they shall be shot at from both sides. --A.M.Greeley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/2013 8:21 PM, Doug wrote:
On 08/13/2013 06:39 PM, Brian K. White wrote:
On 8/13/2013 6:16 PM, Doug wrote:
On 08/13/2013 04:27 PM, Brian K. White wrote:
On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
/snip/
I was recently advised to use rsync to do something like this. I tried it on a test--a portable drive--and it didn't work. Maybe I did it wrong, I don't know.
Nothing copied. This was my first (and only) experience trying to use rsync.
What I want to do is to copy partitions (one at a time) to another drive with a different set of partitions, just a bit bigger. (And numbered differently, leaving out some that will not be used in the future. One reason is that the present drive partitioning scheme has unusable spaces where I cannot expand into them. I want to make a clean partitioning setup on another drive--actually an SSD, in the final cut.
Will DD do that, or will it choke on having partitions of a different size, and different number? (IE., what is now sda8 may become sdb5, and so on, and then when that drive is mounted as the only drive, it will, I hope, be sda5.)
--doug
You can proceed a few different ways.
The best way is probably create new empty filesystems manually on the new partitions, then use rsync to copy all your files over to them. The advantage here is that rsync is resumable (if you abort in the middle, it doesn't have to start over from the beginning), and it works for any kind of fs as long as you can mount that fs in linux.
Another way is dd the old fs to the new partition, then use whichever utilities are appropriate for the fs type to grow the fs to fill the new space. Not all fs's are growable but the common current linux ones are. At least ext3, ext4, reiser. They don't all use the same command, ie there isn't a growfs command. ext3/4 has resize2fs, reiser has resize_reiserfs, xfs probably has something, btrfs probably has something, etc. This all also assumes you aren't using lvm. This way might work if you had a non-linux fs from some other OS where you can't mount or resize the fs from linux, but you can dd any block of disk bytes, and then maybe the other OS can resize it's own fs itself later.
Generally, copying a fs to a larger partition or whole device (no partition table) does not affect the fs at all, it still works fine exactly as before. But it also does not use the extra space. You have to resize the fs to use the extra space. Not all fs types can be resized. Some can be resized but maybe there is no linux utility to do it, or not a safe one anyways. Some can only be grown and never shrunk, some can be grown or shrunk.
I was intending to format the partitions on the new drive with ext4 (for Linux) and NTFS (for Windows 8) so that the DDd files would arrive on formatted space, and the rest of the partition would be usable, being formatted and empty. I get the impression that I'm missing something here--please explain. Is there a difference between what you call a file system, and what I call a formatted partition? If so, what?
Thanx--doug
A filesystem is the formatting, but it need not be in a partition. It can be on a whole device (like a floppy, only you can do it to anything like a hard drive or a thumb drive or a ramdisk) or inside of a file. dd does not copy files it copies raw data. That data may or may not come from a file or go into a file, the point is dd doesn't know or care what the data is. If you use dd to copy a filesystem, you are not "dding the files" you are dding one big solid hunk of raw meaningless data called the entire filesystem. dd does not know about all the individual files inside in the way that tar or cp or rsync or winzip does. The filesystem is the "formatted partition" in one sense, in the sense that it is the formatting that usually occupies an entire partition. When you format a partition in windows, what is happening is windows creates an ntfs or fat32 filesystem But a filesystem is also not a "formatted partition" in the sense that it is not the partition itself, just the data that was written to the partition. The partition is just an arbitrary block of disk space which is defined by the partition table. It's not really accurate to think of "formatting the partition" because for instance you can "format" just a part of a partition if you wanted to. You could write a filesystem that only uses 800 gigs of a 1tb partition. Is that partition then "formatted"? Normally you would not do that but the distinction still matters because of your own current project. You have an old drive that currently shows up as /dev/sda and a new larger drive that shows up as /dev/sdb. The old drive has a partition /dev/sda1 which is 500 gigs, 100% filled with a 500 gig ext3 filesystem. The new drive has no partitions and no filesystems. You create a partition table and make a 1.5tb partition on it. Now you have a /dev/sdb1 that is 1.5tb but it has no filesystem yet. Instead of running "mkfs /dev/sdb1" to create one you use dd to copy the old one: dd if=/dev/sda1 of=/dev/sdb1 What happened was, the first 500G of /dev/sdb1 now has a carbon copy of /dev/sda1, followed by 1T of blank space. Not only is it blank, it's "invisible" to most utilities. If you mount the new copy: mount /dev/sdb1 /mnt Then look at /mnt, you will see that there is only 500G of space total in /mnt. df -h /mnt will show something like this: # df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/sdb1 512M 358M 154M 70% /mnt That empty space is not merely unused like the 154M available above. It's not even available, because it lies outside the filesystem. In the old old days, you couldn't resize filesystems, you could only make new ones and copy files from one to another. Today the popular filesystems can mostly be resized. So now you can use resize2fs to resize /dev/sdb1 to fill up the new larger partition it is in. After that, the df command will show you that the Size and Avail are larger. rsync would be a different story. rsync DOES work on individual files. One reason to use rsync (or cp or tar or cpio or any of the backup programs) instead of dd, would be that if you copy the individual files instead of the whole flsystem, then the new filesystem can be a different type than the old one, as well as a different size. For instance, say the old filesystem is ext2. If you wanted the new fs to be ext3 or ext4 then you can upgrade an existing ext* to any higher version in-place, but that's a special case. In any other case, say you want the new filesystem to be reiserfs or xfs or btrfs or zfs, there is no way to convert one fs to another. So you couldn't copy the old fs with dd and then convert it from ext2 to reiserfs. Instead you have to make a new (empty) fs and copy the files out of the old one into the new one. So, rsync (or cp or tar etc) does not care what kind of filesystem(s) the source or destination files reside in, except for the fact that different fs's have different capabilities, and so it's impossible to replicate some metadata from one fs to another. For instance, if you try to rsync from an ext3 fs to a dos fat16 fs, fat16 has no such things as symlinks, device nodes, named pipes, filenames longer than 8.3, case sensitivity, ownerships, permissions, suid/guid/sticky bits, accurate timestamps, or any extended attributes or acls, files larger than 2G, etc... rsync normally reproduces all of that, but it can't if the one or the other filesystem simply doesn't have it. But for most files going between most linux/unix fs's, most of those features are supported by all of them and so mostly you can copy files between them without ever knowing the difference. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/13/2013 11:21 PM, Brian K. White wrote:
On 8/13/2013 8:21 PM, Doug wrote:
On 08/13/2013 06:39 PM, Brian K. White wrote:
On 8/13/2013 6:16 PM, Doug wrote:
On 08/13/2013 04:27 PM, Brian K. White wrote:
On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote: /snip/
explanation of filesystems and copying--well done!
You can proceed a few different ways.
The best way is probably create new empty filesystems manually on the new partitions, then use rsync to copy all your files over to them. The advantage here is that rsync is resumable (if you abort in the middle, it doesn't have to start over from the beginning), and it works for any kind of fs as long as you can mount that fs in linux.
Another way is dd the old fs to the new partition, then use whichever utilities are appropriate for the fs type to grow the fs to fill the new space. Not all fs's are growable but the common current linux ones are. At least ext3, ext4, reiser. They don't all use the same command, ie there isn't a growfs command. ext3/4 has resize2fs, reiser has resize_reiserfs, xfs probably has something, btrfs probably has something, etc. This all also assumes you aren't using lvm. This way might work if you had a non-linux fs from some other OS where you can't mount or resize the fs from linux, but you can dd any block of disk bytes, and then maybe the other OS can resize it's own fs itself later.
Generally, copying a fs to a larger partition or whole device (no partition table) does not affect the fs at all, it still works fine exactly as before. But it also does not use the extra space. You have to resize the fs to use the extra space. Not all fs types can be resized. Some can be resized but maybe there is no linux utility to do it, or not a safe one anyways. Some can only be grown and never shrunk, some can be grown or shrunk.
I was intending to format the partitions on the new drive with ext4 (for Linux) and NTFS (for Windows 8) so that the DDd files would arrive on formatted space, and the rest of the partition would be usable, being formatted and empty. I get the impression that I'm missing something here--please explain. Is there a difference between what you call a file system, and what I call a formatted partition? If so, what?
Thanx--doug
A filesystem is the formatting, but it need not be in a partition. It can be on a whole device (like a floppy, only you can do it to anything like a hard drive or a thumb drive or a ramdisk) or inside of a file.
dd does not copy files it copies raw data. That data may or may not come from a file or go into a file, the point is dd doesn't know or care what the data is. If you use dd to copy a filesystem, you are not "dding the files" you are dding one big solid hunk of raw meaningless data called the entire filesystem. dd does not know about all the individual files inside in the way that tar or cp or rsync or winzip does.
The filesystem is the "formatted partition" in one sense, in the sense that it is the formatting that usually occupies an entire partition. When you format a partition in windows, what is happening is windows creates an ntfs or fat32 filesystem
But a filesystem is also not a "formatted partition" in the sense that it is not the partition itself, just the data that was written to the partition. The partition is just an arbitrary block of disk space which is defined by the partition table. It's not really accurate to think of "formatting the partition" because for instance you can "format" just a part of a partition if you wanted to. You could write a filesystem that only uses 800 gigs of a 1tb partition. Is that partition then "formatted"?
Normally you would not do that but the distinction still matters because of your own current project.
You have an old drive that currently shows up as /dev/sda and a new larger drive that shows up as /dev/sdb.
The old drive has a partition /dev/sda1 which is 500 gigs, 100% filled with a 500 gig ext3 filesystem.
The new drive has no partitions and no filesystems. You create a partition table and make a 1.5tb partition on it. Now you have a /dev/sdb1 that is 1.5tb but it has no filesystem yet.
Instead of running "mkfs /dev/sdb1" to create one you use dd to copy the old one: dd if=/dev/sda1 of=/dev/sdb1
What happened was, the first 500G of /dev/sdb1 now has a carbon copy of /dev/sda1, followed by 1T of blank space. Not only is it blank, it's "invisible" to most utilities. If you mount the new copy:
mount /dev/sdb1 /mnt
Then look at /mnt, you will see that there is only 500G of space total in /mnt.
df -h /mnt
will show something like this: # df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/sdb1 512M 358M 154M 70% /mnt
That empty space is not merely unused like the 154M available above. It's not even available, because it lies outside the filesystem.
In the old old days, you couldn't resize filesystems, you could only make new ones and copy files from one to another. Today the popular filesystems can mostly be resized.
So now you can use resize2fs to resize /dev/sdb1 to fill up the new larger partition it is in. After that, the df command will show you that the Size and Avail are larger.
rsync would be a different story.
rsync DOES work on individual files. One reason to use rsync (or cp or tar or cpio or any of the backup programs) instead of dd, would be that if you copy the individual files instead of the whole flsystem, then the new filesystem can be a different type than the old one, as well as a different size. For instance, say the old filesystem is ext2. If you wanted the new fs to be ext3 or ext4 then you can upgrade an existing ext* to any higher version in-place, but that's a special case. In any other case, say you want the new filesystem to be reiserfs or xfs or btrfs or zfs, there is no way to convert one fs to another. So you couldn't copy the old fs with dd and then convert it from ext2 to reiserfs. Instead you have to make a new (empty) fs and copy the files out of the old one into the new one.
So, rsync (or cp or tar etc) does not care what kind of filesystem(s) the source or destination files reside in, except for the fact that different fs's have different capabilities, and so it's impossible to replicate some metadata from one fs to another. For instance, if you try to rsync from an ext3 fs to a dos fat16 fs, fat16 has no such things as symlinks, device nodes, named pipes, filenames longer than 8.3, case sensitivity, ownerships, permissions, suid/guid/sticky bits, accurate timestamps, or any extended attributes or acls, files larger than 2G, etc... rsync normally reproduces all of that, but it can't if the one or the other filesystem simply doesn't have it. But for most files going between most linux/unix fs's, most of those features are supported by all of them and so mostly you can copy files between them without ever knowing the difference.
I want to thank you very much for the clear description. I'm afraid I was pretty much in the dark about this whole situation, and now you have shed some light! --doug -- Blessed are the peacemakers..for they shall be shot at from both sides. --A.M.Greeley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Content-ID:
On 08/13/2013 11:21 PM, Brian K. White wrote:
...
I want to thank you very much for the clear description. I'm afraid I was pretty much in the dark about this whole situation, and now you have shed some light!
True - but, please, a request: could you next time erase most of the quoted material? Your post weighted 13 KB instead of the needed 5. We have that material in the previous post, no need to repeat. Why does it matter? Well, several reasons. Besides having to page down several times to get at the new text material, some people have limited internet connection. For instance, myself on this computer, I am limited to 500 MB/month (adding both up and down), so those emails add to the limit. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlILacoACgkQja8UbcUWM1yEEAEAilRq1whXVfsNaVbW4OsFm1Ie aEATIVg+DUAYpZq9n/wA/jGTOTW/q61YhGcgSsk9pZoW0vMzMuUYZ8XorvymAIAY =wlNa -----END PGP SIGNATURE-----
participants (10)
-
Andrey Borzenkov -
Brian K. White -
Carlos E. R. -
Carlos E. R. -
Dave Howorth -
Doug -
ellanios82 -
Greg Freemyer -
John Andersen -
Per Jessen