| enseven | Hi all! I am trying to hotplug USB disks automatically to a KVM virtual machine. What I found is: I get a lot of trouble, when a USB disk has been attached to the VM, because it is not accessable from the hypervisor any more. What I see is, that it is added to the SCSI subsystem "lsscsi" and that tries continuously to access it generating error messages in "dmesg" and "syslog". One solution I found is: Prevent the loading of the "us | 09:21 |
|---|---|---|
| enseven | b_storage" module on the hypervisor. But that's not the way I'd like to handle it, because this prevents the use of USB disks in general. Is there a way to prevent the kernel from adding particular USB disks (recognized by VendorID and ProductID) to the SCSI subsystem? Where can I find some documentation about these mechanisms? | 09:21 |
| enseven | Thanks & best regards! :-) | 09:21 |
| apw | NikTh, ok your build issue there is you have added new components via your patches | 09:48 |
| NikTh | Yes apw | 09:48 |
| apw | and not updated the configuration with the new options | 09:48 |
| apw | run this and answer the questions, and commit the result: fakeroot debian/rules updateconfigs | 09:48 |
| NikTh | I have running make xconfig and saved the .config .. what else I must do after this ? | 09:48 |
| NikTh | apw: The command gave an error. See : http://pastebin.com/gKFSizE9 | 09:53 |
| apw | NikTh, you must run: fakeroot debian/rules updateconfigs | 09:53 |
| apw | NikTh, ahh you are using the .dsc package not the git repo | 09:57 |
| apw | NikTh, you need to chmod +x debian/scripts/misc/* | 09:57 |
| ogra_ | apw, bug 1182829 ... | 10:04 |
| ubot2 | Launchpad bug 1182829 in initramfs-tools (Ubuntu) "initramfs-tools should allow building module-less generic initrds" [Undecided,New] https://launchpad.net/bugs/1182829 | 10:04 |
| NikTh | apw: http://pastebin.com/kc6tEjms (the overrides messages are too many, I did't copy-paste them all, if you need them all tell me). Now I have not a debian/rules file at all.. LoL | 10:06 |
| NikTh | Is so F...ing difficult to build a custom-kernel onsite (Launchpad) and so easy to build it locally.. dmn :P | 10:06 |
| apw | you can ignore the overrides issues | 10:07 |
| apw | you need to make config-check executable it seems, chmod +x debian/scripts/* debian/scripts/misc/* | 10:07 |
| apw | it is much easier to use the git tree than a source tarball, as that is how we do all of ours | 10:08 |
| apw | and threfore any wrinkles like this are covered off | 10:08 |
| apw | making a local kernel just for oneself is easy indeed, doing it 'right' so that the archive can grok it is always going to be much harder | 10:09 |
| apw | NikTh, remember the source pacakge you are producing produces binaries for all supported architectures, not just the local one as you get when you do a local build | 10:10 |
| apw | it is a much more complex animal than just a build | 10:10 |
| NikTh | I have no debian folder at all right now. Only debian.master.. I thing it purged out (rm -rf ) . Any documentation for git ? or just git clone <tree> and then the same procedure ? | 10:11 |
| smb | NikTh, Have you seen this? https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel | 10:15 |
| NikTh | Well, you know what? I will try one more time with tarball , because so many times I have done this procedure I remember it without read anything.. LoL. When I get to the point of chmod +x .... I will update here. | 10:15 |
| NikTh | smb: Thanks. Really I don't remember , probably not. I have read so much these 2-3 days that my mind blown. | 10:19 |
| apw | the kernel is one of the more esoteric packages in the archive, it has to produce so much junk to let us make bootable CDs and the like | 10:23 |
| NikTh | Ok, to be sure I ran the command twice. The first time it did the checks with questions, the second did the checks without questions. Which means that the update was done properly (if I'm not mistaken) | 10:36 |
| NikTh | I'm speaking about fakeroot debian/rules updateconfigs | 10:37 |
| NikTh | I didn | 10:37 |
| NikTh | I didn | 10:37 |
| NikTh | I did not run fakeroot debian/rules editconfigs (I prefer the graphical make xconfig instead) . No problem with that.. (?) | 10:38 |
| smb | Many problems with that. Main one being that this creates .config in the top level dir which is not used at all by the debian build | 10:39 |
| NikTh | smb: So I must first run fakeroot debian/rules editconfigs and then fakeroot debian/rules updateconfigs ? | 10:41 |
| smb | NikTh, With a new option that has no default, no. It will (or should) just ask you how to set things when running updateconfigs | 10:42 |
| NikTh | Ok. I did that. I answered Yes to questions. | 10:42 |
| smb | If you want to change things from current values you had to either run editconfigs or edit the files in debian.master/config | 10:42 |
| NikTh | It seems to work now.. I will cross my hands for Launchpad Builder.. We will see.. :P | 10:43 |
| smb | So it should be ok but just make xconfig is unneeded the least | 10:43 |
| smb | Rule of thumb with debian packages: calling anyting with make directly is bound to be wrong | 10:44 |
| NikTh | Last question smb : If I want to change something in current configuration (eg: Processor Type and features to point to AMD or Intel ) which command is better ? make xconfig or fakeroot debian/rules editconfigs | 10:45 |
| smb | NikTh, Isn't the answer to that obvious from what was said above? ;) | 10:46 |
| NikTh | I guess the second , but don't ask me why. Locally always I used make xconfig to change the configuration.. | 10:46 |
| NikTh | Yes it is obvious. | 10:46 |
| smb | The thing is whether you just use the kernel make infrastructure or the debian packaging | 10:47 |
| smb | when you run fakeroot debian/rules it will always use what is in debian.master/config to create new config files per flavour in debian/build/... | 10:48 |
| smb | Whatever "make xconfig" has done to .config is ignored | 10:48 |
| NikTh | per flavor . Yes, I think that's the secret key here. It would be better for a newbie (like me) to learn ONE procedure either locally or onsite to build a custom kernel.. but differences are small as I can see.. small but important | 10:50 |
| NikTh | Well, thanks for all the help guys.. I'm not here to learn , I don't ask for a teacher , I must read more docs I guess and make more mistakes to learn actually. We'll see how it goes. | 10:53 |
| smb | For that I would point back to the BuildYourOwnKernel wiki. This is the documentation we can control. Unfortunately there is plenty of instructions we cannot. | 10:54 |
| apw | amen to that | 11:21 |
| * henrix -> lunch | 12:10 | |
| marvin24 | rtg_: yesterday you said: "marvin24, I does not appear that you can enable CONFIG_TEGRA with trashing CONFIG_ARCH_MULTIPLATFORM" | 12:10 |
| marvin24 | do you mean that some config options get also changed | 12:11 |
| rtg_ | marvin24, based on some quick testing, CINFIG_TEGRA is mutually exclusive with MULTIPLATFORM | 12:11 |
| marvin24 | I enabled it on the Ubuntu-3.10.0-0.1 branch and it worked without problems | 12:12 |
| rtg_ | I'll look into it a bit more today. if tegra can be enabled in the multiplatform kernel, then we should | 12:13 |
| marvin24 | only minimal changes to the config | 12:13 |
| marvin24 | I don't know if nr_gpios is important though ... | 12:13 |
| rtg_ | marvin24, cool, send a patch to the k-team list. | 12:13 |
| marvin24 | ok | 12:14 |
| rtg_ | I'm pretty sure I only tried it on 3.9 | 12:14 |
| marvin24 | ah, multiplatfrom was only enabled in 3.10 | 12:14 |
| marvin24 | (I mean for tegra) | 12:14 |
| rtg_ | marvin24, I'll switch saucy over to 3.10 around rc3 or 4. its still a bit steamy... | 12:20 |
| marvin24 | rtg_: np, there is still plenty of time ... I also need to test 3.10 on my ac100 first | 12:21 |
| marvin24 | but it would be great if I could boot the default ubuntu kernel on it | 12:21 |
| rtg_ | biab | 12:29 |
| enseven | I got the solution: If you attach the USB disk by udev to the VM, it is done so quickly that the SCSI subsystem cannot catch it. The problem only occurs if you attach it manually, when the SCSI subsystem has already caught it. | 12:44 |
| * ppisati goes out to run an errand, brb | 12:44 | |
| * henrix -> back in 15 | 13:35 | |
| NikTh | waiting | 13:42 |
| apw | NikTh, waiting for what ? | 14:03 |
| NikTh | apw: nothing. This message was a mistake of mine when I tested some commands on IRC (on another channel). It seems that /AMSG sends the message to all channels. LoL | 14:23 |
| NikTh | apw: Actually I'm waiting for building the binary packages on Launchpad. :-) | 14:24 |
| sconklin | apw: I see some weirdness in the CVE tracker status changes this morning. CVEs have switched the pending version from the kernels in -proposed, to one which was already released. | 14:26 |
| apw | from and to ? | 14:26 |
| apw | are they from the new -22 to the old -20 ... or whatever, from the version which is pending now to the one which didn't make it out ? | 14:27 |
| apw | sconklin, ^^ | 14:27 |
| sconklin | CVE-2013-3076: | 14:27 |
| sconklin | -raring_linux: pending (3.8.0-22.33) | 14:27 |
| sconklin | +raring_linux: pending (3.8.0-20.31) | 14:27 |
| apw | so how did the -22 get in there i wonder | 14:28 |
| sconklin | yes | 14:28 |
| sconklin | -22 is in proposed now | 14:28 |
| apw | i am trying to understand how the autotirager would ever have said -22 | 14:28 |
| apw | the issue is that the first release they are in _is_ -20, just it didn't release | 14:29 |
| apw | so i would have epxected it to make that error always, so wondering why it | 14:29 |
| apw | went to -22 first, then changed its mind, that seems wron | 14:29 |
| apw | odd | 14:29 |
| sconklin | agree | 14:29 |
| apw | anyhow ... so the issue here is we have a tag for 3.8.0-20.31 which the autotriager sees, which is actually not really a valid tag | 14:31 |
| apw | sconklin, i am going to have a think about it, as really we should only consider the version which have been in the -release/-updates pocket, not all tags | 14:31 |
| apw | sconklin, don't accept its changes fro the moment, they are clearly balls | 14:32 |
| sconklin | apw: ok, I won't push this back up | 14:32 |
| sconklin | This is why we have a human in the loop | 14:32 |
| apw | sconklin, thanks ... i will prolly just hack it so we can exclude tags to start with, but we ought to get launchpads idea of them | 14:32 |
| apw | sconklin, so very very true | 14:32 |
| henrix | sconklin: its probably due to some manual fixes jj has done for the emergency kernel | 14:35 |
| apw | henrix, yeah that all makes sense, i'll do something to the tool to make it do the right thing; so it doesn't undo his bits | 14:48 |
| henrix | apw: ack, thanks. sconklin ^^ | 14:49 |
| apw | sconklin, which releases did this happen on ? | 14:57 |
| apw | sconklin, i thought we wern't going to commit these changes? it seems we have, at least when i pull i get the -20 version | 14:59 |
| rsalveti | <sergiusens> rsalveti: ok, manta is now using the saucy ubuntu kernel (after a repo sync ;-) ) | 15:16 |
| rsalveti | apw: rtg_: ^ | 15:16 |
| apw | rsalveti, nice | 15:16 |
| rtg_ | rsalveti, thats pretty funny. I _just_ sent an email about kernel status. | 15:17 |
| rsalveti | so mako + manta should be using the ubuntu kernel starting next build | 15:17 |
| rtg_ | rsalveti, grouper too, right ? | 15:17 |
| rsalveti | rtg_: I'll test maguro later today, but grouper is not yet in a good shape | 15:17 |
| rtg_ | ah | 15:17 |
| rsalveti | it's booting and working with the ubuntu kernel now | 15:18 |
| rsalveti | but it seems I cannot open apps with it | 15:18 |
| rsalveti | and I don't have the hardware anymore, so would need help from the kernel team | 15:18 |
| rsalveti | might be a config issue still | 15:18 |
| rsalveti | probably related with binder | 15:18 |
| rtg_ | rsalveti, I have an N7 | 15:18 |
| rsalveti | rtg_: mind flashing our latest N7 image and then updating to our kernel? | 15:19 |
| rtg_ | rsalveti, yeah, was just gonna do that | 15:19 |
| rtg_ | saucy, right ? | 15:19 |
| rsalveti | rtg_: first give it a shot with the default kernel from our image, see if the shell is working as expected (opening apps properly and such) | 15:19 |
| rsalveti | rtg_: yes | 15:19 |
| rtg_ | ack | 15:20 |
| rsalveti | abootimg -u /dev/block/platform/sdhci-tegra.3/by-name/LNX -k <vmlinuz> | 15:20 |
| rsalveti | you probably know already, but just in case | 15:21 |
| rtg_ | rsalveti, I didn't, so thatnks. that save me some time | 15:21 |
| rtg_ | mmm, may have to wait for battery charge | 15:22 |
| apw | rsalveti, can you get the old one off the saem way, so you can put it back ? | 15:39 |
| rsalveti | apw: yup, but you'd need to extract the boot.img file | 15:39 |
| rsalveti | with abootimg itself | 15:40 |
| apw | rsalveti, well i would be happy with 'give me blob i can give you back' for when i brick it again | 15:40 |
| rsalveti | right, but the easier way to restore a broken kernel is by flashing the boot.img via fastboot | 15:41 |
| apw | ahh | 15:41 |
| rsalveti | http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/20130522/raring-preinstalled-boot-armel+grouper.img | 15:41 |
| rsalveti | for example | 15:41 |
| rsalveti | boot into fastboot | 15:41 |
| rsalveti | fastboot flash boot raring-preinstalled-boot-armel+grouper.img | 15:41 |
| rsalveti | apw: rtg_: it seems there's a crash when opening the camera app with manta | 15:49 |
| rsalveti | it reboots right after opening the app (which starts the camera hal) | 15:49 |
| rtg_ | rsalveti, we should be able to start opening bugs in LP against these kernels. | 15:50 |
| rsalveti | yeah | 15:50 |
| rsalveti | need to dig a bit further, not sure if the kernel is actually the culprit here | 15:50 |
| rtg_ | apw, how about something like linux-generic-lts-raring-to-14-04 | 16:04 |
| apw | rtg_, heh other than the nasty mixture of raring and 1404 | 16:06 |
| apw | especially if it was 14.05 or something which is 'slightly' possible | 16:07 |
| apw | lts-generic-lts-raring-upgrade | 16:07 |
| rtg_ | apw, ok, how about linux-generic-lts-raring-to-the -next-lts | 16:08 |
| apw | lts-generic-lts-raring-autoupgrade | 16:08 |
| apw | they are alll so very long and not ver obvious | 16:08 |
| apw | very | 16:08 |
| rtg_ | autoupgrade isn't very specific | 16:08 |
| apw | nope, no better indeed | 16:08 |
| apw | what does it mean ... we want ... -upgrade-at-end-of-support | 16:09 |
| rtg_ | but actually, its not that bad either. | 16:09 |
| apw | which is hard to fit in a short word | 16:09 |
| apw | -eol-upgrade | 16:10 |
| rtg_ | apw, autoupgrade is kind of growing on me. eol-upgrade isn't too bad either | 16:10 |
| apw | we need X to do the same of course | 16:10 |
| rtg_ | apw, not my problem :) | 16:10 |
| apw | yeah :) | 16:11 |
| rtg_ | though it would be nice if they used the same scheme | 16:11 |
| arges | smb: hello | 17:01 |
| smb | arges, Hey, just was wondering | 17:01 |
| * rtg_ always wonders when arges shows up | 17:02 | |
| arges | don't worry... no bad news | 17:02 |
| * rtg_ -> work | 17:39 | |
| * rtg_ just received an 8 bay RAID cabinet. | 18:15 | |
| marvin24 | rtg_: so you can use the saved time to answer questions ... | 18:15 |
| marvin24 | do you see __bad_udelay during kernel compile? | 18:15 |
| rtg_ | marvin24, on 3.10-rc2 ? | 18:16 |
| marvin24 | nsp32.c and nouveau use udelays > 2000, which fails on tegra | 18:16 |
| marvin24 | rtg_: yes | 18:16 |
| rtg_ | marI haven't compiled for armhf yet | 18:16 |
| rtg_ | marvin24, ^^ | 18:17 |
| marvin24 | it should be the same for all arm socs | 18:17 |
| marvin24 | I think I've seen this in 3.8 also | 18:17 |
| rtg_ | I've been distracted by Ubuntu touch kernels | 18:17 |
| marvin24 | at least I disabled these drivers because of this | 18:17 |
| marvin24 | rtg_: yes, ancient versions ... | 18:17 |
| marvin24 | I'm happy not to deal with 3.1 kernels anymore | 18:18 |
| kees | ogasawara: say, how receptive would you be to taking an ARM-only patch to enable seccomp-bpf on precise? The changes are relatively minor (since it just calls into the existing seccomp-bpf infrastructure that was put in place for x86) | 19:00 |
| ogasawara | kees: I don't think I'm personally opposed, send it on over. bjf, rtg_: ^^ thoughts? | 19:01 |
| bjf | kees, ogasawara first thought is I don't see any issue | 19:02 |
| rtg_ | no patch, no opinion | 19:03 |
| kees | heh, fair enough. I'll spin it up so you guys can look at it. thanks! | 19:03 |
| * rtg_ -> EOD | 19:49 | |
| rsalveti | apw: just sent 2 config-related patches to make the camera to work with nexus 10 | 20:59 |
| rsalveti | seems that is the only remaining regression with this kernel | 20:59 |
| rsalveti | going to test maguro now | 20:59 |
| apw | rsalveti, ack thanks | 20:59 |
| rsalveti | the second one is just to enable /proc/net/wireless, requested by the sdk folks | 20:59 |
| === kentb is now known as kentb-out | ||
| NikTh | Here I am again. You will never get rid of me :P | 22:28 |
| NikTh | New build error. As I guess I must add something in debian/rules, but what ? | 22:29 |
| NikTh | Error here: https://launchpadlibrarian.net/140487585/buildlog_ubuntu-raring-amd64.linux_3.8.0-21.32ubuntu1~bfsbfq0_FAILEDTOBUILD.txt.gz | 22:29 |
| NikTh | Ohhh ! Boing ! This was an old message (e-mail) . Now I saw the package version. It seems that we had a delay in delivering. Sorry !! Ignore all above. At Launchpad page (my PPA) seems that is currently building (still) | 22:34 |
| NikTh | But no. As I refreshed the Launchpad page says "1 failed , 1 pending to build" . So I guess that is the report is correct. Dmn ! Forgive me, because this is the 5th failure and I'm little bit confused. Anyone who knows why build failed ? | 22:37 |
| === ssweeny` is now known as ssweeny | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!