/tmp/2015-11-01-#ubuntu.txt:[22:57] <weva> hello everyone, I created and mounted some disk images on my home folder. and I moved them elsewhere because my drive warned that there was no more free space. but after moving them, it still shows zero free space
/tmp/2015-11-01-#ubuntu.txt:[22:57] <weva> in disk utility I still see the .img and .dd files mounted. could it be the reason?
/tmp/2015-11-01-#ubuntu.txt:[22:57] <bekks> weva: Yes.
/tmp/2015-11-01-#ubuntu.txt:[22:58] <weva> bekks, I tried for ex. "umount image.dd" and it says "umount: image.dd is not mounted (according to mtab)"
/tmp/2015-11-01-#ubuntu.txt:[22:59] <bekks> weva: so look at "mount" and umount whatever you want ;)
/tmp/2015-11-01-#ubuntu.txt:[22:59] <ActionParsnip> weva: use the mount point as the thing to unount
/tmp/2015-11-01-#ubuntu.txt:[23:01] <weva> ActionParsnip, I'd mounted it at mnt/loop0, mntloop1, mnt/loop2..I dont know how to use them to unmount. I was given the mount commands
/tmp/2015-11-01-#ubuntu.txt:[23:02] <ActionParsnip> weva: sudo umount /mnt/loop0       for example
/tmp/2015-11-01-#ubuntu.txt:[23:05] <weva> ActionParsnip, it says "not found" for all mount points
/tmp/2015-11-01-#ubuntu.txt:[23:06] <ActionParsnip> weva: use the mount command and you can see the mounted things.
/tmp/2015-11-01-#ubuntu.txt:[23:09] <weva> ActionParsnip, i dont see anything like the image files that are shown mounted in disk utility
/tmp/2015-11-01-#ubuntu.txt:[23:10] <bekks> weva: "mount" - take a look at the output.
/tmp/2015-11-01-#ubuntu.txt:[23:10] <weva> bekks, you'd like to see the output?
/tmp/2015-11-01-#ubuntu.txt:[23:11] <bekks> weva: Yes, pastebin it please and give us the URL to your paste.
/tmp/2015-11-01-#ubuntu.txt:[23:12] <weva> bekks, it is so crazy here that even firefox doesnt work properly. I create the paste, and its link is shown as paste.ubuntu.com, without any number following it
/tmp/2015-11-01-#ubuntu.txt:[23:12] <weva> and also firefox with no history and bookmarks
/tmp/2015-11-01-#ubuntu.txt:[23:13] <weva> the total of files are shown as 750mb, but I have 0 free space
/tmp/2015-11-01-#ubuntu.txt:[23:13] <bekks> weva: due to no space, nothing can be safed.
/tmp/2015-11-01-#ubuntu.txt:[23:14] <weva> bekks, but in the output there is nothing resembling these files
/tmp/2015-11-01-#ubuntu.txt:[23:14] <bekks> weva: try: sudo mount | nc termbin.com 9999
/tmp/2015-11-01-#ubuntu.txt:[23:16] <weva> suddenly free space became 12mb and when I restarted firefox it was normal again.
/tmp/2015-11-01-#ubuntu.txt:[23:17] <weva> bekks, but it'd also worked with terminbin: http://termbin.com/efgv
/tmp/2015-11-01-#ubuntu.txt:[23:18] <bekks> weva: And whats the output of "df -h"?
/tmp/2015-11-01-#ubuntu.txt:[23:19] <weva> bekks, it is this: http://paste.ubuntu.com/13077200/
/tmp/2015-11-01-#ubuntu.txt:[23:20] <bekks> weva: try running sudo apt-get autoremove
/tmp/2015-11-01-#ubuntu.txt:[23:24] <weva> bekks, didnt help
/tmp/2015-11-01-#ubuntu.txt:[23:26] <weva> bekks, these are the images shown in devices in disk utility: http://is.gd/fSnFRD
/tmp/2015-11-01-#ubuntu.txt:[23:27] <bekks> weva: PAstebin "df -h" again.
/tmp/2015-11-01-#ubuntu.txt:[23:31] <weva> bekks, http://paste.ubuntu.com/13077351/
/tmp/2015-11-01-#ubuntu.txt:[23:32] <frostschutz> weva, if 'sudo losetup' shows those, try 'sudo losetup /dev/loopX' for the loop device X you no longer need (or losetup -D for all)
/tmp/2015-11-01-#ubuntu.txt:[23:32] <frostschutz> weva, *sudo losetup -d /dev/loopX
/tmp/2015-11-01-#ubuntu.txt:[23:34] <weva> frostschutz, they're gone, free space went up to normal. thank you very much!
/tmp/2015-11-01-#ubuntu.txt:[23:36] <weva> bekks, ActionParsnip, thank you!
/tmp/2015-11-01-#ubuntu.txt:=== waly is now known as weva
/tmp/2015-11-01-#ubuntu.txt:[23:49] <weva> hello again, how can i restore an external drive partition from its dd image file
/tmp/2015-11-01-#ubuntu.txt:[23:49] <weva> ?
/tmp/2015-11-01-#ubuntu.txt:[23:53] <weva> daftykins, it is a file in "image.dd" format, would BS be a specific number, i.e. 4096?
/tmp/2015-11-01-#ubuntu.txt:[23:53] <frostschutz> weva, bs=1M is fine, unless you have a good reason to use something else
/tmp/2015-11-01-#ubuntu.txt:[23:54] <daftykins> weva: but an image of what
/tmp/2015-11-01-#ubuntu.txt:[23:54] <frostschutz> weva, cp works fine too, cp /path/to/image /dev/partition
/tmp/2015-11-01-#ubuntu.txt:[23:57] <weva> daftykins, it is an image of a partition, the file type of which I assigned as "linux luks" via testdisk
/tmp/2015-11-01-#ubuntu.txt:[23:58] <weva> now I'd like to create a partition again, to see if I get a proper luks one
/tmp/2015-11-01-#ubuntu.txt:[23:58] <weva> because it was a properly created partition, but it turned into "unknown" when plugged in at the next session
/tmp/2015-11-01-#ubuntu.txt:[23:59] <weva> so I created an image of this problem partition. but i dont remember if it was the image or the real partition that I assigned the file type. maybe it doesn't matter?
/tmp/2015-11-02-#ubuntu.txt:[00:00] <frostschutz> weva, cryptsetup works with image files too, so you can cryptsetup luksDump some.image to see if it's LUKS or not
/tmp/2015-11-02-#ubuntu.txt:[00:00] <frostschutz> weva, or did you mean you are migrating an unencrypted one to luks?
/tmp/2015-11-02-#ubuntu.txt:[00:05] <weva> frostschutz, I tried it not with luksdump, but with luksopen, and the results were the same for different disk images I have: http://paste.ubuntu.com/13075829/
/tmp/2015-11-02-#ubuntu.txt:[00:05] <weva> I tried it with the mounted images that I had difficulty unmounting in the recent session
/tmp/2015-11-02-#ubuntu.txt:[00:06] <frostschutz> weva, cryptsetup would create (and remove) the necessary loop devices for you
/tmp/2015-11-02-#ubuntu.txt:[00:06] <frostschutz> weva, what does 'file the.image' say?
/tmp/2015-11-02-#ubuntu.txt:[00:08] <weva> frostschutz, it says "image.dd: data"
/tmp/2015-11-02-#ubuntu.txt:[00:10] <frostschutz> weva, so it's not a known type, filesystem, luks, or raid image... were you expecting it to be?
/tmp/2015-11-02-#ubuntu.txt:[00:11] <weva> frostschutz, this was a partition that I properly created as encrypted, and then transferred 2,5 gb of files into, and locked before powering off the drive. in the next session, the partition was shown as "unknown"
/tmp/2015-11-02-#ubuntu.txt:[00:12] <weva> I dont know what happened, but 2,5gb of data must be somewhere inside, as I haven't deleted any file, folder or partition
/tmp/2015-11-02-#ubuntu.txt:[00:15] <frostschutz> weva, encrypted as in LUKS? you need to find the LUKS header then
/tmp/2015-11-02-#ubuntu.txt:[00:18] <weva> frostschutz, yes, it is luks encrypted. but, aside from the question how i can find the header, does it help when the file is not shown as an encrypted ext4 filesystem?
/tmp/2015-11-02-#ubuntu.txt:[00:18] <quantic> weva: because until its decrypted, how would the system know it's a filesystem at all?
/tmp/2015-11-02-#ubuntu.txt:[00:18] <weva> quantic, so it's shown as unknown because it's encrypted?
/tmp/2015-11-02-#ubuntu.txt:[00:18] <quantic> weva: Being able to determine what type of filesystem exists inside an encrypted container would be an information leak.
/tmp/2015-11-02-#ubuntu.txt:[00:18] <frostschutz> weva, normally, testdisk should find LUKS headers... if you're looking for alternatives, 'sudo strings -t d /where/to/look | grep LUKS' (but it will give you false matches as well)
/tmp/2015-11-02-#ubuntu.txt:[00:21] <weva> quantic, I understand. the root cause seems to be something gone wrong in the filesystem, because not all the partitions have become "unknown", there are intact luks partitions.
/tmp/2015-11-02-#ubuntu.txt:[00:23] <weva> frostschutz, I also read about testdisk or gparted could restore filesystems. that was why I thought about changing file type via testdisk and creating the image of the new file to restore a partition from it
/tmp/2015-11-02-#ubuntu.txt:[00:23] <weva> do you think it might help?
/tmp/2015-11-02-#ubuntu.txt:[00:25] <frostschutz> weva, not sure what you mean by change file type via testdisk... testdisk is supposed to find things, not change things
/tmp/2015-11-02-#ubuntu.txt:[00:29] <weva> frostschutz, that's also what I should think. but I found an online post about it, and saw in testdisk the "T" option, which changes the file type, and I set it as "linux LUKS"..then I copied the new file to a drive, the dd file that I referred to.
/tmp/2015-11-02-#ubuntu.txt:[00:33] <frostschutz> weva, do you actually have to recover this data or can you just ... copy it again from wherever you copied the first time?
/tmp/2015-11-02-#ubuntu.txt:[00:35] <weva> frostschutz, the two places on two different drives, where I copied the data, have both become "unknown" at the same time. so I can get image of two partitions as many times as I can, but cannot access the data which I suppose is still in there, as I saw them there before all this happened
/tmp/2015-11-02-#ubuntu.txt:[00:36] <weva> since they are LUKS partitions, I might not have success with testdisk anyway, if I'm not mistaken?
/tmp/2015-11-02-#ubuntu.txt:[00:36] <weva> I mean in trying to recover data right now
/tmp/2015-11-02-#ubuntu.txt:[00:37] <weva> frostschutz, sorry for the long answer, the answer to your question is that the data is only in these two borked partitions now
/tmp/2015-11-02-#ubuntu.txt:[00:38] <frostschutz> weva, if it was luks encrypted you need the luks header. if testdisk does not find it, try strings. otherwise, end of the line
/tmp/2015-11-02-#ubuntu.txt:[00:38] <weva> except that I could probably use testdisk on my hard drive from where I cut-pasted them to the external drive
/tmp/2015-11-02-#ubuntu.txt:[00:39] <weva> but I think strings would be much easier than digging into hundreds of GB to find 2,5gb of data
/tmp/2015-11-02-#ubuntu.txt:[00:40] <weva> frostschutz, I see. so no use in creating a partition from the dd image?
/tmp/2015-11-02-#ubuntu.txt:[00:41] <weva> or no possibility of file system restore via gparted or, theoretically, via fsck?
/tmp/2015-11-02-#ubuntu.txt:[00:41] <weva> just asking, as I am wary of fsck, being unfamiliar with it
/tmp/2015-11-02-#ubuntu.txt:[00:45] <weva> frostschutz, so in the command 'sudo strings -t d /where/to/look | grep LUKS'  "where to look" would be the "unknown" luks partition on the drive?
/tmp/2015-11-02-#ubuntu.txt:[00:52] <weva> meanwhile, I'd like to see what happens with the image file.  in this command "dd if=image.dd of=/dev/sdX bs=1M" will /dev/sdX be the destination drive where the partition created by the image will be saved?
/tmp/2015-11-02-#ubuntu.txt:[00:53] <frostschutz> weva, it would be the drive or image file where you believe the luks header to be. and don't dd the image back to the disk, that's unnecessary...
/tmp/2015-11-02-#ubuntu.txt:[00:54] <frostschutz> weva, i.e. if you don't know where it is, search the whole drive, with testdisk too if you used testdisk on a partition instead of whole disk before
/tmp/2015-11-02-#ubuntu.txt:[00:55] <weva> frostschutz, I presume the luks header would be on the external drive where I created the partition, am I correct?
/tmp/2015-11-02-#ubuntu.txt:[00:57] <weva> could it be anywhere on the whole drive, or is it likely that it is found within the partition's own area(as it is still clearly seen as /dev/sdbX)
/tmp/2015-11-02-#ubuntu.txt:[00:57] <weva> ?
/tmp/2015-11-02-#ubuntu.txt:[00:58] <frostschutz> weva, it would be at the very beginning of the partition in question normally, (and file -s -L /dev/device would say it's LUKS as would luksDump)
/tmp/2015-11-02-#ubuntu.txt:[00:58] <weva> so if the partition in question is /dev/sdb9, would it be correct to type sudo strings -t d /dev/sdb9 | grep LUKS ?
/tmp/2015-11-02-#ubuntu.txt:[00:58] <weva> frostschutz, so if the partition in question is /dev/sdb9, would it be correct to type sudo strings -t d /dev/sdb9 | grep LUKS ?
/tmp/2015-11-02-#ubuntu.txt:[01:01] <weva> frostschutz, file -s -L /dev/sdc9 says '/dev/sdc9: data', like earlier
/tmp/2015-11-02-#ubuntu.txt:[01:05] <weva> frostschutz, in that case, would it still be correct to use " sudo strings -t d /dev/sdc9 | grep LUKS" ?
/tmp/2015-11-02-#ubuntu.txt:[01:11] <weva> frostschutz, ok, I am applying the command as I pasted above, but how will know if an output is a luks header? does it have a particular extension, expression..?
/tmp/2015-11-02-#ubuntu.txt:[01:13] <weva> frostschutz, i found one
/tmp/2015-11-02-#ubuntu.txt:[01:13] <weva> how will I proceed?
/tmp/2015-11-02-#ubuntu.txt:[01:14] <weva> it is a ten-digit number with LUKS next to it
/tmp/2015-11-02-#ubuntu.txt:[01:19] <frostschutz> weva, create a loop device, using losetup --read-only --offset=thenumber, then cryptsetup luksDump the loop device
/tmp/2015-11-02-#ubuntu.txt:[01:22] <weva> frostschutz, the offset would be the start point of the first partition on the drive, that is, /dev/sdc1 ?
/tmp/2015-11-02-#ubuntu.txt:[01:35] <weva> hello, frostschutz seems to have gone. can someone here help me further maybe?
/tmp/2015-11-02-#ubuntu.txt:[02:21] <weva> hello, sorry I was about to apply a solution to recover luks headers of my partition, but frostschutz has left, can you help me further maybe?
/tmp/2015-11-02-#ubuntu.txt:[02:22] <weva> I'd last applied strings and a number was detected
/tmp/2015-11-02-#ubuntu.txt:[02:24] <TJ-> weva: recover headers? does that imply you had back-ups?
/tmp/2015-11-02-#ubuntu.txt:[02:39] <weva> TJ- I have backups that are shown as "unknown" partitions..I think we were talking about it yesterday
/tmp/2015-11-02-#ubuntu.txt:[02:41] <weva> the problem was that I created these partitions as backups before reinstalling system. I saw the data was transferred in them. but now they are there as "unknown" partitions
/tmp/2015-11-02-#ubuntu.txt:[02:43] <TJ-> weva: does "sudo blkid /dev/sdXY" fail to identify any meta-data in them?
/tmp/2015-11-02-#ubuntu.txt:[02:46] <weva> TJ- the command gives no output. it just jumps to command prompt
/tmp/2015-11-02-#ubuntu.txt:[02:47] <TJ-> weva: which suggests there's no intelligible metadata there
/tmp/2015-11-02-#ubuntu.txt:[02:47] <weva> TJ- but strings returned a ten-digit number with LUKS written in red next to it
/tmp/2015-11-02-#ubuntu.txt:[03:04] <TJ-> weva: what does "sudo cryptsetup isluks /dev/sdXY" report for the backups?
/tmp/2015-11-02-#ubuntu.txt:[03:06] <weva> TJ- it reports these: http://paste.ubuntu.com/13079630/
/tmp/2015-11-02-#ubuntu.txt:[03:09] <weva> TJ- but the partition is shown with a star here : http://is.gd/htJ1hK does this not mean that it is mounted?
/tmp/2015-11-02-#ubuntu.txt:[03:10] <weva> also gparted shows it is mounted at /home
/tmp/2015-11-02-#ubuntu.txt:[03:10] <TJ-> weva: which ubuntu release is that on?
/tmp/2015-11-02-#ubuntu.txt:[03:11] <weva> TJ- it is on my external drive, my system is 14.04.3
/tmp/2015-11-02-#ubuntu.txt:[03:11] <TJ-> weva: Oh! my typo! "sudo cryptsetup isLuks /dev/sdc9" (not the UPPER-CASe L) !
/tmp/2015-11-02-#ubuntu.txt:[03:12] <weva> TJ- so it has to be upper case?
/tmp/2015-11-02-#ubuntu.txt:[03:12] <TJ-> weva: The 'L' of Luks does, yes
/tmp/2015-11-02-#ubuntu.txt:[03:13] <TJ-> weva: oH!! Add the option '-v' in there too, as in "sudo cryptsetup -v isLuks /dev/sdc9" so it tells you the status
/tmp/2015-11-02-#ubuntu.txt:[03:14] <weva> TJ- well.. http://paste.ubuntu.com/13079668/
/tmp/2015-11-02-#ubuntu.txt:[03:15] <weva> I find a luks string in /dev/sdc9, but it turns out not to be a valid luks device..the question remains; what am I to do, where is my data that i saw there with my own eyes..:)
/tmp/2015-11-02-#ubuntu.txt:[03:16] <TJ-> weva: was /dev/sdc9 always an encrypted block device using LUKS, or was its data copied from an original LUKS device elsewhere?
/tmp/2015-11-02-#ubuntu.txt:[03:17] <weva> TJ- it was created just before the data transfer to it. its data was copied from my hard drive, which was at least not home-folder encrypted.
/tmp/2015-11-02-#ubuntu.txt:[03:18] <weva> sorry, not copied, but cut-pasted
/tmp/2015-11-02-#ubuntu.txt:[03:19] <TJ-> weva: so the process was effectively "cryptsetup luksFormat ... /dev/sdc9; cryptsetup luksOpen /dev/sdc9 crypt_sdc9; mount /dev/mapper/crypt_sdc9 /mnt/tmp; ... cp -a /home/$USER/ /mnt/tmp; ... umount /mnt/tmp; cryptsetup luksClose crypt_sdc9" ?
/tmp/2015-11-02-#ubuntu.txt:[03:20] <weva> TJ- if you're asking me how I created the partition and transferred the files, I used all GUIs for them
/tmp/2015-11-02-#ubuntu.txt:[03:20] <weva> nautilus and gnome disk utility
/tmp/2015-11-02-#ubuntu.txt:[03:21] <TJ-> weva: Hmmm; wasn't aware they had LUKS format capabilities
/tmp/2015-11-02-#ubuntu.txt:[03:21] <weva> I might have used gparted to do initial formats of drives..which made me think when I heard of mbr-gpt mismatch as a possible cause of this filesystem problem..
/tmp/2015-11-02-#ubuntu.txt:[03:22] <weva> TJ- yes, gnome disk utility can do ext4 luks encryption
/tmp/2015-11-02-#ubuntu.txt:[03:22] <TJ-> weva: can you show me "pastebinit <( sudo dd if=/dev/sdc9 bs=16384 count=1 | hexdump -C )"
/tmp/2015-11-02-#ubuntu.txt:[03:23] <TJ-> weva: obviously it doesn't do it correctly!
/tmp/2015-11-02-#ubuntu.txt:[03:23] <weva> TJ- with the final ")" included?
/tmp/2015-11-02-#ubuntu.txt:[03:24] <TJ-> weva: that <( ... ) is process I/O redirection, collects the output, gives it to pastebinit
/tmp/2015-11-02-#ubuntu.txt:[03:25] <weva> TJ- here it is: http://paste.ubuntu.com/13079728/
/tmp/2015-11-02-#ubuntu.txt:[03:26] <TJ-> weva: don't know what the tools did, but the LUKS metadata header should be at offset 0 through to 00000250 ... there's none there
/tmp/2015-11-02-#ubuntu.txt:[03:27] <TJ-> weva: so you need to figure out if the tools create detached LUKs headers and if so where they put them!
/tmp/2015-11-02-#ubuntu.txt:[03:28] <TJ-> weva: this is the kind of thing you'd expect to see: http://paste.ubuntu.com/13079742/
/tmp/2015-11-02-#ubuntu.txt:[03:29] <weva> TJ- I see..where else could they be places?
/tmp/2015-11-02-#ubuntu.txt:[03:29] <weva> placed*
/tmp/2015-11-02-#ubuntu.txt:[03:31] <TJ-> weva: I have no idea; any tool that does detached LUKS headers and doesn't inform you is bad. I wonder if that is even a LUKS device at all; it could be a 'plain' dm_crypt device with no LUKS header at all, in which case you'd need to know the key to unlock it
/tmp/2015-11-02-#ubuntu.txt:[03:31] <weva> TJ- I sure still have my password
/tmp/2015-11-02-#ubuntu.txt:[03:32] <TJ-> weva: try "sudo cryptsetup open --type plain /dev/sdc9 crypt_sdc9"
/tmp/2015-11-02-#ubuntu.txt:[03:34] <weva> TJ- gosh, it asks me "enter passphrase"..should I enter the partition's encryption password?
/tmp/2015-11-02-#ubuntu.txt:[03:36] <TJ-> weva: Yes, and then you'll need to test the resulting device mapper node to see if the data in it makes sense, with "sudo blkid /dev/mapper/crpyt_sdc9"
/tmp/2015-11-02-#ubuntu.txt:[03:37] <TJ-> weva: I rather think it'll be garbage though
/tmp/2015-11-02-#ubuntu.txt:[03:37] <weva> TJ- I entered my password and it said "Device crypt_sdc9 already exists"...by the way, I think itwasnt there before, but now I see in device list /dev/sdc9 mounted at /dev/mapper
/tmp/2015-11-02-#ubuntu.txt:[03:38] <weva> TJ- crpyt_sdc9 or crypt_sdc9 ?
/tmp/2015-11-02-#ubuntu.txt:[03:44] <TJ-> weva: "Device crypt_sdc9 already exists" suggests some other tool already tried/did unlock the block device
/tmp/2015-11-02-#ubuntu.txt:[03:45] <weva> TJ- I don't know about it..I entered my password for the first time since the partition has this state
/tmp/2015-11-02-#ubuntu.txt:[03:47] <weva> TJ- this is how it currently looks: http://is.gd/nMkiti
/tmp/2015-11-02-#ubuntu.txt:[03:48] <TJ-> weva: something created /dev/mapper/crypt_sdc9, if it was there before you tried my 'cryptsetup open ...' suggestion
/tmp/2015-11-02-#ubuntu.txt:[03:49] <weva> TJ- I, too, first noticed it after I entered my passphrase
/tmp/2015-11-02-#ubuntu.txt:[03:52] <TJ-> weva: You'll have to research what the tools you used to encrypt the partition actually did/do, since it obviously is NOT LUKS - unless the tools used detached headers, but that makes no sense, since the first 4KB was left blank, which is where the header should be. It looks to me as if something wiped the original header out
/tmp/2015-11-02-#ubuntu.txt:[03:54] <weva> TJ-, that is probably the whole story behind the switching of the partition from encrypted LUKS label to "unknown"...if I could only know what happened. the same kind of damage on three different drives.
/tmp/2015-11-02-#ubuntu.txt:[03:55] <weva> and at the same time interval
/tmp/2015-11-02-#ubuntu.txt:[03:55] <weva> speaking of two of them, also at the same time
/tmp/2015-11-02-#ubuntu.txt:[03:57] <weva> TJ- frostschutz had last written that I should do " losetup --read-only --offset=thenumber, then cryptsetup luksDump the loop device"
/tmp/2015-11-02-#ubuntu.txt:[03:57] <weva> TJ- does it point to another approach?
/tmp/2015-11-02-#ubuntu.txt:[03:58] <weva> TJ- where might I need to look in? under /dev/mapper there is a file named crypt_sdc
/tmp/2015-11-02-#ubuntu.txt:[03:58] <TJ-> weva: in other words, is there a LUKS header in that device?
/tmp/2015-11-02-#ubuntu.txt:[03:58] <weva> sorry crypt_sdc9
/tmp/2015-11-02-#ubuntu.txt:[03:59] <TJ-> weva: "sudo cryptsetup -v isLuks /dev/mapper/crypt_sdc9" for example?
/tmp/2015-11-02-#ubuntu.txt:[04:01] <weva> TJ- no different http://paste.ubuntu.com/13079907/
/tmp/2015-11-02-#ubuntu.txt:[04:03] <TJ-> weva: whatever those GUI tools were doing, I'd take it up with their developers!
/tmp/2015-11-02-#ubuntu.txt:[04:06] <weva> TJ- do you think they could explain what might have borked the partitionsß
/tmp/2015-11-02-#ubuntu.txt:[04:06] <weva> ?
/tmp/2015-11-02-#ubuntu.txt:[04:16] <weva> TJ- I will reboot shortly, and be back
/tmp/2015-11-02-#ubuntu.txt:[04:35] <weva> oh, TJ- seems to have left..