| === gerald is now known as Guest63462 | ||
| === mwhudson is now known as zz_mwhudson | ||
| === gerald is now known as Guest23089 | ||
| === zz_mwhudson is now known as mwhudson | ||
| === mwhudson is now known as zz_mwhudson | ||
| smb | apw, yes | 07:58 |
|---|---|---|
| ppisati | something sweet for your breakfast: http://cryptome.org/2014/02/nic-ssh-rootkit.htm | 08:01 |
| ppisati | bottom line: fake nic firmware used to dump content of main memory | 08:02 |
| ppisati | but he didn't stop there, and and developed a fully working sshd running on the nic's cpu | 08:03 |
| ppisati | quite amazing if you ask me | 08:03 |
| === lag` is now known as lag | ||
| smb | ppisati, Unprotected remote firmware update... That is either the big conspiracy or just the usual unlimited stupidity one hears about. :-P | 08:18 |
| ppisati | smb: after the rdrand incident, you never know | 08:21 |
| ppisati | smb: the guy says "Well, as all research projects it evolved from using the flash update program which came with the NIC and simply feeding it my modified firmware to using more sophisticated techniques like discovering a remote update capability. The current version simply sends the appropriate packets to vulnerable cards and updates them." | 08:22 |
| smb | Yeah. Though some are apparently better protected than others. And then there is the problem that even the same chip might not be always the same as he states later. | 08:23 |
| ppisati | yeah, read it | 08:23 |
| * apw yawns | 08:37 | |
| apw | (somewhat theatrically at that) | 08:37 |
| smb | apw, WELCOME, to the next week! (sticking with the theatrically theme) | 08:55 |
| === psivaa-afk is now known as psivaa | ||
| xnox | When will fix for bug #1276739 land in -updates pocket? (as in which precise sru cadence is that in) or are there udebs that i can fetch off somewhere with that fix included? | 13:16 |
| ubot2` | Launchpad bug 1276739 in linux (Ubuntu Precise) "partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb" [High,Fix committed] https://launchpad.net/bugs/1276739 | 13:16 |
| apw | xnox, that hshould be in this weeks builds, though i thin the US may be off today | 13:18 |
| apw | xnox, ie in the archive within 3 weeks | 13:18 |
| xnox | apw: ok, thank you. | 13:21 |
| xnox | apw: and in -proposed pocket that would be in ~1 week time? | 13:21 |
| xnox | (or is that straight away, after current set of -proposed kernels is released) | 13:22 |
| apw | xnox, it'd be whenever they are built yeah, so sometime this week | 14:41 |
| rsalveti | apw: mind updating the flo kernel with one additional patch? I publish it at http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/flo, and also did a version bump | 15:06 |
| rsalveti | apw: would just need it to be merged and pushed to the archive | 15:06 |
| apw | rsalveti, ack | 15:07 |
| rsalveti | apw: also tested kernel for manta/mako, all good, but we should keep them in the ppa still | 15:07 |
| rsalveti | until we're done with the android 4.4 porting (close :-) | 15:08 |
| apw | rsalveti, i presume from the messages from the archive, that you are copying them out as you feel ready yes? | 15:08 |
| rsalveti | apw: yes | 15:08 |
| apw | rsalveti, so i will continue to ignore them in the PPA | 15:08 |
| rsalveti | apw: yeah, publishing them in the ppa is fine, I can copy them over once we're good | 15:08 |
| apw | works for me (us) | 15:09 |
| rsalveti | great | 15:10 |
| rsalveti | apw: also published a small fix for manta: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/manta, so we can have a working power indicator with 4.4.2 | 15:47 |
| apw | rsalveti, flo is building in the PPA | 15:55 |
| apw | rsalveti, ack on the manta change | 15:59 |
| rsalveti | apw: awesome, thanks | 16:12 |
| lfaraone | I wasn't sure whether to file a new bug; I'm experiencing similar issues to bug 1270808 , but we have different wireless chipsets, and that bug was marked incomplete. I opened a new bug, bug 1281170. Let me know if I should instead mark it as a duplicate and just add info to the first bug. | 16:21 |
| ubot2` | Launchpad bug 1270808 in linux (Ubuntu) "iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 2" [Medium,Incomplete] https://launchpad.net/bugs/1270808 | 16:21 |
| ubot2` | Launchpad bug 1281170 in linux (Ubuntu) "iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2 on Intel Centrino Advanced-N 6205" [Undecided,New] https://launchpad.net/bugs/1281170 | 16:21 |
| xnox | i'm working on dmraid -> mdadm upgrade path. | 16:38 |
| xnox | dmraid seems to generate funny targets e.g. /dev/mapper/isw_ebebhgdagf_Volume1p1, where as mdadm seems to just do Volume1p1 type names. | 16:38 |
| xnox | i understand taht isw is just raid type, but i'm failing to find where ebebhgdagf is defined, all ID's returned by mdadm tools are not that =( | 16:38 |
| TJ- | xnox: IIRC, they come from the metadata signature created by the controllers, Promise are different to Nvidia, etc. | 16:43 |
| xnox | TJ-: hm. so i'm definately missing udev rules to (a) run kpartx against containers / mdadm raid arrays (b) setup compat symlinks to all from previous.... | 16:45 |
| apw | rsalveti, manta is building in the PPA | 17:10 |
| rsalveti | apw: thanks | 18:09 |
| smb | xnox, I though I had seen it somewhere in the dmraid code. Of course I probably won'T find it that quickly. But I think it was part of the meta-data the adapter write (some kind of uuid) | 18:28 |
| xnox | smb: hm... if it's dmraid custom algo, then i don't want to use it. If it is something that i can also access elsehow (e.g. via kernel, sys, or mdadm) then it's something I can use. | 18:30 |
| xnox | smb: otherwise i'm working on dmraid to generate /dev/mapper/Volume1p2 symlinks, to match what mdadm would have done. (in addition to current /dev/mapper/isw_aewlfss_Volume1p2) | 18:31 |
| smb | xnox, Hm, is blkid maybe returning some of it...? I don't have the computer with isw turned on right now | 18:32 |
| smb | Ok, I turned it on and blkid is not telling much. But mdadm --examine on a drive contains a "Family" field which looks like it could be a label like dmraid used... | 18:39 |
| smb | Otherwise the code in dmraid is in lib/format/ataraid/isw.c | 18:40 |
| smb | xnox, ^ | 18:40 |
| xnox | smb: well, inside isw.c I got lost =) let me mount everything with mdadm and check the family bits. | 18:43 |
| smb | I could imagine it needs at least some additional prefix that is per-container as I think each container could have the same volume names... not that I got a setup like that | 18:43 |
| xnox | smb: yeah, family looks plausible, but it's different from what dmraid reports. | 18:45 |
| smb | bah... | 18:45 |
| xnox | smb: for some reason in dmraid code i see family_num to be calculated using a checksum and current time =/ | 18:47 |
| xnox | nah, that's creation | 18:47 |
| xnox | smb: actually i think family is the right field here, but looks like mdadm is mangling it. | 18:51 |
| smb | xnox, Hard to be sure if both disagree on contents. :( | 18:51 |
| smb | xnox, I agree the _name function in dmraid which seems to produce the content is mind boggling | 18:52 |
| smb | At least at this time of day | 18:52 |
| smb | xnox, Ok, I think what dmraid uses there is isw->family_num which seems to be set by "isw->family_num = isw->orig_family_num = _checksum(isw) + time(NULL);" | 19:04 |
| xnox | smb: at volume creation time, one needs to put something random there. | 19:05 |
| xnox | smb: ditto is done in mdadm. | 19:05 |
| xnox | smb: i've now done this: | 19:05 |
| xnox | dmraid -i -n | grep family | 19:05 |
| xnox | and mdadm --examine /dev/md127 | grep Family | 19:05 |
| xnox | first one is in base10, the mdadm one is in hex, but they match \o/ | 19:06 |
| smb | ah | 19:06 |
| smb | cool :) | 19:06 |
| xnox | smb: but they are different from the original isw_$(string)_Volume2 | 19:07 |
| smb | xnox, Oh hrm, I thought from the code they both should be ... but meh, no one should rely on the exact pathname nowadays... | 19:09 |
| xnox | smb: i'm trying to create a stable name. | 19:10 |
| xnox | smb: at the moment filesystem UID is used by grub and "dmraid-style mapper name" by /etc/fstab on existing installations. | 19:10 |
| xnox | one shouldn't use FS UUID, as then filesystem get mounted directly - instead of from the assembled raid device. | 19:11 |
| xnox | and a /dev/mapper/* name so far is unstable =) | 19:11 |
| smb | Yeah, well I usually used lvm on the volume... but one cannot rely on that... | 19:12 |
| xnox | smb: oh, i'm doing without lvm upgrade case. | 19:12 |
| xnox | smb: yeah, with lvm we have our act together and it doesn't matter much what the RAID device names are. | 19:12 |
| smb | Yeah... but right for the other case it would be nice if it would not change | 19:13 |
| smb | :q | 19:15 |
| smb | xnox, Oh gosh... | 19:35 |
| smb | Try using the family number in decimal and replace each digit by 'a'+n | 19:36 |
| smb | xnox, I bet mdadm family number in your case is f6de49f9 | 19:41 |
| xnox | smb: yes, it is. | 19:54 |
| smb | xnox, So that is the magic... dunno why dmraid thought it needs to mange a decimal number into letters... :/ | 19:55 |
| smb | *mangle | 19:55 |
| xnox | smb: apart from I didn't understand the algo =) | 19:55 |
| smb | Oh, you take each digit and replace 0 with a, 1 with b, 2 with c... | 19:56 |
| xnox | smb: sigh =) | 19:56 |
| xnox | smb: gotcha. | 19:56 |
| xnox | smb: because hex is bad, i guess =) | 19:57 |
| smb | But it wasn't hex :) | 19:57 |
| smb | oh they could have done hex maybe... :-P | 19:57 |
| xnox | smb: as in mdadm chose to use hex representation of family_number. | 19:57 |
| smb | Yeah... imo that is good enough and even guarantees a certain length | 19:58 |
| smb | for an uint_32 at least | 19:58 |
| smb | hm, nm only with prefixed 0s and you can do that with uints too | 19:59 |
| smb | so really no idea... | 19:59 |
| smb | The _name function also hurts your brain because they first use %u in a special snprintf and then run that mk_alpha over some of it... | 20:00 |
| rsalveti | apw: mind updating the meta package for linux-manta as well? (in the c.k ppa) | 20:04 |
| apw | rsalveti, uploaded | 21:24 |
| rsalveti | apw: awesome, thanks again | 21:27 |
| === zz_mwhudson is now known as mwhudson | ||
| === mwhudson is now known as zz_mwhudson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!