#qa | Logs for 2020-10-17
« return
[01:04:40] -!- halibut [halibut!~halibut@2001:468:d01:mr:tvu:rpjp:hkzp:mwzz] has joined #qa
[08:08:54] -!- aristarchus [aristarchus!~c2228478@194.34.ypr.wkh] has joined #qa
[09:26:10] <aristarchus> Cert expired. Yo.
[09:28:28] -!- aristarchus has quit []
[18:06:08] <halibut> Bytram: Don't restart your dd process, but if you end up running another process, using a block size larger than 16 tends to be more efficient (try 1M or something). Looks like you are currently limited by USB transfer speeds, so that is not an issue for your current dd, but might be worth keeping in mind if you use it again.
[22:39:07] -!- Bytram_dewey [Bytram_dewey!~a6b6f8cd@840-838-777-756.mobile.uscc.com] has joined #qa
[22:42:19] <Bytram_dewey> dd progress: 966 GB, 900 GiB copied, 32323 s, 29.9 MB/S
[22:54:06] <halibut> Bytram: Don't restart your dd process (you're so close!), but if you end up running another process, using a block size larger than 16 tends to be more efficient (try 1M or something). Looks like you are currently limited by USB transfer speeds, so that is not an issue for your current dd, but might be worth keeping in mind if you use it again.
[22:58:11] <Bytram_dewey> halibut: I am using: dd if=/dev/sda of=/dev/sdc status=progress bs=1G
[22:59:27] <Bytram_dewey> yes, I am aware it's USB-limited... I'm copying from (and to) SSDs. :/
[23:02:13] <halibut> The bs=16 means it reads and writes 16 bytes at a time, which involves way more system read/write calls than if you use a larger block size. Don't make it too large, though, because it does allocate that much memory (bs=4G will consume a 4G chunk of memory). I have not played with it much, but I have seen performance hits with small block sizes compared to a megabyte (or probably even 64K). Anyways, not
[23:02:19] <halibut> too important here since that's probably not your limiting factor.
[23:02:43] <halibut> Also, when you mount the copy on your other computer, you might try a read-only mount: mount -o ro /dev/sd<whatever> /mnt/<wherever>
[23:02:51] <halibut> Just to be extra safe.
[23:07:57] <Bytram_dewey> Oooooo! TYVM!!!!!!!!
[23:08:01] <Bytram_dewey> done!
[23:09:03] <Bytram_dewey> 1.0 TB, 932 GiB copied, 33474 s, 29.9 <B/s
[23:09:16] <halibut> Always a nice feeling when a >9-hour copy finishes.
[23:10:59] <Bytram_dewey> just calculated it: 9h17m 54s
[23:11:11] <halibut> Cheap way to figure out what device the external drive shows up as (other than guessing /dev/sdb) is to do ls /dev/sd* before and a few seconds after plugging the drive in.
[23:11:42] <Bytram_dewey> for future reference, is there an option to dd that says to "verify the copy as you go along"?
[23:12:14] <Bytram_dewey> nod nod; I've been going by: lsblk
[23:12:42] <halibut> Not to my knowledge. dd is a raw copy program. If you want to verify, you either do it a second time, use a diff, or write a simple script to read blocks back as it copies.
[23:13:21] <halibut> Another way is to check the system logs, which typically report when a USB drive is added and what block device they are set to. There are no shortage of ways, but simply looking for what appears is the easiest for me.
[23:13:31] <halibut> date -ud @33474
[23:13:34] <halibut> Thu Jan 1 09:17:54 AM UTC 1970
[23:13:39] <Bytram_dewey> I'd rather avoid doing another 9+hr task, if I can avoid it. :D
[23:13:53] <halibut> Yep.
[23:14:10] <Bytram_dewey> Neat!
[23:14:12] <halibut> (above) Cheap way to use the date program to convert 33474s to HH:MM:SS.
[23:14:16] <halibut> I see you figured that out.
[23:15:32] <Bytram_dewey> I'm familar with most of the options.. except the "@"
[23:15:58] <halibut> Drives typically have error correction built-in. I frequently check large copies, and the only time I have every seen a corruption issue was when I had some bad hardware (motherboard, CPU, memory, PSU, never figured out what, but it wasn't the drive).
[23:16:40] <halibut> date -d <date> reports the given date/time rather than the current date/time. @S gives the time as S seconds after the epoch.
[23:17:09] <halibut> (as opposed to HH:MM:SS, or some other format)
[23:19:30] <Bytram_dewey> nod nod; tx!
[23:20:39] <Bytram_dewey> back to the mount command.... -o ro does that mean: "option: read-only" ?
[23:22:37] <chromas> sì
[23:22:40] -!- halibut has quit [Remote host closed the connection]
[23:22:59] -!- halibut [halibut!~halibut@2001:468:d01:mr:tvu:rpjp:hkzp:mwzz] has joined #qa
[23:23:16] <halibut> Yes. -o ro means add the read-only option.
[23:25:52] <Bytram_dewey> Oh, to unmount the external SSD... /dev/sdc ... ??
[23:26:13] <Bytram_dewey> is is as simple as: umount /dev/sdc
[23:26:32] <Bytram_dewey> s/is/it/2
[23:27:09] <halibut> Should be. I typically give the mount point (directory) rather than the device, but I think both work.
[23:27:29] <halibut> If the command completes successfully and just running ``mount'' (no arguments) no longer lists it as mounted, that should be sufficient.
[23:27:30] <Bytram_dewey> has not yet been mounted.
[23:27:40] <Bytram_dewey> oh!
[23:27:49] <halibut> Oh, good. This is the drive you were copying? You should not be using dd on mounted disks.
[23:28:17] <halibut> Although, if you did mount it, the device is probably /dev/sdc1 or something (need the paritition number).
[23:29:54] <Bytram_dewey> no partition numbers on either in the dd command; I typed it here exactly as entered... BUT, I *did* have /dev/sda mounted... not accessing it any way (at least to my knowledge)
[23:30:33] <halibut> Probably OK. Your copy can get corrupted if anything alters the file system when trying to do a byte-for-byte copy like that.
[23:31:10] <Bytram_dewey> dd if=/dev/sda of=/dev/sdc status=progress bs=1GB
[23:32:16] <Bytram_dewey> nod nod... *way* back when I helped test IBM's VM operating system. VM/SP HPO3.4 and HPO4 (IIRC)
[23:32:50] <halibut> Oh -- I see I misread ``bs=1G'' before as ``bs=16''. Hence my comments. 1G is a little excessive, but should not hurt.
[23:33:15] <halibut> Before transferring the drive, see if you can mount the copy on your current machine.
[23:33:27] <halibut> mount -o ro /dev/sdc1 /mnt/<somewhere>
[23:33:30] <halibut> or something like that.
[23:34:15] <Bytram_dewey> written in BAL/370 try testing a 3rd level VM by single-stepping though the 1st level VM and mentally translating Table-Look Aside buffers. In hex.
[23:34:35] <Bytram_dewey> k, brb
[23:35:16] <halibut> Sounds ... excrutiating.
[23:36:26] <Bytram_dewey> yeah, there was some hex translation in the 2nd level VM, too.
[23:37:03] <Bytram_dewey> do I need to mkdir the desinati0on mount point, first? e.g.: sudo mkdir /mnt/foo
[23:37:19] <halibut> Yes (sudo only required if you are not in a root shell).
[23:37:35] <Bytram_dewey> ruhroh... hold on
[23:38:06] <halibut> I think I remember you were using ~/mnt/ instead of /mnt/. If this is a liveCD/liveUSB system, it should all be temporary anyways, so it does not matter too much.
[23:39:03] -!- Bytram_Huey [Bytram_Huey!~a6b6f8cd@840-838-777-756.mobile.uscc.com] has joined #qa
[23:39:19] <Bytram_Huey> Hi from over *here*!
[23:39:47] <Bytram_Huey> ubuntu@ubuntu:~$ sudo mkdir /mnt/foo ubuntu@ubuntu:~$ mount -o ro /dev/sdc /mnt/foo mount: only root can use "--options" option ubuntu@ubuntu:~$ sudo mount -o ro /dev/sdc /mnt/foo mount: /mnt/foo: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error. ubuntu@ubuntu:~$
[23:39:57] * halibut is seeing double ... Two Bytrams ...
[23:40:41] <halibut> You are trying to mount the entire drive, but the filesystem is likely on a partition. Try replacing /dev/sdc with /dev/sdc1 (also, make sure it is /dev/sdc and not some other last letter).
[23:40:58] <Bytram_dewey> think, left to right, Huey, Dewey, and Louis (however they are spelled!)
[23:41:39] <halibut> Louie, according to https://unix.stackexchange.com
[23:41:47] <Bytram_dewey> Louie? that looks better (not booted up atm, but that one is over --------> there)
[23:41:50] <halibut> https://en.wikipedia.org
[23:41:58] <Bytram_dewey> ktx
[23:42:40] <Bytram_dewey> Little did I suspect how much trouble I would have spelling those names when I came up with them!
[23:43:11] <Bytram_dewey> well, decided to use those names for those computers.
[23:43:37] <halibut> Shouldn't you then change your /nick to Donald?
[23:43:37] <Bytram_dewey> anyway... let me try to paste that stuff in again on separate lines...
[23:43:39] * halibut ducks
[23:43:48] <Bytram_dewey> PASTE_BEGIN
[23:44:10] <Bytram_Huey> ubuntu@ubuntu:~$ sudo mkdir /mnt/foo
[23:44:24] <Bytram_Huey> ubuntu@ubuntu:~$ mount -o ro /dev/sdc /mnt/foo
[23:44:39] <Bytram_Huey> mount: only root can use "--options" option
[23:44:52] <Bytram_Huey> ubuntu@ubuntu:~$ sudo mount -o ro /dev/sdc /mnt/foo
[23:45:03] <Bytram_Huey> mount: /mnt/foo: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error.
[23:45:05] <halibut> Try: ls -l /dev/sd*
[23:45:14] <Bytram_dewey> PASTE_END
[23:45:16] <halibut> I suspect you want /dev/sdc1 instead of /dev/sdc in the mount command.
[23:45:25] <Bytram_dewey> doh!
[23:45:53] <Bytram_Huey> ta dah!
[23:46:45] <Bytram_dewey> And... ls does give me a list of files and dirs there
[23:47:24] <Bytram_dewey> woo hoo!
[23:47:27] <halibut> Nice. Now it's just deciding what to copy?
[23:48:20] <halibut> I remember you mentioning IRC logs (and asking somebody to remind you), hexchat config, and ssh keys. I can probably only be of very minor help with the latter (but since ssh private keys are private, you should be careful about showing too much there).
[23:48:54] <halibut> As for GUI setup, I'm afraid I will be of no help at all, but it sounds like several others would be helpful there.
[23:49:23] <Bytram_Huey> ubuntu@ubuntu:~$ sudo umount /mnt/foo
[23:49:42] <Bytram_Huey> still shows /dev/sdc1 when I do lsblk
[23:50:06] <halibut> The device still exists, but should not be mounted. Run ``mount'' with no arguments to get a list of what is currently mounted.
[23:50:12] <halibut> mount | grep -F /dev/sdc
[23:50:17] <halibut> just to filter it a little.
[23:50:28] <Bytram_dewey> ahh, I got a couple screenfuls, before
[23:50:49] <halibut> Neither /dev/sdc nor /dev/sdc1 should be in the mount output.
[23:51:08] <Bytram_dewey> yep,
[23:51:13] <halibut> If you mount it, they should show up, and if you umount it, it should disappear. /dev/sdc1 should exist as long as the drive is connected.
[23:51:29] <Bytram_dewey> grep -F /dev/sd
[23:51:50] <Bytram_dewey> showd sda and sda1 but no other drives
[23:53:14] <halibut> /dev/sda is the drive you were copying, right? It is probably safe to unmount that, too, if you want to work with just your copy from now on.
[23:53:36] <Bytram_dewey> so, IIUC, I should be able to safely unplug /dev/sdc from the computer (that is the destination for the dd and is mounted in the USB enclusure)
[23:54:06] <Bytram_dewey> yes, /dev/sda was the source SSD
[23:54:19] <halibut> Yes. It is not mounted, so it should be safe to unplug. However, I would also run ``sudo sync'' first.
[23:54:32] <halibut> sync ensures that anything that is queued to be written to disks actually gets written.
[23:54:52] <Bytram_dewey> do you remember the fsck command?
[23:54:54] <halibut> It's a little paranoid, because I think unmounting also does that for the disk being unmounted, but it does not hurt.
[23:55:30] <Bytram_dewey> nod nod
[23:55:38] <halibut> Is this an NTFS drive? You might not have an NTFS file system checker, but if you want to try:
[23:55:42] <halibut> fsck -f /dev/sdc1
[23:56:01] <halibut> Maybe leave off the -f
[23:56:02] <Bytram_dewey> well, it's unmounted, now.
[23:56:14] <halibut> fsck should only be run on unmounted partitions.
[23:56:30] <Bytram_dewey> k
[23:56:32] <halibut> I think the -f is specific to certain filesystems
[23:58:43] <Bytram_Huey> Ubuntu@ubuntu:~$ fsck -f /dev/sdc1
[23:58:58] <Bytram_Huey> fsck from util-linux 2.31.1
[23:59:06] <Bytram_Huey> e2fsck 1.44.1 (24-Mar-2018)
[23:59:27] <Bytram_Huey> fsck.ext2: Permission denied while trying to open /dev/sdc1
[23:59:56] <halibut> e2fsck? Wasn't this a Windows system? It should not have ext2 as a filesystem.