[01:38] <lamont`> BenC: it still says find: /lib/firmware/2.6.22-10-hppa64: No such file or directory with -10.30, just fyi. :)
[03:16] <doko> kylem, BenC: please could you add lpia support to: linux-backports-modules-2.6.22 linux-meta linux-source-2.6.22 linux-ubuntu-modules-2.6.22
[09:13] <kraut> moin
[09:43] <verwilst> morning
[11:30] <tseliot> BenC: can I steal a minute of your time?
[01:54] <paran> could someone look at bug 92553? I have sent two mails about it to the kernel-team list, the last one with a patch attached, but both have been ignored.
[01:54] <paran> if there is something wrong with my solution i'd really like to know so that I can fix it.
[01:55] <jwendell> Hi, BenC. I'm seeing on changelog you dropped snd-hda-intel on version 10.30. Now i have no sound on my laptop
[01:55] <jwendell> BenC, what should i do in order to have my sound back?
[02:41] <zul> hah someone wants cfs
[02:59] <verwilst> hi zul
[03:00] <verwilst> zul: you have mail
[03:00] <verwilst> zul: already gets a lot further than without the patch :)
[03:05] <zul> ill send you a patch
[03:07] <verwilst> okido
[03:07] <verwilst> go ahead, i'll test it right away
[03:07] <verwilst> an updated "diff" ?
[03:08] <zul> yeah it'll have to be later though since I just got into work
[03:12] <verwilst> ah ok :) after work you mean?
[03:12] <zul> probably
[03:12] <verwilst> ok! enjoy your work then :)
[03:29] <ogra> zul, https://lists.ubuntu.com/archives/ubuntu-users/2007-August/121818.html is that known ?
[03:30] <zul> ogra: not that i know of
[03:33] <zul> ogra: http://lists.xensource.com/archives/html/xen-users/2006-10/msg00103.html
[03:35] <ogra> i'll point him to that, thanks
[03:36] <zul> no probs
[03:44] <verwilst> zul: found the problem i think
[03:44] <zul> oh?
[03:45] <verwilst> you set LOCALVERSION to "-xen"
[03:45] <verwilst> but you have an EXTRAVERSION in make, that's -10-xen
[03:45] <verwilst> making it -10-xen-xen
[03:45] <zul> ok
[03:45] <verwilst> setting the localversion in config.amd64 to "" should fix it
[03:45] <verwilst> trying now
[03:46] <verwilst> zul: the kernel itself compiles fine though
[03:52] <paran> ignored once again. am I the only one actually using the linux-image-debug-packages? :-)
[04:26] <verwilst> zul: linux-headers-2.6.22-10-xen_2.6.22-10.30_amd64.deb and linux-image-2.6.22-10-xen_2.6.22-10.30_amd64.deb are present! ;)
[04:26] <verwilst> so it works
[04:26] <verwilst> i'll go home in 30 mins and try booting with it
[04:26] <zul> ok
[04:26] <verwilst> ( had to add amd64 in control first :)
[04:26] <verwilst> and the small fix to config.amd64
[04:31] <verwilst> zul: Signed-off-by: Bart Verwilst <bart@verwilst.be>
[04:31] <verwilst> hehehe
[04:33] <Kano> hi
[04:33] <Kano> config-2.6.22-10-generic:# CONFIG_SND_HDA_INTEL is not set
[04:33] <Kano> is that by purpose?
[04:34] <rtg> Kano: CONFIG_SND_HDA_INTEL is fubar'd. It being worked on.
[04:36] <mjg59> Kano: Check Launchpad. It's a known issue.
[04:36] <tseliot>  hi, does anybody know why my patches (for Feisty and Gutsy) haven't been approved yet? https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/66 https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/67
[04:38] <Kano> hmm system lock with that kernel...
[04:40] <BenC> tseliot: I thought that were in there...I'll check them in a few
[04:40] <Kano> why was hda-intel not active??
[04:40] <tseliot> BenC: thanks
[04:41] <mjg59> Kano: Because it was in linux-ubuntu-modules instead
[04:42] <Kano> any specific reason why it was not patched directly
[04:42] <mjg59> Because of a desire tokeep the Linux source as close to upstream as possible
[04:43] <Kano> why have been most of my kernel patches ignored
[04:43] <Kano> only the one from mm was integrated
[04:44] <mjg59> What makes you think they've been ignored?
[04:44] <Kano> they did not have been applied
[04:45] <Kano> and i added a bug one month ago for each of em
[04:45] <Kano> how do you compile linux-ubuntu-modules for one flavour only
[04:46] <zul> *sigh* here we go again
[04:48] <mjg59> Kano: linux-restricted-modules is generally handled at a lowerpriority than the core kernel. I'll be done before the release.
[04:48] <Kano> patches that only change 1 or 2 lines...
[04:48] <Kano> but the 2 others
[04:48] <Kano> about hostap_cs and the via southbridge on intel
[04:48] <Kano> currently i even patch the a new siemens id
[04:49] <Kano> these 2 where against 2.6.22 directly
[04:50] <BenC> Kano: fakeroot debian/rules binary-modules-generic
[04:50] <Kano> BenC: thanx. and for restricted too?
[04:51] <BenC> for lrm, you're just going to have to build the whole thing
[04:51] <BenC> no one has switched it over to the new build system yet, because it's ugly and hairy
[04:52] <Kano> not good...
[04:52] <mjg59> Kano: Working patches welcomed
[04:52] <Kano> they work
[04:52] <Kano> but still ignored
[04:52] <mjg59> There's no real incentive to change it - lrm builds correctly, and for the purposes of Ubuntu development there's no real incentive to build it for a single flavour
[04:53] <lamont> it's not like the build takes a long time
[04:55] <verwilst> zul: just to let you know, the kernel boots fine
[04:55] <lamont> 13 minutes is quick
[04:55] <verwilst> xend starts, xm list works, ...
[04:55] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128289
[04:55] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132466
[04:55] <Kano> patches working, not included
[04:55] <mjg59> Kano: Thank you. We can list your bugs.
[04:55] <mjg59> Kano: They're patches of low importance and low risk, so they're not high priority righ tnow
[04:56] <mjg59> We're part-way through a development cycle. If they're not there by beta, then please feel free to remind us.
[04:56] <Kano> well risk is really low, just apply em
[04:56] <Kano> i know that they are correct. otherwise pure ubuntu kernels are absolutely useless for me
[04:56] <mjg59> But there's no point whatsoever in doing so until then. It won't make things happen any faster.
[04:57] <BenC> Kano: it's true, we could "just apply them", but the reality is, those are not the only two bugs we have to look at...we have to prioritize, else we'll never get the big problems taken care of
[04:58] <BenC> Kano: but your fixes will get in
[04:58] <Kano> there is a new one i currently patch. the one who found it reported it here:
[04:58] <Kano> http://bugzilla.kernel.org/show_bug.cgi?id=8932
[04:59] <Kano> also only id changes
[04:59] <Kano> 2 lines
[04:59] <mjg59> Kano: Please file a bug and link to the upstream bug
[04:59] <nixternal> quick question...with gutsy, my realtek 8139 lappy eth connection craps out on the wan, works fine on the lan...happens after a while of use, and then comes back...would this be kernel related at all? I just started noticing this yesterday (24+ hours ago)
[05:00] <BenC> Kano: if you want things faster, apply for a kernel.ubuntu.com account, clone our tree, commit the patches and send a pull request
[05:00] <nixternal> not wireless
[05:00] <nixternal> I can hit my gateway fine, but anything outside of my network I can't...and it is only this laptop, it doesn't happen with any other gutsy machine here
[05:00] <lamont> ah, ok
[05:00] <BenC> nixternal: doesn't sound like kernel
[05:00] <lamont> that sounds more like a router issue
[05:01] <nixternal> why only this laptop and not my other machines?
[05:01] <nixternal> hehe
[05:02] <nixternal> you know, I wouldn't 100% put it past the router either after our storms and issues last night, but it is just odd that it only happens to one machine
[05:02] <BenC> nixternal: could be something whacky with network-manager :)
[05:02] <nixternal> BenC: network-mangler you mean :)
[05:02] <BenC> for example, if it dropped the default route
[05:02] <mjg59> nixternal: Are the other machines running Linux?
[05:03] <nixternal> mjg59: yessir
[05:03] <mjg59> Hm. Ok.
[05:03] <mjg59> If the card is able to talk to your local network, it's highly unlikely that it's a kernel issue
[05:03] <mjg59> Unless your upstream is *very* odd
[05:03] <nixternal> ie. I am connected to my server which is running gutsy, that is how I am able to stay on IRC
[05:03] <BenC> nixternal: next time it happens, check "route" output to see if it's sane
[05:03] <nixternal> BenC: will do
[05:03] <mjg59> Best you could do would be to get a tcpdump of the the traffic when it's affected
[05:04] <Kano> ubuntu is really fast... just as fast as the ntfs-3g development. there is 1.8 out and 1.7 in repository...
[05:04] <nixternal> looks sane
[05:04] <nixternal> it is affected right now...let me try tcpdump
[05:04] <Kano> do i really have to report every bug...
[05:04] <zul> yes
[05:05] <zul> then it would never get fixed
[05:05] <BenC> Kano: when we hit kernel freeze, we only take fixes that have bug reports associated with them
[05:05] <Kano> is nobody tracking upstream on major packages, and ntfs-3g is major
[05:05] <Kano> it writes on ntfs
[05:05] <mjg59> Kano: We're past upstream version freeze.
[05:05] <BenC> Kano: pkl is taking care of our ntfs-write support
[05:06] <mjg59> No new upstream versions will be accepted unless somebody explicitly requests them.
[05:06] <Kano> i use it since 14 days without problems
[05:07] <zul> BenC: what should i do with the cfs wishlist bug report?
[05:07] <BenC> zul: bug#?
[05:07] <nixternal> heh, as soon as I run tcpdump the connection comes back
[05:08] <zul> 134491
[05:08] <rtg> zul: revert it to wishlist from confirmed.
[05:09] <zul> its already wishlist
[05:10] <rtg> zul: never mind. I confused status with importance.
[05:11] <zul> BenC: i say tell them to wait til gutsy+1 
[05:11] <BenC> zul: mark as wont fix in 2.6.22 with a comment about being too late, and tag it gutsy-plus-one
[05:12] <BenC> zul: actually, better tag may be deferred
[05:15] <zul> BenC: done
[05:15] <BenC> zul: gracias
[05:15] <zul> no probs
[05:20] <tseliot> BenC: if you have any questions on my patches I'll be glad to answer
[05:23] <Kano> why do you compile ipw3945 and iwlwifi?
[05:24] <mjg59> Kano: Because iwlwifi is currently not stable on 3945
[05:24] <Kano> and why is it compiled then
[05:24] <Kano> you would need to blacklist it
[05:25] <mjg59> The 3945 IDs have been removed
[05:25] <mjg59> It's used for 4965
[05:25] <Kano> hmm
[05:26] <Kano> thats older lirc or
[05:26] <BenC> tseliot: sure thing
[05:26] <BlueDevil> BenC: can you share how you built the packages for nvidia 100.14.11 driver and l-r-m please?
[05:26] <BlueDevil> i'd like to build the same packages for my system. thanks
[05:26] <BenC> BlueDevil: I'm not sure what you mean
[05:26] <Kano> hmm lirc is new
[05:26] <Kano> but why is ttusbir not there
[05:27] <BenC> BlueDevil: install the latest nvidia-glx-new and you have that
[05:27] <BlueDevil> BenC: i'm running a custom kernel (because the stock kernel does not support more than 4G of ram) so i need to build l-r-m myself, right?
[05:27] <Kano> any specific reason to skip that module?
[05:28] <BenC> BlueDevil: you're better off just downloading the nvidia installer and running that for your kernel
[05:28] <BenC> Kano: lirc support came from a community member, we didn't decide what to put in there, we too what the guy gave us
[05:28] <BlueDevil> BenC: would i be able to deinstall what the installer installed if I ever wanted to?
[05:29] <BenC> took
[05:29] <BenC> BlueDevil: yes
[05:29] <BlueDevil> how?
[05:29] <tseliot> BlueDevil: you can install nvidia-glx-new nvidia-glx-new-kernel-source (or whatever it is called) and build the kernel module with module-assistant
[05:29] <Kano> BenC: i think he missed that the new lirc has a new module
[05:29] <BenC> BlueDevil: the installer will uninstall too
[05:30] <BlueDevil> tseliot: i'm not sure how to build that
[05:30] <BenC> Kano: I wasn't very keen on lirc being included in lum anyway, but the ubuntu-media folks needed it to support hw out of the box
[05:30] <Kano> yes it is needed just like the new module 
[05:30] <BlueDevil> are there any chances that the kernel in gutsy will support more than 4G ram by default?
[05:30] <BenC> Kano: then by all means include it
[05:30] <tseliot> BlueDevil: you can uninstall it by typing sudo sh nameoftheinstaller --uninstall
[05:30] <Kano> i think only the CONFIG_LIRC line is missing
[05:30] <Kano> the source is there
[05:31] <BenC> BlueDevil: Not likely to happen in our default 32-bit kernel...why not run 64-bit?
[05:31] <Kano> will check it
[05:32] <tseliot> BlueDevil: this is something we can discuss elsewhere. I can show you how to do that in just few mouse clicks
[05:32] <BlueDevil> BenC: because i'm in the online video business and 64bit is nothing but trouble in that respect (flash + w32codecs) :(
[05:32] <BlueDevil> tseliot: can I pm you?
[05:32] <tseliot> BlueDevil: sure
[05:32] <BlueDevil> thx
[05:32] <BenC> BlueDevil: Maybe you should run the -server kernel?
[05:33] <BlueDevil> BenC: i tried the -bigiron but nvidia wouldn't work, would i have better success with -server?
[05:33] <BenC> BlueDevil: it's worth a shot
[05:34] <Kano> it seems you manually added those, well should be no problem...
[05:41] <Kano> well the makefile mod is simple, whats with that 0list?
[05:41] <Kano> or should it be in every arch
[05:42] <BenC> 0list is a template
[05:43] <Kano> CONFIG_LIRC_TTUSBIR=m
[05:43] <Kano> should i add it everywhere?
[05:43] <BenC> each arch needs the CONFIG_* line in it
[05:43] <BenC> yeah, including the 0list file
[05:44] <Kano> well you have to check if it compiles..
[05:44] <BenC> I'm not going to include a patch that I know I have to test
[05:44] <Kano> i can not compile sparc and such things
[05:45] <Kano> that is no real patch, i just added the line in the makefile
[05:45] <BenC> you don't have to test it everywhere
[05:45] <BenC> just binary-modules-generic will make me happy
[05:45] <BenC> Kano: does it apply with the patch command?
[05:45] <Kano> tested that on i386
[05:46] <Kano> wait one second
[05:49] <Kano> should i dcc you the patch
[05:49] <Kano> or upload
[05:49] <cjwatson> people still use dcc?
[05:49] <Kano> a very simple one
[05:50] <BenC> hehe
[05:50] <BenC> I haven't used dcc since the efnet days
[05:50] <Kano> http://kanotix.com/files/kernel/linux-ubuntu-modules-2.6.22-2.6.22-lirc-ttusbir.patch
[05:50] <BenC> Kano: email to kernel-team is preferred
[05:51] <BenC> kernel-team@lists.ubuntu.com
[05:54] <verwilst> zul: could i recommend 1 more patch?
[05:55] <verwilst> http://overlays.gentoo.org/proj/xen/browser/patches/tags/2.6.20/fedora-xen-patches-2.6.20-2925.13.fc7/1665-linux-2.6-disable-netback-checksum.patch?rev=10
[05:55] <verwilst> it's a one-liner
[05:55] <verwilst> but it makes sure you don't need to do ethtool -K ethX tx off
[06:01] <Kano> why is ndiswrapper 1.45 not 1.47?
[06:01] <BenC> Kano: UPSTREAM-VERSION-FREEZE
[06:02] <Kano> do you really know how long 1.47 was avalable
[06:02] <BenC> unless we have a compelling reason to do so, it wont get upgraded
[06:02] <Kano> bugfixes
[06:02] <BenC> Kano: can you list the bugs?
[06:02] <BenC> Kano: can you tell me how severe they are?
[06:02] <Kano> 1.47 is out since 27. 04.
[06:02] <Kano> 4 months
[06:02] <BenC> if we go by bug-fix alone, we'll be upgrading till release day
[06:03] <Hobbsee> BenC: Kano seems to be out to troll, so probably wont answer that
[06:03] <Kano> Hobbsee: should i add all changelogs since 1.46 to the bugreport?!
[06:03] <Hobbsee> BenC: that being said though, upgrades of ndiswrapper are usually a good idea, for the hellish cards that require them.
[06:03] <Hobbsee> Kano: list the bug fixes.  not changes.  
[06:04] <mjg59> Kano: If you can point us to people who are having bugs in Ubuntu, that's significantly more compelling
[06:04] <Kano> Version 1.46 has been released. Short summary of changes since 1.45:
[06:04] <Kano>     * Fixed crash with large transfers (bug in version 1.45)
[06:04] <Kano> Version 1.47 has been released. Short summary of changes since 1.46:
[06:04] <Kano>     * Fixed random (occassional) crash issues with 64-bit drivers (observed with Broadcom driver)
[06:04] <Kano>     * Fixed compilation issues with version 1.46
[06:04] <Kano> so you see 64 bit fixes
[06:05] <verwilst> zul: mail sent
[06:05] <verwilst> bye!
[06:06] <BenC> Kano: 64-bit doesn't concern me too much
[06:06] <BenC> people have way too many excuses already to use 32-bit even on x86_64 hw
[06:06] <Hobbsee> ndiswrapper seems to have a disobliging habit of *breaking* some cards, the further up they go.
[06:07] <Hobbsee> version-wise
[06:07] <Kano> Hobbsee: i really prefer to use latest code
[06:07] <BenC> yeah, hence, fixing things may not be worth breaking other things
[06:07] <Hobbsee> Kano: i prefer to use code that *works*.
[06:07] <Hobbsee> Kano: tell that to my old wifi card, which broke with later versions of ndiswrapper.
[06:08] <Kano> Hobbsee: then you are not able to go to #ndiswrapper and speak to giri
[06:08] <Kano> i did serveral times, even donated to him
[06:08] <Hobbsee> Kano: you assume, wrongly, that i did not.
[06:09] <Kano> and it still does not work with 1.47?
[06:09] <Hobbsee> see the part about "old"
[06:09] <Hobbsee> it broke in 1.17, iirc.  i no longer have that card.
[06:10] <Kano> what i absolutely know is that the feisty ndiswrapper was unusable at all for my card
[06:11] <Kano> so i skipped feisty not because of that, but due to other problems
[06:13] <Kano> hmm even 1.48rc1 there...
[06:16] <mjg59> We're not shipping a release candidate
[06:18] <Kano> then use 1.47
[06:19] <mjg59> Kano: As I said, if you can point us to bugs filed against Ubuntu that show people having problems, it's much easier to convince the release team that we should do that
[06:19] <mjg59> But if we have no evidence of people having problems, we're not going to take the risk of introducing new and unknown bugs
[06:20] <Kano> the only reason that i see is that your current ubuntu users are not heavy ndiswrapper users. but kanotix users are
[06:21] <Kano> and when i want use ubuntu as base then i dont want to have worse hw support than before
[06:21] <mjg59> Kano: Perhaps the needs of your users do not align well with the Ubuntu release methods?
[06:23] <BenC> Kano: any time you use a release distribution, you are going to have slightly out-dated software
[06:24] <BenC> there's no way to get a stable dist with latest software all around
[06:24] <Kano> BenC:  sure, but not the main drivers
[06:24] <BenC> Kano: I'd hardly call ndiswrapper a main driver
[06:24] <Kano> ntfs-3g, ndiswrapper are thing that i monitor
[06:24] <mjg59> Kano: We don't accept new upstream versions after the 16th of August unless there are important bugs that we know they will fix
[06:24] <BenC> Kano: important to you doesn't mean important to all of our users
[06:25] <mjg59> Kano: If that's unacceptable to you, then I suggest that you either changethe process (you'll want to contact the technical board) or find a new source of kernels
[06:29] <doko> kylem, BenC: please could you add lpia support to: linux-backports-modules-2.6.22 linux-meta linux-source-2.6.22 linux-ubuntu-modules-2.6.22
[06:33] <BenC> doko: I'm pretty sure it's in linux-source, linux-meta and linux-ubuntu-modules
[06:33] <doko> lookking
[06:33] <BenC> doko: just needed for lbm and lrm
[06:40] <doko> BenC: linux-meta doesn't build linux-headers-generic and linux-image-generic . correct?
[06:42] <BenC> doko: yeah, it does
[06:43] <doko> BenC: and linux-ubuntu-modules and linux-backports-modules-2.6.22 is not needed for the live CD, apparently
[06:44] <BenC> doko: linux-ubuntu-modules is
[06:47] <doko> BenC: ok, was confused that lpia doesn't have a -generic, but just a -lpia kernel. but as long as that's roughly the same config as i386 that will let us boot from the liveCD
[06:47] <BenC> doko: well, linux-ubuntu-modules-2.6.22-abi-generic is, not sure about the meta package
[06:48] <BenC> doko: lpia flavour is pretty much the same as ume
[06:48] <doko> apt-cache -n search linux-ubuntu doesn't show anything
[06:51] <tseliot> doko: linux-restricted-modules
[06:51] <doko> yes, missing as well
[06:52] <tseliot> doko: instead of linux-ubuntu-modules
[06:57] <zul> doko: i was wondering why you added ipia to xen-3.1?
[06:58] <tseliot> doko: doesn't this command return anything??? apt-cache -n search linux-restricted-modules 
[07:00] <doko> tseliot: it does on amd64, not on lpia
[07:00] <doko> zul: looking if it builds and works with gcc-4.2
[07:01] <zul> ah ok
[07:02] <tseliot> doko: sorry, I didn't read ipia flavour...
[08:04] <BlueDevil> what is the downside of compiling a kernel with HIGHMEM64G=y vs HIGHMEM4G=y?
[08:05] <BenC> BlueDevil: more overhead
[08:05] <BenC> you really only want 64G enabled if you have > 4G of memory
[08:06] <BlueDevil> do you know if any benchmarks have been done?
[08:06] <BenC> otherwise it hurts you performance wise and takes up more memory just for memory management
[08:06] <BenC> BlueDevil: I can't point you to any, but I'm pretty sure it's been done
[08:08] <BenC> I think most people assume that you'll be running a 64-bit kernel on such machines
[08:08] <BenC> there are ways to run 32-bit stuff decently on 64-bit
[08:08] <BenC> ia32-libs and friends help a lot
[08:09] <BlueDevil> the last time i ran flash in a 32bit chroot it took away part of my filesystem when it crashed; i didn't even think that was possible
[08:10] <BenC> were you running it as root?
[08:10] <BlueDevil> no
[08:10] <BenC> I don't see how it can corrupt your fs if it isn't run as root
[08:10] <BenC> that would be a major bug :)
[08:11] <BlueDevil> i didnt investigate much the machine being a production one; i just reinstalled 32bit
[08:12] <BlueDevil> AFAIK it didn't do anything outside of the chroot but i wasn't going to risk it
[08:17] <BenC> BlueDevil: why not ditch the chroot and use ia32-libs and the 32-bit firefox plug-in wrapper?
[08:18] <BlueDevil> BenC: i don't think those were available at that time
[08:18] <BlueDevil> i was on dapper-1
[08:18] <BlueDevil> or -2
[08:19] <BlueDevil> everybody was recommending 32-bit chroot to run flash
[08:20] <BlueDevil> looking now at ia32libs
[08:21] <BlueDevil> what are my options for w32codecs?
[08:25] <JanC> w32codecs are illegal, so...  ;)
[08:26] <tseliot> BlueDevil: have a look at this sticky in the forum: http://ubuntuforums.org/showthread.php?t=191205
[08:27] <BlueDevil> JanC: why are w32codecs illegal?
[08:27] <BlueDevil> i own a windows xp oem copy for the machine
[08:28] <pmjdebruijn> BlueDevil, because MS' license probably says you may only use the codecs in conjunction with WinXP
[08:32] <JanC> that license says that, but that part might be illegal in itself in some countries
[08:33] <JanC> OTOH, there is no license that allows redistribution of those codecs in the way w32codecs does
[08:33] <JanC> so if you use the codecs on your WinXP partition, that might be okay, but w32codecs certainly isn't
[10:14] <verwilst> http://pastebin.ca/669541 <- anybody knows about this?
[10:16] <verwilst> had to modprobe dm-mod manually