[00:00] please help [00:00] I gave up on my af9015 card, I've started a second time on a tv card that uses the em28xx drivers -- both drivers have built, but neither attach to their card when it is installed [00:00] and I have the latest hardware -- but there's scant little, virutally no results for em28xx support. these are both dvb drivers [00:00] ** firmware, not hardware [00:01] I can't find any documentation for em28xx that's recent [00:13] the modules load if I modprobe them, and after I did that the administration->hardware drivers found a firmware for me to download for my card, but still I get nothing from my card with that firmware installed [00:14] online I found something saying that a different firmware was needed but its not working either [00:15] and I just tried removing the firmware that the system automatically installed and reloading the em28xx modules, but that didnt pick up either [00:19] lsusb doesn't list any name for the hardware, like this is all it says right now: Bus 001 Device 029: ID 1d2c:1012 -- but there's like a million lines of output in lsusb -v for the device: http://pastebin.ws/6htngd [01:04] Can anyone tell me if i am correct in my understanding that programs must request a kernel write to the hdd on its behalf and that programs usually dont have access to the hdd to write to it on its own? [02:04] morning guys [02:18] ogasawara: you may be my new best friend ;) [02:18] vanhoof: heh, I'm not sure if that's good or bad :) [02:19] ogasawara: def good :) [02:20] ogasawara, be afraid if vanhoof is offering to be your bff....:-/ just sayin' [02:20] lol thanks akgraner [02:20] opps inside voice - I mean vanhoof is awesome... yeah that's what I meant :-) === kamal is now known as kamal-away [03:25] where would i locate the debug kernel image for lucid 2.6.32? [03:31] greenfish: what debug info are you after? [03:32] vmlinux compiled with debug symbols [03:37] not sure if there's a pre-built one; but most of the time you can get by with the symbol table & System.map [03:37] greenfish: http://ddebs.ubuntu.com/pool/main/l/linux/ [03:37] oh, cool. [03:37] greenfish: however the 2.6.32 ones broke for a long period [03:37] greenfish: so I don't see them there [03:37] greenfish: you might be outta luck [03:38] yeah. thats tough for a sysadmin who needs to profile things... [03:38] pgraner: i wasn't seeing them either [03:40] greenfish: I know the build system for some reason was broke and I don't think we can go back and recreate, the next SRU kernel should have one tho [03:40] greenfish: what kind of profiling? 'perf'? [03:40] greenfish: what are you trying to debug, normally full symbols is overkill as jk was saying [03:41] pgraner: the tcp stack and memory management when certain applications in my stack are under extreme load [03:41] greenfish: perf is prob a better tool or ftrace [03:43] regardless of the tool, i'll need debug symbols to see what the kernel is doing [03:43] greenfish: are you familiar with perf or ftrace? You don't [03:43] perf might give me a call graph, but i'm much more familiar with oprofile [03:44] greenfish: not much we can do, as I said we can't recreate if its not urgent you can wait for the next SRU kernel and it will have ddebs [03:45] ahh. where are the backups? ;) [03:45] greenfish: they never got created, the build system was broke [03:45] yeah. tough to back that up then ;) [03:45] greenfish: unfortunately we don't use ddebs that often and when we realized it was too late [03:47] greenfish: so you're looking for hot functions in the kernel? [03:47] i see. there are 2.6.34 kernels in the ddebs pool. is that from maverick? [03:48] jk-: perhaps. i just need a full stack profile of the system under specific loads. [03:48] i'm not opposed to other tools, but i'd have to learn them before they would be useful to me [03:49] greenfish: yes those are maverick kernels [03:49] greenfish: if you install the maverick kernel and are experiencing the same issues you can use those ddebs to debug with the tools your familiar with [03:50] greenfish: I'm running the maverick kernel on the lucid userspace with no issues on both desktop & server so I'd give it a go [03:52] pgraner: terrific. can that be updated using apt with the right source and not interfere with non-kernel dependencies? [03:52] greenfish: perf should suit; `sudo perf record -a -f -g` and `perf report --call-graph -i perf.data` [03:52] apologies for the silly question, ubuntu is not my primary distro [03:55] or, alternatively, where can i find the build process for the 2.6.32 generic kernel? while the resulting binary may not be exactly the same, if i do a full build of both vmlinux, and vmlinuz then things should line up with little to no differences from the ubuntu build [03:58] greenfish: https://wiki.ubuntu.com/KernelTeam/ [03:58] thanks again [03:58] greenfish: then find the KnowledgeBase link and follow the link to build instructions [03:59] jk-: you got video conf working yet.... [03:59] pgraner: can set it up on my machine if you need [04:02] but putting it on a .mills host would be cool [04:02] jk-: how much resource do you need, I can give you sudo on frylock if you want [04:02] jk-: I'd like to see how well it works [04:03] pgraner: the server doesn't need much CPU [04:03] jk-: ok, lemme add you to the sudoers [04:04] yeah, happy to set it up for testing. it was just a hack for our virtual-coffee-machine calls though. [04:21] jk-: what'cha working on? [04:22] vanhoof: I hacked together a video conf server for our informal calls [04:22] just getting it set up on pgraner's machine [04:23] vanhoof: this way I can see your ugly mug [04:23] oh nice [04:23] pgraner: dont make me drive west :) [04:23] can skype do more than 1:1 [04:23] vanhoof: bring it (and some friends) [04:24] pgraner: if by friends you mean jess, and my dogs sure :) [04:24] pgraner: http://hphotos-snc3.fbcdn.net/hs575.snc3/31375_389772562186_511662186_4512783_5162068_n.jpg [04:25] ... a nightmare in the graner household lol [04:25] vanhoof: nope just something for murphy to play with [04:27] pgraner: does he get along w/ women? :) [04:27] vanhoof: yep [05:33] * jk- out for a bit [08:14] cooloney: do you know anything about this on mx51? http://pastebin.ubuntu.com/439766/ [08:15] I'm trying to boot a mainline mx51 kernel [08:15] it looks related to the mdio code you were hacking on? [08:17] amitk: i posted 2 patches to upstream [08:18] amitk: but Andy Fleming who is the phylib maintainer has some concern [08:18] cooloney: patches to fix this issue? [08:18] i don't have hardware to do furthur development [08:19] amitk: i'm not sure about that. [08:19] amitk: could you try my patch and test again [08:19] let me find the patch for you [08:20] * smb yawns [08:21] cooloney: l-a-k? [08:21] cooloney, Hi, just as info: boot is ok. If you can play around a bit, the better, but there is no real regression test plan for arm [08:22] amitk, Morning [08:22] moin smb [08:22] smb: ok, got it. GrueMaster will help to test it on his hardware [08:23] cooloney, Great, thanks! [08:24] * smb goes back to his long checklist [08:25] amitk: i sent them out to netdev mailist [08:25] amitk: did you subscribe to that mail list? [08:27] Morning smb [08:28] Morning amitk [08:28] hi lag [08:28] lHey lag [08:28] cooloney: I think not, but I'll find the archives [08:28] * smb punches the backspace key harder [08:28] amitk: http://kerneltrap.org/mailarchive/linux-kernel/2010/5/7/4566895 [08:28] smb: Has apw spoken to you regarding the new bug stuff yet? [08:29] amitk: i need rework on this patch, but don't have working hardware, so ...... [08:29] lag, Nope. I assume neither to you then [08:29] lag, Guess we need to get back to him later [08:29] smb: Sure [08:37] * apw looks blearly over his domain [08:37] * smb and lag already wait in the shadows for apw to arrive [08:38] apw: you make a poor warlord if your desk is your domain [08:38] cking, morning [08:38] hiya [08:38] smb: Speak for yourself ;) [08:38] amitk, heh indeed [08:39] * apw notes that 12 hours on linux armel is still building [08:39] I noted that, its surprising [08:39] amitk: It worked for Churchill [08:39] amitk, why is it supprising? [08:39] apw: I'd thought 5+5 hrs [08:39] it takes 6-7 hours to do 1 armel flavour, you added a new one yesterday [08:40] ok, so it should be about done now [08:40] 5.5 for the build itself, plus packaging time, which is huge [08:40] its in the last 30-40 mins yes [08:41] this brings up an issue we need to consider, for when you do get all arm branches in the same image [08:41] we can't afford to have a ton of flavours [08:41] by then (next 6 months), we will have ARM HW with 2GB RAM [08:41] oh the build is 'done' we ar in pkg*mangler [08:42] oh no, maybe not, seems to be back to linux-image now for versatile [08:43] we're talking to vendors to give us faster disk though (sata connections) [08:43] we need some 64 way arm servers [08:43] talk to Martyn @ Smoothstone [08:44] indeed [08:44] sadly adding omap probabally means we need to pull back all our freeze dates by a day [08:44] as now you can only do 1 arm build a day not two [08:46] I wonder how hard it would be to hack our scripts to do cross-compile for testing automatically [08:46] i do armel builds using crossbuilds primarily, but those don't seem to be able to make the tools side [08:46] you need one of those real cross-buildy qemu thingies [08:46] *automatic cross-compile for test-builds [08:47] you can do automated test builds using sbuild, though being qemu emulated its like 2:30 a flavour for me [08:48] apw: just for arm [08:49] to tooling i am using for just building the linux-image, works using cross compilers for armel builds automatically [08:49] and i just found sbuild, so am thinking on letting that be a backend [08:50] its an interesting approach for all platforms, not tried it for performance on x86, though i assume its native speeds [08:50] lag, To reply to "pseaking for yourself". I meant the bug processing thingy. Though I completely trust you to speak for yourself there, too. :) [08:50] the nice thing about sbuild is it seems to be a pbuilder style 'auto install deps' kind of thing, and uses aufs to retain the virgin original chroot [08:51] smb: I was joking. I meant I wasn't cowering in the shadows awaiting the arrival of our overruling leader. ;) [08:52] lag, Ah you prefer the open attack. :-P [08:52] * apw marshalls his forces [08:53] smb, apw: Full frontal! ;) [08:53] apw: how about using qemu running on x86 [08:53] * apw does not need any full frontal pictures at this time of day [08:53] and we native compile kernel for armel in qemu [08:53] apw: Are we going to chat today about the new bug processes? We didn't really get chance yesterday did we? [08:53] cooloney, that is what sbuilder does in this context. 2.5 hours a flavour still [08:54] apw: 2.5 hrs on emerald? [08:54] that was on a local box, a 4 way [08:54] not tried on emerald as yet [08:54] and if the x86 is very powerful, we can running several qemu instance and use dist-cc to distribute the building tasks to several qemu builder [08:55] cooloney: how many cores can qemu use effectively? [08:55] cooloney, yes i really was trying to say even there its not 'instant', yes much better than the real h/w [08:55] * abogani2 waves [08:55] I'm wondering about ubuntu-debian.git. What it is useful for? [08:55] * smb points to apw [08:55] though the performance on the real buildd is not guarenteed to be the same, not is the outcome [08:55] amitk: actually, i have no idea about that [08:55] abogani2, its a respository for the master copy of the debian build machinary [08:56] we are cleaning up the disparate copies in all our trees over the next few weeks [08:56] abogani2, But in general, it should become the source for what is in our debian directories [08:56] so that they all behave the same [08:56] the main trees will retain their own copied, but they will be regularly updated from the common copy [08:56] abogani2: unified build policy across all releases [08:56] as most changes there affect all releases and should be pushed out to all [08:57] as they relate to archive behavour which is the same regardless of release age [08:58] amitk, apw: Understand thanks. [09:17] #ifdef DEBUG [09:17] #define pr_devel(fmt, ...) \ [09:17] printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) [09:29] amitk, i see the armel build is in its 14th hour [09:30] still packaging? [09:30] yep, the dbg deps are bigger than the machine so it thrashes like pig i am sure [09:30] they take many minutes on emerald [09:30] let alone a memory starved arm [09:31] i have been saying arm takes 6-7 hours per falvour, and noone believes me [09:31] always whining... :-P [09:31] amitk, what worries me, is now is the stage where it goes 'package foo not in control file, BANG' [09:32] and throws away everything its done [09:32] yeah, I *hate* that [09:32] makes me want to cry [09:45] hmm, there seems to be something weird in your package build scripts, omap4 didnt build because the code below only seems to detect omap but not omap4 [09:45] imagelist=$(cat /build/buildd/linux-ti-omap4-2.6.33/debian/build/kernel-versions | grep ^armel | awk '{print $4}') [09:45] (thats right after "# unpack the kernels into a temporary directory") [09:45] and results in: ls: cannot access ../linux-image-2.6.33-900-omap_2.6.33-900.1_armel.deb: No such file or directory [09:46] * lag is ready to talk about 'moths in relays' with apw and smb [09:46] * smb can join [09:47] * apw gets tea [09:48] ogra: ok, thanks, i think i missed something in the debian script stuff [10:00] ogra: thanks, i forgot to replace omap to omap4 in debian.ti-omap4/d-i/kernel-versions.in [10:01] ogra: will upload and build again, although it will take 6hrs to build [10:02] ah, perfect [10:02] yeah, the babbage boards arent fast but reliable :) [10:16] good night * [10:25] apw: arm is done building [10:32] apw: all flavours of a single arch are built on the same machine, right? [10:32] amitk, yes all flavours are built sequentially on one machine [10:33] apw: could that be split up in debian/ ? Or is that buildd backend magic? [10:34] amitk, a source package is sequential per architecture, and single thread per architecture [10:34] *sigh* [10:34] but the point of your work is to make one kernel for all so we won't have an issue right [10:35] amitk, i suspect if we end up with more than 2 arm flavours in 'master' we will have to do something like make two source packages out of the same master tree [10:35] apw: that work is still a year away realistically [10:35] linux and linux2 [10:36] amitk, yep, but of course until you win that battle the arm variants are likely to remain branches, and their own packages, and threfore buildable in parallel [10:36] amitk, so likely self limiting in a lot of senses [10:37] true === smb is now known as smb-afk [11:14] guys, my upload to arm PPA build failed, [11:14] it is ti-omap4 kernel package, [11:14] i build it successfully in my local machine [11:14] but it failed in our build system [11:15] so i fixed it in my kernel pakcage and wanna to reupload, but it was rejected because of my initial upload is there [11:16] do you guys know how to change my package version without bumping my kernel ABI? [11:16] apw, amitk and smb-afk ^^^ [11:16] add build2 to the end of the version number [11:17] apw, why does that help? [11:18] apw: which file contains that version number i can change? [11:19] cking, you have to increment version numbers in every upload [11:19] cooloney, in the debian./changelog [11:20] apw: oh, sh*t, i know that. [11:20] the complaint is about the literal and total version number which must increment [11:20] apw: thanks [11:20] so build2 is a common way, you can use build3 etc when it fails again [11:20] though as a general rule, where i am testing sometihng i will upload as -10.20 i use ~pre1 ~pre2 as i go and never use the real number [11:21] allowing that to only appear in the main archive. that way someone running my test version is decernable as against the official build [11:22] apw: ok, understood. so normally, for this change, will you commit it into the kernel git? [11:22] apw: i think we just change the name for upload [11:25] cooloney, just for the upload yes [11:26] apw: thanks, man [11:26] apw: bug 569882 [11:26] Launchpad bug 569882 in linux (Ubuntu) (and 1 other project) "Suspend Lenovo Thinkpad X61 with card in SD card reader (affects: 3) (heat: 24)" [Undecided,In progress] https://launchpad.net/bugs/569882 [11:27] smb-afk, this looks to be a duplicate of your MMC card crashy on suspend bug ... [11:27] bug #477106 [11:27] Launchpad bug 477106 in linux (Ubuntu) "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware (affects: 76) (dups: 15) (heat: 526)" [Medium,Confirmed] https://launchpad.net/bugs/477106 [11:44] * pgraner yawns and blinks [11:47] morning pgraner [11:47] apw: sup man? [11:47] just chilling ... nothing speical [11:49] apw: Updated my primary desktop Maverick... and well I'm bleeding a bit, not called bleeding edge for nothing! [11:49] pgraner, you are mad :) [11:51] apw: not bad, other than I loose my mouse about once an hour and I have to reboot. X is working fine, keyboard, just the mouse locks up unplugging shows in demsg but X never picks it up again [11:51] apw: and evolution keeps crashing on startup [11:52] pgraner: switched back to evo? [11:52] mouse> interesting ... in lucid i am pretty sure i lose my mount and sometimes external keyboard but a USB unplug replug works there [11:53] mouse [11:53] pgraner, i actually use a VT switch to 1 and back to restore them too sometimes [12:02] apw: not here, I've even tried forcing a suspend/resume to see if that would shake it loose but nothing === smb-afk is now known as smb [12:31] apw, mcc thingy sounds similar, yeap [12:31] mmc even [12:31] smb sounds like lag has made some progess isolating it too [12:32] so perhaps you can palm it off on him :) [12:32] Oh he is always free to fix it. I can test if he has something. :) [12:33] Is there something in the scrollback (about what it could be)? [12:33] smb, apw: Okay, I'll crack on with it then [12:46] smb, he has identified a module that if you rmmod it on suspend and modprobe it on result it doesn't blammo <- about right lag ? [12:46] which probabally tells us which suspend/resume callbacks are broked [12:48] Hm, ok. I am not sure there is a rmmod in the case I looked at. But it might still be related. [12:49] It's not an rmmod per-say [12:50] You can tell PM to unload/reload modules on suspend/resume via a config file [12:50] i thought you added it to the pm-suspend list [12:50] right and that makes it rmmod on suspend and modprobe on resume [12:50] I did so and fixed the errors on my ThinkPad [12:50] Correct [12:50] right ... so its likely the suspend callback on that driver thats blowing chunks [12:51] I don't know the inner workings, but I would have thought so [12:51] as when the module is removed it does not blow chunks, which avoids that callback [12:51] or rmmoding adds another sync-wait point [12:51] Which is where my debug code is currently ;) [12:51] as the module is not there on suspend [12:51] smb, or indeed it may just slow down suspend enough [12:51] but i do suspect suspend based borkage [12:51] i suspect it panics [12:52] I'm in the middle of these theories currently - leave it with me :) [12:52] Chances for that are high. But I guess its in good hand with lag :) Just enlighten us when youre finished [12:53] yep [12:55] It doesn't look like it's even getting to the module's suspend function [12:55] It's dieing in the interrupt handler [12:56] * lag gets ready for a new debugging session :) [12:56] * lag smiles [12:57] Hi all. I'm having a permissions-related problem with qemu/kvm and I believe it is a kernel related issue (through process of elimination). I would really value insight from members of this group. [12:57] http://open.eucalyptus.com/forum/libvirt-operation-failed-failed-retrieve-chardev-info-qemu-info-chardev [12:58] Both apparmor and selinux are disabled with kernel boot parameters... yet for some reason, kvm cannot get permission to open a simple file for logging the console. [12:59] cybrocop, which file is it, what filesystem type is it on [12:59] apw: filesystem is ext4 [13:00] is that inside or outside the KVM instance? [13:00] Whenever I include this as part of libvirt.xml, kvm fails to start: http://slexy.org/raw/s20HiyArHA [13:01] libvirt is unable to create the "serial" device and thus kvm fails to start. [13:01] gah xml, now i remember why i work on the kernel [13:01] what does ls -l on that file say, and on the containing directory? [13:01] apw, ping? [13:01] hi [13:02] pgraner said I should ping you :) [13:02] imagine I have a USB stick which, when plugged in, says lots of "device not accepting address 13, error -71" in dmesg, and doesn't mount [13:02] cybrocop, what generates that fragment [13:02] apw: the file doesn't exist (wasn't able to be created). here is "ls -al" http://slexy.org/view/s2LWfnYhXw [13:02] (or get a device name or anything) [13:02] is there any way to get the data off it? [13:03] aquarius, well i would try it on a different machine, and on an older kernel to confirm its not s/w related, but generally i've foudn that behaviour to be 'bad' [13:03] apw, it's not s/w related; fails under Windows too (that's where it failed originally, so it was brought to an Ubuntu machine to see if that helped) [13:03] aquarius, that is assuming that at some point it has worked in the past of course [13:04] yeah, it used to work :) [13:04] apw: that fragment is part of the full libvirt.xml... Eucalyptus generates teh XML file and that is supposed to launch a VM instance. It contains the definitions for the VM instance, to be used by libvirt. Here is the full libvirt.xml http://slexy.org/raw/s2KPFinewG [13:04] I have given the owner a little lecture about not keeping your *only* copy of files on a usb stick. [13:04] aquarius, i would be suspicious it is sick at the h/w level then sadly ... as its refusing to take an address at the USB level [13:05] apw, so it's just broken and there's nothing that can be done about it? bah. That's what I thought, but I didn't know if there were Secret Things that could be done [13:05] i don't know of any way to talk to it if its really not having an address, thats kinda the first step [13:05] cking, know any magic to get a usb stick which is refusing addresses on both win and ubuntu to play ball? [13:06] cybrocop, ok the sensible debugging step would be to get an strace off the startup sequence to see what the open it tried did and said [13:06] apw: Basically libvirt/kvm tries to create that file in order to map it to the serial port for the VM instance. I suspect it cannot create the file and thus KVM errors out... [13:07] cybrocop, i have no idea whether you can get to it do do that or not, have you brought this up on #ubuntu-server, they are the ucalyptus experts [13:07] cybrocop, if not then we should move over there and get their input [13:08] apw: I have spent many hours on #eucalyptus and they have tried to debug this with me to no avail. #ubuntu-server didn't provide any insight. [13:08] well i see nothing in the directory settings which is unusual. if basic permissions didn't work on ext4 i think we would have noticed by now [13:09] cybrocop, so the next step is to get a trace off of the thing as it tries to start, normally i use strace for that -- strace -o /tmp/TRACE -f -e 'trace=open' [13:09] something like that [13:09] apw: The consensus (and I agree) is that Eucalyptus is not responsible for this as it tries to fire a KVM instance. Eucalyptus is eliminated as a culprit because I try to launch it manually using virsh and it fails. [13:09] apw: Thank a lot, I'll try that. [13:10] cybrocop, use the very simplest command you can to start it for sure [13:10] and then the output should be all files opened, looking for the open which is to that file [13:10] * lag 's new GIT book as arrived :D [13:10] $DEITY help us all [13:11] ;) [13:12] soon you'll be commiting by editing .git/objects/** directly [13:12] working trees are for chumps [13:13] * apw imagines doing the sha1's in his head [13:14] * lag is still confused, as he hasn't yet read the book and has no idea what they $PLACE_BAD_PEOPLE_GO you're on about! [13:14] the* [13:15] apw, no idea how to fix a misbehaving USB stick that looks dead [13:16] cking, yeah i think so too ... ouch [13:16] what does the kernel say when it's plugged in [13:16] apw: Here's the output.. http://slexy.org/raw/s2FmLeuYdM Is it possible that virsh is firing off another process which isn't monitored by strace? [13:18] cybrocop: the other process could be started by the libvirtd daemon [13:18] * jk- doesn't have much context [13:20] jk: can I attach strace to a running proc? [13:23] sure can, strace -p [13:23] cking, the kernel says lots of "device not accepting address 13, error -71" when the USB stick is plugged in [13:24] aquarius, tried the USB stick in a different machine just in case it's not the USB stick? [13:24] -EPROTO ? [13:26] cking, yep -- failed under windows in one machine, failed under ubuntu in another [13:26] sounds like broken H/W to me [13:26] you shouldnt use your usb keys as swap space ;) [13:27] cking, thanks :) [13:27] * manjo says N900 got a maemo 5 update, disable extra-devel extra-testing before you do an upgrade, or you might not have enough space on rootfs [13:27] manjo, bah, to late, already running [13:28] ogra, ota in the us was today [13:28] here too [13:28] :) you have some lead time on me [13:29] yeah, but only got around to click the button 1/2h ago [13:29] ogra, :) N900 won't get the meego update [13:29] i dont want meego [13:29] :) [13:30] this is probably the last update to maemo [13:30] * ogra is happy with maemo [13:30] jk / apw: it was indeed libvirtd that is starting it. Here is the command I used: strace -o /tmp/TRACE -f -e 'trace=open' -p 945 [13:30] * ogra wishes the new arm project would take over maemo :) [13:30] jk / apw: Then I ran this from another shell: http://slexy.org/view/s2jndz6OKP [13:31] * manjo wants andriod 2.2 on N900 [13:31] bah [13:31] * manjo want to dual boot [13:32] * ogra just wants ubuntu based maemo [13:32] jk / apw: Then I detailed by Ctrl-C. Here is the output of /tmp/TRACE http://slexy.org/raw/s2u2zWu5Ur [13:32] detailed -> detached [13:32] cybrocop: so libvirtd does not have access to console.log ? [13:33] cybrocop, right who is that daemon running as ? [13:33] No, which is very puzzling... [13:33] root 945 1 0 14:48 ? 00:00:00 /usr/sbin/libvirtd -d [13:34] does it drop privs at any point [13:34] ? [13:34] need to know its real ids [13:34] It should (according to the advertisement) drop privs to libvirt-qemu:libvirtd [13:34] root@srv-uec-qa-node02:~# grep libvirt /etc/passwd /etc/group [13:35] strace -e trace=open,setuid,seteuid [...] [13:35] jk: let me try with those options. [13:35] cybrocop, you can tell from /proc [13:36] apw: provided he can catch the spawned process in time :) [13:36] apw: can you be more specific? Does it contain a history of setuid/setgid? [13:36] jk: correct, the spawned process dies quickly. [13:37] cat /proc/945/status and grep for Uid and Gid [13:38] jk its possible it has d already [13:38] jk it is possible that it has dropped them already [13:38] cybrocop, if the docs are right then the permissions it runs them as doesn't have open right in there does it? [13:38] root@srv-uec-qa-node02:~# cat /proc/945/status |grep -i -e "uid" -e "gid" [13:38] Tgid: 945 [13:38] Uid: 0 0 0 0 [13:38] Gid: 0 0 0 0 [13:39] ok, so console.log (and the parent directories) need to be accessible by that user [13:39] yeah unless libvirt-qemu is in eucalyptus group then its not going to work is it\? [13:39] so check if its a member of that, if not then the permissions checks are working as expected [13:39] jk / apw: I am running the command as root [13:40] and something is owned by the wrong person [13:40] cybrocop, but the docs tell you it demotese self to libvirtsomething didn't you just say [13:40] jk: "that user" uid=0 ? [13:40] cybrocop: it doesn't matter who is running the command [13:40] "that user" = the user that libvirtd is setuid-ing to [13:41] and the docs you just pasted told us who it was [13:42] jk /awo: this is from /etc/group - libvirtd:x:114:olm,eucalyptus [13:42] thats not the user you pasted above though [13:42] libvirtd-qemu you said [13:43] It should (according to the advertisement) drop privs to libvirt-qemu:libvirtd [13:44] apw: Let me do an strace and get the exact user. Sorry for the confusion. I thought i may be libvirtd-qemu, but I have to admit it is not from docs, just my memory. [13:44] cybrocop, ok [13:46] jk: hmm... what am I doing wrong here [13:46] jk: root@srv-uec-qa-node02:~# strace -o /tmp/TRACE -f -e 'trace=open,setuid,seteuid' -p 945 [13:46] strace: invalid system call `seteuid' [13:47] my bad, remove seteuid [13:47] jk: ok [13:49] jk / apw: I don't see any setuid http://slexy.org/raw/s21B2A4Dlo [13:50] furthermore, I remember, that when I set the path of the file to be /tmp/console.log (in libvirt.xml) the owner of the file was root [13:50] does anyone have a touch screen running in lucid? [13:50] sokeman, yes [13:51] i think i know how you did it but i have a proble, [13:51] problem* [13:51] cybrocop, does chacl -l say anything on any of the paths ? [13:52]