[00:09] what does the raw data on the drive look like for the first 8 sectors? [00:13] i've just managed to obtain the program and convert it, it's appearing as "GPT protected" to my windows 10 PC [00:13] firing up a Linux machine now [00:16] perhaps MS have changed their methodology since this program was made [00:17] xubuntu claims the GPT tables are corrupted [00:18] look at the raw data, ignore the tools [00:19] yeah i'll revert it to stock first [00:22] hrmm not used to using dd in this context; is "sudo dd if=/dev/sdb of=file bs=1M count=1 ok to grab the first 1MB? :) seems not based on the data i saw [00:22] * daftykins puts another " up there [00:24] hrmm hexdump [00:24] daftykins: yes that works [00:25] then you can "hexdump -C file" [00:25] hehe, i guess 1MB is a lot... it's going for some time. [00:26] ah there we go, man page to the rescue [00:26] well, it should be 512 x 35 sectors to get primary GPT [00:27] so about 20KB is all that is needed [00:27] i can't work out what value or unit hexdump -n requires for 'length' [00:28] the manpage is rubbish [00:28] or i could just host the file XD [00:29] https://www.dropbox.com/s/k2omzaodp46q8ae/dd?dl=0 [00:29] that appears to have a download function [00:29] ah yeah i see some strings using "hexdump -C file -n 1024" [00:35] dropbox doesn't work for me, not even with allowing its Javascript [00:36] ok lemme throw it on a webserver [00:37] http://techblo.gg/stuff/dd_image [00:37] that should be good :> [00:39] oooo! 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99 cc |................| [00:40] those last 2 signature bytes are usually 55 AA so it looks like 99 CC is the 'locked' signature [00:40] I bet if you change those it'd be read by the tools [00:42] ooh :D what'd be the easiest way to action that change? [00:43] fdisk -l /dev/loop1 [00:43] GPT PMBR size mismatch (976773165 != 2047) will be corrected by w(rite). [00:43] Disk /dev/loop1: 1 MiB, 1048576 bytes, 2048 sectors [00:43] Units: sectors of 1 * 512 = 512 bytes [00:43] Sector size (logical/physical): 512 bytes / 512 bytes [00:43] I/O size (minimum/optimal): 512 bytes / 512 bytes [00:43] Disklabel type: dos [00:43] Disk identifier: 0x78563412 [00:43] Device Boot Start End Sectors Size Id Type [00:43] /dev/loop1p1 1 976773165 976773165 465.8G ee GPT [00:43] oops! pastebin silly :D [00:43] "hexedit" ... type-over with the correct values at offset 0x1FE, then Ctrl+X to save (answer Yes) [00:43] ooh ty [00:43] BUT... don't do it on the device itself!! [00:44] the EFI-SP starts where the primary GPT should start [00:44] ah just on the file, then dd to and fro? [00:44] No, don't alter the disk. There's something special in where it has put the GPT primary tables. [00:45] ah ok so i'll have to image the whole disk >8\/ [00:45] The primary GPT header should be in sector 1-34 [00:45] the secondary is at the very end of the device [00:47] annoyingly the Linux laptop i'm working from doesn't have enough storage to image up this 500GB disk in its' entirety [00:47] i could put it on a network drive though [00:48] What was the original problem? [00:48] i've got two SATA to USB 3.0 adapters for use with my xbox, today... neither one will show up to the xbox at all [00:49] plugging the drives into my desktop PC shows the drives are definitely there and talking, just seems like they've had a falling out with the xbox :D [00:49] i'm tempted to contact their support about it; but i don't imagine getting too far [00:49] all it is is a storage drive of installed games, so not the end of the world, just means a big re-download [00:51] correction. GPT primary header is at Sector 1. I was mis-reading [00:52] so, temporarily altering 0x1FE from 99 CC to 55 AA should be safe. [00:53] i'm a tad puzzled on the way to attack this then, do you think i should make a full image? [00:53] OK, going back a bit [00:54] USB3<>SATA adapters. Are you using those on the PC, too [00:54] yep [00:54] Can we rule them out as the problem? [00:54] i took a second drive and used one of the two to connect it to the xbox and it came up right away [00:54] it does sound like something specific to the XBox then [00:54] *nod* [00:55] just found their FAQ page on diagnosing storage and i've tried all their golden advice already [00:55] "turn the xbox off and on again" [00:55] "try another USB port" [00:55] :D [00:55] look at the 'new' drive it does see; does it's sector 0 have that same signature 99 CC [00:55] i'll go grab it and bring it up [00:55] maybe the fix is to put it back to 55 AA :) [00:55] no idea what would change that though! [00:56] unless that program i just used to change between 'xbox' and 'PC' mode killed it [00:56] maybe it does that to the drives deliberately in order to 'hide' the drives? [00:56] i think so yeah, stops folk copying the content so freely [00:57] it'd be a good step to stripping DRM and spreading games [00:57] heh !list [00:58] wileee, all torrents are here http://torrents.linuxmint.com/ [00:58] daftykins: Aha. The Primary GPT's CRC is incorrect [00:59] So yes, I think the tool has altered key bytes and not regenerated the CRC of the header [00:59] * OerHeks hides behind a glass bacardi-cola [00:59] I knew this was not exactly the stuff in whatever the list holds, the drm strip was the trigger [00:59] ? [00:59] did you install that budu script thingy ? [01:00] mint!? [01:00] * daftykins shakes a fist [01:00] TJ-: hmm, should i still do a dump of the other disk? maybe less than 1MB this time? [01:02] funny how linux has so many derivatives of something, everyone or some anyway want individuality I suppose [01:02] daftykins: offset 0x5C in the GPT header should have a 4-byte CRC32. In the image it's 0x0 [01:02] it kind of annoys me, if they could work together it'd be a de-duplication of effort and more work could be done on the fewer :) [01:02] daftykins: that's offset 0x25C in image file [01:03] I'd have thought they've jsut moved the CRC32 somewhere else, lets find it :D [01:03] * TJ- dons his Sherlock Holmes cape and picks up the magnifying glass [01:03] fair assessment is they are more a like than different across the board at least from a armchair view [01:04] daftykins: Grrr, I'm tired. the CRC32 is at 0x58 (0x258 in the image) and its there! My memory is failing me [01:06] TJ-: ooh this other one came up showing me the NTFS partition once i let it use the primary table [01:06] it said the backup was corrupt [01:06] (parted) [01:07] daftykins: That's interesting. maybe there is no backup on these drives. use dd to look at the last 34 sectors [01:07] i've no idea how to do that XD [01:09] daftykins: I noticed in the primary header, offset 0x28 (0x228) first usable LBA for partitions - is set to 2, when it ought to be 0x22 (34) [01:09] i've grabbed the first 1MB again on this second disk; http://techblo.gg/stuff/dd_image2 [01:10] daftykins: HAHA! that was it. I changed it to 0x22 at offset 0x228 and the tools recognise the GPT [01:11] :D [01:11] i've reconnected the original disk [01:11] I've had to use 'cgdisk' on the partial disk image because the other tools won't ignore there not being a complete disk [01:12] can i hexedit the 1MB image then write it back? [01:12] it'd be easier to just hexedit the disk device directly [01:12] hexedit /dev/sdX [01:12] true, just heeded your earlier warning :> nothing to lose here though [01:13] well, you have an image of that area of the disk so you could just put the original back with dd [01:13] ok i'm in the hexedit view [01:13] As long as you take an image of the original first, you're covered (as long as you don't make changes outside the range covered by the backup image). Right now you're working with just the 1st 2 sectors. [01:14] navigate to offset 0x228 [01:14] you should see 0x02 [01:14] change to 0x22 [01:14] also, make sure you changed the signature at 0x1FE to 55 AA [01:15] that's the protective MBR signature [01:16] ok first change done [01:16] at 0x228 [01:17] tip: "hexedit -s ..." will give you a sector-based display which is often easier to work with when working on disk images [01:18] so we have 99 at 0x1FE [01:18] ah yes that made it far easier to see XD [01:18] so change from 99 CC to 55 AA [01:19] alrighty, that's all finished [01:19] parted still claims both GPTs are corrupt [01:20] shall i take it to the xbox to test anyway? [01:22] forget parted, use cgdisk [01:22] when it opens, choose Verify and see the text it reports [01:23] It may be you've got to edit the Secondary GPT header too [01:23] CRC invalid for both [01:23] you've got the same header there that I have :s [01:23] perhaps i did something wrong? i only made two edits [01:24] hrmm the disk looks totally different now, standby [01:24] no, 0x228 definitely has "22" [01:25] https://iam.tj/projects/misc/cgdisk-sector1.jpg [01:25] and "FF" in 0x1FE and "AA" in 0x1FF [01:26] 55, not FF [01:26] 55 AA [01:27] oops yeah that was meant to be 55, not sure what my brain did. [01:27] the reason is they bit patterns help detect flipped bits: 01010101 10101010 [01:27] hmmm, I've not done anything else [01:27] perhaps i need to reconnect? cached reads maybe? [01:27] no [01:29] it looks like the disk is presenting 1024 byte sectors [01:29] i think both of these are advanced format [01:30] oh cgdisk's output differed btw [01:30] the reason for saying that is that the first actual partition-table entry starts in the first sector following the header, and the header sector must be all-zeros from its end (its 92 bytes long) to the end of the sector. In the image here its all zeros until 0x600 [01:32] http://paste.ubuntu.com/13222007/ [01:34] the primary table seems only to use 20 sectors, because 0x2800 looks to be partition/file-system/file data [01:35] I change 0x22 back to 0x02 and I see that too [01:36] weird that your edits did a different thing to mine [01:37] tha value is the starting usable sector (34 decimal, 0x22 ) so if the header is shorter maybe it should be a smaller number [01:38] so try making the original 0x02 0x16 instead of 0x22 [01:39] same output as the above pastebin, from cgdisk [01:40] it could also be affected by my loop device using 512 byte sectors, and your using advanced format that looks to be 1KB sectors, in which case the number would be decimal 10, 0x0A [01:40] however, that doesn't explain why I don't get the CRC32 error when using 0x22 and you do, since the CRC's are the same [01:41] what are the 4 bytes starting from 0x210 ? [01:41] should i change the 0x228 "16" to anything else yet? [01:41] I have 00000210 92 BC A5 63 [01:42] no, lets figure out if we have differences first. [01:42] yep that matches [01:42] right, that's the CRC32 of the header itself [01:42] there's another CRC32 at 0x58 (0x258) of the partitions themselves, and I think that is the one that might be hiting you [01:43] 36 78 8D B0 is there [01:43] I do a verify with cgdisk: [01:43] cgdisk /dev/loop1 [01:43] No problems found. 1981 free sectors (990.5 KiB) available in 1 [01:43] segments, the largest of which is 1981 (990.5 KiB) in size. [01:43] that's with 0x228 = 0x22 [01:44] 00000250 01 00 00 00 80 00 00 00 36 78 8D B0 [01:44] yep, same :S [01:45] very strange! I can understand you seeing a problem with the backup table [01:46] just check sgdisk reports the same as cgdisk (its the same back-end) [01:46] "sgdisk --verify /dev/sdX" [01:47] yep - with 16 in place at 0x228 still [01:49] put 0x22 there and try again [01:49] here's additional stuff I see: http://paste.ubuntu.com/13222375/ [01:49] no change, both still with a bad CRC [01:50] hmmm, makes no sense. Try doing the same changes and tests on (a copy of) that file you sent me. [01:50] it seems like when addressing the hardware something to do with translation is changing things [01:51] will i need to use loop mounting? [01:52] yes "losetup /dev/loop1 /path/to/file" [01:52] then "sgdisk --verify /dev/loop1" and "hexedit -s /dev/loop1" [01:54] identical result to yours after making the two edits :( [01:54] sgdisk reads it fine [01:54] so it's something to do with the advanced format disk [01:54] This is where GPT breaks, so its interesting [01:56] i wonder if the xbox has any preference between AF or non [01:56] you'd have thought not, because it's bound to encounter both these days [01:56] the header is supposed to be in LBA1 of the disk. So depending on the sector size of the disk that could be 512, 1024, or 4096 bytes into the disk. This image has it at 512 bytes, which suggests the original controller uses 512 byte logical sectors. If Linux is using a different logical sector size that might explain it [01:57] i'm used to seeing the physical and logical sector size in parted's output, but we're not going to see that without a readable GPT i guess [01:58] maybe i need to take this drive out of its' enclosure and put it directly into a Linux PC tomorrow - that might change something? [01:58] hmmm, not sure. What does this report? [01:58] sgdisk --print /dev/sda [01:58] Disk /dev/sda: 976773168 sectors, 465.8 GiB [01:58] Logical sector size: 512 bytes [01:58] well, change /dev/sda obviously, for the real sdX of the disk [01:58] see what the Logical sector size reports [01:59] 512 bytes [01:59] ok, not that either! [01:59] i'll need to pop it out to double check if it was an AF drive [02:00] yep definitely has the AF logo [02:02] what does "cat /sys/block//device/model" report? [02:02] FE2005 - that'll be the model of the inateck enclosure i bought that it's in right now [02:03] it uses a jmicron UASP capable USB 3.0 controller [02:05] OK, so maybe its the translation causing the issue [02:06] Despite the warning, I wonder if the disk will be 'seen' if you return it to the xbox [02:06] * daftykins pops it downstairs [02:08] it noticed it this time, but it offered to format it instead of just use it [02:08] so even it knows something is wrong [02:09] perhaps all this work has been invalidated by the Windows program i ran first :( [02:09] but i did tell it to switch it back, so any process should have been reversed [02:10] you put in a new disk earlier, and it formatted it? maybe we should look at the header that created? [02:11] sure [02:11] did you happen to see the second 1MB image i posted? http://techblo.gg/stuff/dd_image2 [02:11] that's the working one [02:11] i must have missed it, let me look [02:14] that one is also advanced format, *but* used the other bridge chip to access it [02:14] changing the MBR signature to 55 AA fixes that one, it just complains about missing baclkup GPT. [02:14] 0x226 = 0x04 [02:14] parted was able to see the NTFS partition on that one as-is [02:15] but tools wouldn't mount it, naturally [02:15] i guess the kernel reads the primary only [02:20] these are weird; Trust MS to be non-standard [02:20] :D [02:21] well i think they want to stop people readily reading and copying installed content [02:23] this is your 2nd, good, disk image: http://paste.ubuntu.com/13222960/ [02:25] hmm [02:25] hexedit shows that Parition GUID at 0x600 (it's byte-reversed as little-endian) [02:25] notce "First sector: 4" [02:25] mmhmm [02:25] so the GPT header is very minimal, not storing the usual 128 entries (34 sectors) [02:25] i could read the first disk again with the same bridge chip, see if it was a quirk? [02:26] so that explains something about the CRC32 / first LBA 0x02/0x22 changes. That makes me think that the 0x228 on the faulty disk should be 0x04 [02:28] valid backup! :D [02:28] did you fix it? [02:29] that's weird, cgdisk still errors to both tables [02:29] sgdisk started to regenerate the main header from the backup [02:29] maybe i should go try the xbox again [02:30] http://paste.ubuntu.com/13223057 [02:31] oh it doesn't spot the microsoft basic data part, so maybe it's not happy still [02:32] i just figured out using sgdisk here re-write the GPT header without warning when using --verify, so BE CAREFUL [02:33] should i run sgdisk on the disk with --verify? [02:34] your pastebin was very different, stating "First sector: 4 (at 2.0 KiB)" whilst mine "First usable sector is 2," [02:40] right, LBA '2' suggests the logical sector size is 1024 [02:40] I'm running 'sgdisk' always with --pretend (-P) so it only does changes in-memory [02:41] ah har [02:41] i gave it another check on the xbox, naturally it tried to offer to format it again [02:43] -!- daftykins changed the topic of #ubuntu-love to: What is love? Baby don't hurt me... don't hurt me... no [02:43] more. [02:43] curious channel :) [02:45] sounds more like #ubuntu-tweens [02:45] ;) [02:45] :D [02:46] where for where art though ubuntu mod [02:46] thou* [02:47] TJ-: crikey look at the time :S i think this one deserves a nights sleep [02:56] * daftykins wonders if TJ- has been dragged away by the hounds [02:56] yeah [02:56] I just tried testdisk; even it can't deal with the non-standard GPT header with only 1 partition entry it assumes 34 sectors [02:57] ouch! [02:57] well, i could just give up and wipe it i guess [02:57] this reminds me of all the things that made me walk away from Microsoft software [02:57] You could try using testdisk to scan the disk and suggest a partition table for use on Linux at least [02:58] the good news is the xbox gets a new OS on Thursday, so maybe it'll be all change :D [02:58] then you could backup files to another device, then let the xbox reformat it correctly, change those signature bytes so Linux can see it, and copy the files back [02:59] hmm that could work! [02:59] i think that'll have to be a task for tomorrow though [03:02] You don't need the partition table if you mount the filesystem directly using "losetup --offset [03:03] "losetup --offset 2048 /dev/loop5 /dev/sdX" then "blkid /dev/loop5" might reveal an NTFS file-system [03:03] * daftykins quickly boots back up [03:03] I don't have enough of the data here to test that correctly. testdisk cold also discover the NTFS file-system [03:04] This all assumes the file-system/header/metadata isn't somehow 'changed' like the GPT [03:04] i could try emailing the guy that wrote the program that was meant to unlock it [03:04] there's certainly an NTFS header starting at 2048 (0x800) [03:05] might be a good idea, and indicate it somehow broke it [03:06] ok i ran the losetup, weirdly parted does nothing with the device [03:07] no, it's a pure file-system now, no PT [03:07] do "blkid /dev/loop5" [03:07] oh wow that's got the correct name i gave it on the xbox :) [03:07] we're trying to side-step the PT and work on the file-system directly [03:08] yep ntfs spotted [03:08] right: "mkdir -p /mnt/xbox; mount /dev/loop5 /mnt/xbox" [03:08] yep content successfully visible! [03:08] :D [03:09] YAY! [03:09] so perhaps as you said, backup the disk... let the xbox convert it... then compare the headers at the start and end of the disk? [03:09] OK, so you can backup correctly now, and then let the Xbox re-format te device, bring it back to Linux, id where the file-system is again, losetup+mount that empty new FS and copy the files back [03:10] I think the trick now is to IGNORE the partition table and work on the file-system(s) directly [03:10] ah yes, that'd be a lot less work [03:10] no point fighting it when the PT is not needed to work with the files [03:10] this info is highly useful to point out to xbox owners how to access the data direct [03:11] I've been doing this stuff for so long I generally do avoid PTs, but for some reason with only having these disk images from the 1st 1MB I got fixated on trying to correct the PT [03:12] hehe :D perhaps i should've offered SSH access early on :> [03:12] I could write a simple C program for you that does that [03:12] would that only be for use on a Linux host? [03:13] It'd be source code, so potentially usable on any POSIX host. [03:13] it would't work on Windows; but I was on about being able to natively mount an XBox disk on Linux without having to fiddle with it [03:13] ah har, could be pretty handy - though i'm certainly not adverse to the losetup method [03:13] ouch 227GB i've got on there :D [03:14] the thing is, to do that, you've got to identify the correct offset, and that could change [03:14] mmm, i wonder if they'd be that clever [03:14] I mean due to advanced format disks vs 'traditional' - sector sizes make translation a requirement to get it correct for all drives [03:15] i think there'd definitely be many folks that would appreciate a tool like that :) [03:15] i think it's our bedtime for sure though :D [03:16] I also, thinking about it, think the MS programmers got their GPT implementation wrong! Those offsets at 0x28 and 0x48 should be Logical Block Address offsets, whatever the LBA sector size is, but I *think* the programmers have assumed an LBA is ALWAYS 512 bytes [03:16] That's explain why the numbers didn't match the geometry [03:16] oooh this is interesting, remember that 'nonic' string that showed up? there's a file on this FS called 'LastConsole' that contains a few characters then 'nonic' [03:16] hehehe, so could be some other values to try? [03:18] nonic is actually part of the DISK GUID in the GPT header [03:18] ooh [03:19] at offset 0x38 to 0x47 [03:19] hehe i've not got the space on this laptop to copy the content over either [03:19] Well, at least you have access to it. Worry about that tomorrow [03:19] (later today!) [03:19] indeed :D [03:20] big games these days, just one is 55GB [03:20] most of it being texture data [03:20] mmm [03:20] well thanks muchly for that sir, it is hugely appreciated :) [03:21] you're welcome [03:21] very interesting seeing MS' methods reverse engineered [03:22] ooh my SSD has enough space come to think of it ^_^ [03:23] can't you connect the other, GOOD, empty Xbox drive to the PC too, and copy from one to the other? [03:24] could do, i was using xubuntu on a USB 2.0 only drive - so i've just booted ubuntu from a flash drive on my sandybridge laptop which has a USB 3.0 port [03:24] this should be extremely zippy :) [03:25] right, as long as the NTFS doesn't do something special too. I'd recommend writing just a few test files to the empty drive then testing it on the Xbox before going ahead with a full clone [03:25] that of course assumes the Xbox lets you browse the file-system [03:25] hmm i unmounted the mountpoint prior to shutdown but didn't disconnect the loop device, just issued a shutdown [03:26] the NTFS partition has this time mounted read only [03:26] oh think i used the wrong disk, haha [03:26] Careful!! [03:27] I've got to go clear spiders from a CCTV camera; they're setting off the motion detector continuously! [03:27] erk! ok :) [03:30] now there's a nice USB 3.0 UASP capable enclosure; 98.4MB/sec copying to my laptop's SSD from the 500GB laptop 2.5" [04:14] yay all copied, why did i stay up for that o0 [04:17] :D [04:17] alrighty i could go make the xbox format this for use now, then copy it back on (same disk) [04:18] or i could just sleep since it's 4am >8\ [04:18] I forgot to refit the back-plate in the freezer earlier, because still testing the hot-wire, and just realised that stops the fan from being able to force the air up into the fridge! So, waiting up a bit longer to ensure the fridge cools :) [04:18] yeah, I'm thinking of staying up all day, get ultra-tired and have a decent early night [04:18] i only made it 'til 4am the last time XD [04:19] er 4pm [04:21] i generally find if I started flagging, go for a run and a shower after wakes me up [04:22] TJ-: what would be interesting to see now from the formatted drive? [04:22] another 1MB dd grab? [04:24] same 2048 offset works :) [04:25] ouch far slower write speed naturally [04:26] 2hrs :( [04:28] I suspect the header of the formatted drive will be the same as the 'spare' you used earlier. [04:29] lets give it a go! [04:29] could i just diff the two files? [04:29] I've been getting annoyed by deficiencies in the GPT tooling we have for some time; I think I'm going to write a tool that can deal with this kind of stuff [04:29] No, CRCs and drive GUID will be different [04:29] you have to compare field-to-field [04:30] yee-ouch! so no point me showing you this one? :) [04:30] being able to tell a GPT tool only-use primary/backup table; ignore CRC errors, etc, etc [04:31] Not really, no, I've got the idea of what is going on there. [04:31] ouch it's gone down to 23MB/sec write :( [04:31] 3hrs it wants now to write that 243GB! [04:31] I've not had many drives with GPT have serious errors so far, so not had to hack too much. [04:32] you're feeling sleepy [04:32] how did you know :o [04:32] ;) [04:32] that's still a good transfer rate [04:32] you're just too spoilt! [04:32] hehehe [04:32] serves you right for buying such large games :D [04:32] yeah i love my SSDs, gigabit LAN and so forth [04:33] I wish there was a lappy that has a fibre port not copper [04:33] they're quite annoying with the "Xbox One"; it has an internal mechanical 500GB which they don't let you upgrade =| [04:33] these USB 3.0 enclosures are the only way to add storage [04:34] i hope there's nothing unique in these files... [04:49] i think nautilus really sucks for file copy because it's filled the RAM, i see 20% CPU usage on a dual core 2nd gen i5 from mount.ntfs and 14% CPU from usb-storage [05:03] it uses as much free space as possible to cache [05:03] same as us manually using 'dd bs=1G ...' [05:19] I've just tried booting this embedded system with plopkexec from a USB FDD. syslinux boots, plop starts then crashes/hangs the PC with the keyboard lights flashing! [06:06] good morning to all [06:06] again [06:13] http://news.softpedia.com/news/steam-machine-lunch-sale-brings-huge-discounts-for-45-steamos-and-linux-games-496007.shtml [09:50] Good morning. [10:28] good morning guys [10:43] morning lotus|xenial [10:43] hey EriC^^ [10:43] EriC^^: hows the movienight been :p [10:43] good good [10:44] :p [11:39] Puppet apply --noop is quite nice :D [12:16] afternoon cfhowlett and Ben64 [12:16] hello [12:16] lotus|xenial, greetings [12:24] once upon a time there was a penguin... [12:24] keep it clean! [12:25] haha [12:38] his name was tux and loved downhill snowraces... [12:39] ... his best friend was gnu [12:39] hahaha [12:40] cfhowlett: i think we ivented a new type of bedtime storybooks here we can earn big $$$ [13:07] !find nvidia-cuda [13:07] Found: boinc-nvidia-cuda, nvidia-cuda-dev, nvidia-cuda-doc, nvidia-cuda-gdb, nvidia-cuda-toolkit [13:10] Hi everyone [13:13] hi pauljw :p [13:29]