| maco | kirkland: hey can you take a look at bug 317895? | 00:23 |
|---|---|---|
| ubottu | Launchpad bug 317895 in ecryptfs-utils "netboot newuser and ecryptfs fails to login" [High,Triaged] https://launchpad.net/bugs/317895 | 00:23 |
| sabdfl | cjwatson: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ makes good installer fodder? | 00:45 |
| ScottK | If there's an archive admin available, the kde4.2 backport is once again hung up on binary New. I'd appreciate it if you would accept kde4bindings from Intrepid New. It's got mixed Main/Universe binaries so I can't do it from the LP U/I. | 01:13 |
| directhex | kde 4.2 backport? sounds like a big job | 01:15 |
| ScottK | It is. sigh. | 01:17 |
| directhex | i didn't think major infrastructure was even eligible for backporting | 01:17 |
| ScottK | It's several dozen packages that mostly have to get built in a certain order and several of which get stuck in New because they grew new binaries in Jaunty. | 01:18 |
| ScottK | Kubuntu has historically had a more generous policy about post release updating. | 01:18 |
| directhex | fair enough | 01:18 |
| ScottK | Also because KDE4 is such a rapibly moving target .... | 01:18 |
| directhex | anyway, good luck with the backport. i think it's time for sleepybyes | 01:18 |
| ScottK | directhex: JFTR if I'd dropped all the CIL bindings for the backport I'd have avoided a trip through New, but I didn't. | 01:20 |
| Hobbsee | ScottK: waved thru | 01:21 |
| ScottK | THanks. | 01:21 |
| directhex | ScottK, see, that wasn't as bad as all that, was it? | 01:22 |
| * directhex hands Hobbsee a fiver | 01:22 | |
| Hobbsee | directhex: \o/ | 01:25 |
| directhex | hmm... sounds like rhythmbox development is winding up | 01:29 |
| directhex | i wonder what that'll mean for ubuntu desktops | 01:29 |
| Hobbsee | would help if the power didn't trip out, too... | 01:33 |
| Hobbsee | OK, that's actually accepted this time | 01:33 |
| ScottK | Thanks. | 01:35 |
| === freeflyi1g is now known as freeflying | ||
| dtchen | hunger_t: yes, currently at least bug 332270 | 04:32 |
| ubottu | Launchpad bug 332270 in udev "[jaunty] doesn't boot anymore after udev upgrade" [Critical,Incomplete] https://launchpad.net/bugs/332270 | 04:32 |
| pwnguin | oh neat | 04:39 |
| pwnguin | for some reason update-manager is blocking on a etc file in the embedded VT | 04:40 |
| MrMacPlus | any chance of getting the PC-BSD package manager ported to Ubuntu? | 04:51 |
| MrMacPlus | (it doesn't require internet) | 04:51 |
| MrMacPlus | the only machines I have don't have an internet connection | 04:52 |
| MrMacPlus | nevermind | 04:54 |
| maco | kirkland: i *think* that patch is doing the right thing. when the user's not logged in, their ~ is 755 with visible filenames (as in release notes) but all files appear empty (even to root). when the user is logged in, ~ becomes 700 and root can see into the files (which makes sense to me, since the fs is mounted). i just want to check with you that this is the correct behavior for fixing that bug. | 05:58 |
| cjwatson | sabdfl: yeah, there was somebody on ubuntu-devel-discuss (I think?) a little while back who was interested in working on that | 09:22 |
| sabdfl | cjwatson: would that logic best be encoded in the d-i partitioner | 09:23 |
| sabdfl | ? | 09:23 |
| cjwatson | sabdfl: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-January/006760.html | 09:24 |
| cjwatson | sabdfl: and followup, where I provide some suggestions | 09:24 |
| sabdfl | thanks colin | 09:24 |
| cjwatson | libparted is a good common place to put this kind of thing - d-i would just need to flip the switch, ideally. However from the look of tytso's blog it does seem that we'd have to pass some extra arguments to mkfs.ext4 and such | 09:25 |
| cjwatson | but we could stash that information in /var/lib/partman if libparted were doing the work of fishing it out from the kernel | 09:26 |
| sabdfl | yes, it looks like there needs to be a level of intelligence in a variety of the tools | 09:26 |
| sabdfl | did daniel respond to your question about whether he's willing to do the work? we could connect him to ted tso | 09:26 |
| cjwatson | sabdfl: haha, and in my work mailbox this morning there's a followup from Daniel J Blueman on parted-devel about this exact subject ;-) | 09:26 |
| sabdfl | including a ref to ted's blog? | 09:27 |
| cjwatson | no, but it would fail to surprise me if he were prompted by the same thing | 09:29 |
| cjwatson | the coincidence is a bit much | 09:29 |
| cjwatson | I'll keep the link and nudge things alon | 09:29 |
| cjwatson | g | 09:29 |
| cjwatson | sabdfl: I've mentioned Ted's blog on parted-devel | 09:35 |
| cjwatson | sabdfl: the bit about alignment of the first partition is interesting, given that we haven't historically created a /boot | 09:35 |
| cjwatson | (well, not by default anyway) | 09:35 |
| sabdfl | he's encoded a *lot* of "wisdom and best practice" into that blog | 09:36 |
| cjwatson | I wonder whether the right answer is to create a /boot on SSDs, or whether it's to say screw MS-DOS compatibility and hope that not too many partitioning programs will whine at us if we 128KB-align the first partition | 09:37 |
| sabdfl | can we detect SSD's? and worse, can we determine things like which type of SSD it is? | 09:37 |
| cjwatson | we can detect SSDs with ATA IDENTIFY. I don't know about which type | 09:37 |
| cjwatson | Daniel says: """ | 09:38 |
| cjwatson | I've checked into this, and since libparted sees the SATA block device | 09:38 |
| cjwatson | as SCSI, it doesn't perform the expected ATA 'identify' command to | 09:38 |
| cjwatson | fill out the 512 bytes of device info, of which (short) word 217 is | 09:38 |
| cjwatson | device RPM, defined to be 1 on newer compliant SSDs. The kernel uses | 09:38 |
| cjwatson | this word to detect if a device is an SSD or not, so I suggest we use | 09:38 |
| cjwatson | the same. | 09:38 |
| cjwatson | """ | 09:38 |
| cjwatson | that much is pretty trivial | 09:38 |
| sabdfl | assuming we fix the libparted-sees-scsi bit | 09:39 |
| === hunger_t is now known as hunger | ||
| ogra | cjwatson, do we have a way to enforce that users create swap in partman ? (would be handy to not make nslu2 users shoot themselves in the foot, though i can just document that you need it indeed) | 12:14 |
| === kyselejsyrecek1 is now known as kyselejsyrecek | ||
| LordMetroid | I just installed 8.10 and now 9.04 is soon to be released, I can't keep up with this high pace... | 12:58 |
| LordMetroid | How can I get insight in what is being developed for each release? | 12:59 |
| hunger | LordMetroid: CHeck launchpad:-) | 13:03 |
| LordMetroid | I am hanging around on Launchpad, I even contributed some bug reports | 13:03 |
| LordMetroid | But how do I know what people are working on? | 13:04 |
| hunger | LordMetroid: https://launchpad.net/ubuntu/intrepid/ is the "homepage" for intrepid. The most interesting section there wrt. planning is "Blueprints". | 13:04 |
| hunger | You might want to replace intrepid with jaunty... Not that much planning is happening in intrepid nowadays:-) | 13:05 |
| LordMetroid | karmic has no section of its own? | 13:10 |
| StevenK | LordMetroid: Not yet, no. | 13:40 |
| geser | a quick question: why is python3-minimal an essential package? | 13:41 |
| directhex | because ubuntu wuvs python? | 13:42 |
| highvoltage | geser: are you wondering more about the '3' part or more about the 'python' part? | 13:42 |
| geser | yes | 13:42 |
| geser | the 3 | 13:43 |
| geser | python3 is still in universe and iirc doko waits on python 3.1 | 13:43 |
| highvoltage | yeah that is a bit weird | 13:43 |
| directhex | any rdeps? | 13:44 |
| geser | I just wondered why my jaunty pbuilder install python3-minimal just to find out it's because it's essential | 13:44 |
| doko | geser: it's a bug and should be fixed | 14:01 |
| Keybuk | mdeslaur: so you're getting this udev bug too? | 16:11 |
| mdeslaur | Keybuk: yes...not fun | 16:11 |
| Keybuk | have you worked around it yet, or can I pick on you for some debugging? | 16:12 |
| Keybuk | it seems to be uniquely affecting people who use some magic combination of lvm, devmapper or mdadm | 16:13 |
| mdeslaur | Keybuk: well, I commented out the watch line, but I booted on an old kernel, so I can simply add it back in | 16:13 |
| Keybuk | mdeslaur: do you have some time to do that now? | 16:13 |
| Keybuk | or Monday (since today is Sunday and you might be busy :p) | 16:13 |
| mdeslaur | problem is, I had a hell of a time getting my laptop to boot so I could make the change | 16:13 |
| mdeslaur | yes, let me just save my work | 16:13 |
| mdeslaur | Keybuk: what would you like me to do? | 16:14 |
| Keybuk | I'd like to find out what's causing these inotify events | 16:14 |
| Keybuk | so firstly need to get booted up, so we can find out which block devices they're happening for | 16:15 |
| Keybuk | ie. run udevadm monitor | 16:15 |
| mdeslaur | Keybuk: I can't successfully boot _with_ the problem | 16:16 |
| mdeslaur | Keybuk: the best I can do is add the watch line back in, but boot with the 2.6.28-7 kernel | 16:17 |
| mdeslaur | is that ok? | 16:17 |
| Keybuk | does the kernel make a difference? | 16:18 |
| geser | Keybuk: I'm affected by the bug too (I downgraded udev in the end). I didn't get near a shell with the bugged udev (perhaps I didn't wait long enough) to be able to test something. | 16:18 |
| mdeslaur | Keybuk: I think it's juste because the old kernel has an old initrd | 16:19 |
| Keybuk | oh, hmm | 16:19 |
| Keybuk | ok, let's just debug this from the other angle then | 16:19 |
| Keybuk | can you remember which filesystems you saw inotify events for? | 16:19 |
| Keybuk | geser: likewise? | 16:20 |
| mdeslaur | Keybuk: I think it was my home directory.../dev/mapper/defaultvg-home on /home | 16:20 |
| mdeslaur | Keybuk: but I'm not 100% sure | 16:20 |
| Keybuk | is there anything special about that drive, other than using LVM? | 16:21 |
| Keybuk | is it encrypted? | 16:21 |
| Keybuk | do you use encrypted drives or swap? | 16:21 |
| mdeslaur | Keybuk: I use encrypted swap, and have an ecryptfs ~/Private directory | 16:21 |
| Keybuk | geser: what about you? | 16:22 |
| geser | I use just simple raid + lvm for / and /home | 16:22 |
| Keybuk | geser: lvm-on-md-on-sda? | 16:23 |
| mdeslaur | Keybuk: I use LUKS for my encrypted swap | 16:23 |
| geser | yes, raid1 on sda+sdb and lvm on that raid | 16:23 |
| Keybuk | interesting | 16:24 |
| Keybuk | mdeslaur: so you use md at all? | 16:24 |
| mdeslaur | Keybuk: nope | 16:24 |
| Keybuk | mdeslaur: but you do use lvm? | 16:24 |
| mdeslaur | Keybuk: yes | 16:24 |
| Keybuk | mdeslaur: cryptswap is done all inside the kernel, right? | 16:25 |
| Keybuk | there's no userspace helper that writes to the block device? | 16:25 |
| mdeslaur | Keybuk: yeah, I'm pretty sure it's kernel | 16:26 |
| Keybuk | geser: do you see inotify events for both underlying disks/ | 16:26 |
| mdeslaur | Keybuk: of course, I get prompted for a password during boot up for my encrypted swap | 16:27 |
| mdeslaur | Keybuk: It's during usplash, from initr | 16:27 |
| mdeslaur | initrd | 16:27 |
| Keybuk | the confusing thing is that none of this is supposed to generate inotify events | 16:28 |
| Keybuk | certainly not the IN_CLOSE_WRITE event that udev actually looks for | 16:29 |
| geser | Keybuk: I could upgrade udev again and check. | 16:30 |
| Keybuk | geser: you should be able to upgrade in-situ without rebooting | 16:30 |
| Keybuk | and then trigger it | 16:31 |
| geser | even better | 16:31 |
| geser | Keybuk: I've started udevadm monitor and restarted udev and no output from udevadm | 16:34 |
| Keybuk | ok | 16:34 |
| Keybuk | run udevadm trigger --subsystem-match=block | 16:34 |
| mdeslaur | Keybuk: I've done the same | 16:34 |
| Keybuk | (have a very niced root terminal somewhere :p) | 16:35 |
| mdeslaur | Keybuk: whoa, I'm getting a TON of events | 16:35 |
| Keybuk | mdeslaur: are they repeating? | 16:35 |
| mdeslaur | Keybuk: yes | 16:36 |
| Keybuk | if so, kill udevd from the other terminal and pastebin me the output ;) | 16:36 |
| geser | Keybuk: http://paste.ubuntu.com/121466/ (it didn't stop) | 16:36 |
| mdeslaur | Keybuk: https://pastebin.canonical.com/14086/ | 16:37 |
| Keybuk | geser: kill udevd harder | 16:37 |
| mdeslaur | Keybuk: I didn't get the beginning | 16:38 |
| geser | Keybuk: that was before I killed udevd | 16:38 |
| Keybuk | both of you: can you run "find /sys/block" for me and pastebin that | 16:38 |
| mdeslaur | Keybuk: http://paste.ubuntu.com/121467/ | 16:39 |
| geser | http://paste.ubuntu.com/121468/ | 16:39 |
| IntuitiveNipple | Keybuk: Some info: If running with udev_log=debug (and a serial console) the problem isn't nearly as bad, although there are a huge number of "vol_id..." invocations early in the initrd - before netconsole gets going. Without either "debug" or "info" log-levels, the disk will just thrash constantly and not reach a prompt for a very long time (hour?). This is with just a single LVM volume, not even mounted via fstab. | 16:47 |
| IntuitiveNipple | Keybuk: If you want to ssh in to observe/interact, I can do that | 16:48 |
| Keybuk | my guess is that mdadm and lvm (and probably just devmapper) are generating open/close events in the kernel | 16:53 |
| IntuitiveNipple | It is very weird how with logging on, the timing difference allows the system to boot. Also very frustrating, because it is making it almost impossible to catch the activity! | 16:54 |
| Keybuk | the timing difference is just because udevd is much slower | 16:54 |
| Keybuk | you could replicate the same by adding a rule like | 16:54 |
| Keybuk | SUBSYSTEM=="block", RUN+="/bin/sleep 5" | 16:54 |
| IntuitiveNipple | yeah, but my point is, the timing delay is preventing the problem... the disk doesn't thrash like it does when the system's being hit | 16:55 |
| Keybuk | is it preventing it? or just slowing it? | 16:55 |
| geser | Keybuk: you need more testing? else I'd downgrade udev again so I can boot tomorrow | 16:56 |
| Keybuk | a continuous loop of events is bad whatever | 16:56 |
| Keybuk | geser: I think I have enough information to try and put together a test install | 16:56 |
| Keybuk | if I still can't replicate it, I'll come back to you | 16:56 |
| IntuitiveNipple | With logging enabled, I can get to the root prompt in about 80 seconds. Without it the disk thrashes with no screen reports for a _long_ time... longest I left it was 30 minutes | 16:56 |
| IntuitiveNipple | Keybuk: I found as soon as I added lvm2 to the intrd it fired it off - remove lvm2 from initrd and it's fine | 16:57 |
| Keybuk | sure, that's just the symptom though | 16:57 |
| Keybuk | the real problem is udev picking up events that seem to cause other events | 16:57 |
| Keybuk | it'd be interesting to find out whether it's caused by a udev event | 16:57 |
| Keybuk | or whether the kernel simply generates events over and over again anyway | 16:57 |
| IntuitiveNipple | I have a log here now (captured via screen from the serial console). I *think* it might be useful but I'm trawling through it to check | 16:58 |
| IntuitiveNipple | Keybuk: It's got a lot of this kind of thing: http://paste.ubuntu.com/121476/ | 16:59 |
| Keybuk | what I need to find out is whether the *next* event is caused by the previous one | 17:00 |
| Keybuk | that's possibly quite easy | 17:00 |
| Keybuk | SUBSYSTEM=="block", ACTION=="change", OPTIONS+="last_rule" as a 00-xxx.rules file | 17:00 |
| Keybuk | add that to the system, and see if the eventS stop | 17:00 |
| IntuitiveNipple | OK I'll try that now. I've just attached this most recent log-file to the bug report for you. | 17:03 |
| geser | Keybuk: http://paste.ubuntu.com/121483/ with 00-xxx.rules (complete output, no looping) | 17:13 |
| geser | after a udevadm trigger --subsystem-match=block | 17:14 |
| cjwatson | ogra: partman already complains if you don't create swap, AFAIK | 17:15 |
| Keybuk | geser: aha! fantastic | 17:19 |
| Keybuk | I bet it's something silly | 17:19 |
| lamont | should 'Running "grub-install (hd0)"...' take forever in a qemu box? | 17:20 |
| IntuitiveNipple | Keybuk: With the 00-xxx.rules the boot with udev_log="err" succeeded. About 60 seconds to the root prompt | 17:20 |
| Keybuk | IntuitiveNipple: does udevadm monitor show continuous activity? | 17:20 |
| IntuitiveNipple | Keybuk: After the system reaches the root prompt, the 'storm' has gone away. So no, it shows 'normal' behaviour at that point. | 17:21 |
| Keybuk | IntuitiveNipple: what about throughout the boot? | 17:21 |
| IntuitiveNipple | During the boot there's no way to run that manually since the storm kicks off the very moment udevadm starts. | 17:23 |
| Keybuk | so you're saying that you still get the looped events during boot? | 17:23 |
| Keybuk | or are you saying you simply don't know | 17:23 |
| Keybuk | please be accurate | 17:24 |
| IntuitiveNipple | With udev_log="err" it is difficult to know what is going on. The console reaches about 6 seconds and then all console logging ceases, the hard disk begins thrashing continuously, and it never appears to get out of the initrd stage (I was hoping by leaving it that /var/log/udev might catch something) | 17:25 |
| Keybuk | "it" ? | 17:25 |
| Keybuk | please be specific about what you are doing | 17:25 |
| Keybuk | I cannot read your mind] | 17:26 |
| IntuitiveNipple | With udev_log="info/debug" the console continues to deliver kernel messages as well as the udev output, and it takes about 80 seconds to reach the recovery root prompt | 17:26 |
| Keybuk | I don't care about how long anything takes | 17:26 |
| Keybuk | that is irrelevant | 17:26 |
| Keybuk | are you seeing the same change event for the same block device repeated over and over? | 17:26 |
| geser | IntuitiveNipple: did you also add that additional rule to the initrd? | 17:26 |
| IntuitiveNipple | Keybuk: The log messages blur the console. The log-files I attached to the bug from serial are hard to parse since there's so much in them. I've not spent a massive amount of time analysing every line of one so far | 17:29 |
| IntuitiveNipple | geser: Yes, and it allowed the system to boot but problems with /dev/disk/by-uuid/ entries missing - obviously :) | 17:30 |
| Keybuk | ok, so you see continous log messages | 17:30 |
| Keybuk | putting in that rule I asked, do you _STILL see continuous log messages | 17:30 |
| Keybuk | or do they stop? | 17:30 |
| IntuitiveNipple | With the 00-xxx rule *and* udev_log="debug" there seemed to be the same amount of log messages. | 17:31 |
| Keybuk | continuously? | 17:31 |
| Keybuk | ie. the log messages never ever stop? | 17:31 |
| IntuitiveNipple | No. Whenever I use udev_log="debug|info" the udev messages stop just before the root login is reached | 17:31 |
| Keybuk | well, that doesn't make sense in of itself | 17:35 |
| Keybuk | changing udev_log shouldn't change anything | 17:36 |
| Keybuk | are you, honestly, telling me that changing udev_log makes this bug appear and go away? | 17:36 |
| IntuitiveNipple | Yes. | 17:36 |
| Keybuk | ie. if you set udev_log to a particular value, your machine boots as normal, and udevadm monitor shows nothing if you run it while booted | 17:36 |
| Keybuk | even with the OPTIONS+="watch" rules all in place? | 17:36 |
| IntuitiveNipple | I've seen it before, with the kernel, debugging suspend/resume. Just adding additional logging added enough time delay to cure the problem | 17:37 |
| IntuitiveNipple | correct | 17:37 |
| IntuitiveNipple | This test-bed has the default install on, I've not messed with it | 17:37 |
| Keybuk | iiiinteresting | 17:38 |
| Keybuk | you know what this suggests? | 17:38 |
| Keybuk | this suggests that the inotify event is coming from one of the programs that udev runs | 17:38 |
| Keybuk | and the logging is enough to slow down the call of inotify_add_watch such that the run rule finishes before it | 17:38 |
| Keybuk | geser's debugging suggests that udev is indeed chasing its own tail | 17:39 |
| IntuitiveNipple | The thing I keep noticing is vol_id | 17:39 |
| IntuitiveNipple | It feels as if it is triggering itself | 17:39 |
| Keybuk | vol_id certainly shouldn't | 17:39 |
| Keybuk | extras/volume_id/vol_id.c:fd = open(node, O_RDONLY); | 17:40 |
| Keybuk | it opens the block device RDONLY | 17:40 |
| IntuitiveNipple | Looking through that log, I see a lot of this kind of thing, too: udevd-event[1569]: '/sbin/modprobe' (stderr) 'FATAL: Module acpi:LNXTHERM: not found.' | 17:41 |
| Keybuk | that's all normal | 17:41 |
| IntuitiveNipple | okay | 17:41 |
| Keybuk | all we're looking for is something that udev runs that opens the block device for _writing_ | 17:42 |
| === iulian is now known as Guest46483 | ||
| IntuitiveNipple | I'm reading every line in the log now, but its slow going | 17:44 |
| IntuitiveNipple | There are a *lot* of these: udevd[835]: seq 729 forked, pid [914], 'add' 'acpi', 0 seconds old | 17:46 |
| geser | Keybuk: it's 65-mdadm.vol_id.rules what's causing this | 17:47 |
| IntuitiveNipple | geser: they're not installed on this test-bed | 17:47 |
| Keybuk | http://people.ubuntu.com/~scott/udev.inotify.patch | 17:48 |
| Keybuk | could you try applying that to udev's source and rebuilding | 17:48 |
| IntuitiveNipple | I think I've noticed something. The rules are firing like mad when ACPI and PCI are creating devices | 17:48 |
| Keybuk | IntuitiveNipple: *shrug* you'd expect to see a lot of udev events then anyway | 17:49 |
| geser | Keybuk: when I comment out IMPORT{program}="vol_id --export $tempnode" from 65-mdadm.vol_id.rules the looping stops | 17:50 |
| Keybuk | geser: right | 17:50 |
| Keybuk | that's what will cause mdadm to be run though | 17:51 |
| Keybuk | so commenting out the mdadm --incremental line has the same effect, no? | 17:51 |
| ramvi | I'm customizing Ubuntu. What are possible reasons for vntwsusb not showing up in lsmod? 1. sudo depmod -a vntwusb 2. lsmod . It's also added to /etc/modules | 17:52 |
| Keybuk | how does one set up encrypted swap? | 18:00 |
| Keybuk | do I select "physical volume for encryption" then put the swap in that? | 18:00 |
| lamont | is the xml that libvirt wants to see documented anywhere? | 18:03 |
| lamont | meh. so it is | 18:03 |
| cjwatson | Keybuk: yes | 18:04 |
| cjwatson | Keybuk: (or put a physical volume for LVM in that, and put swap on LVM) | 18:05 |
| cjwatson | the reason you might do the latter is that it is much less faff to have just a single encrypted block device | 18:05 |
| Keybuk | I've gone for a full spectrum attack | 18:07 |
| Keybuk | /dev/sda1 + /dev/sdb1 -> /dev/md0 -> ext3 /boot | 18:07 |
| siretart | the other approach that many people seem to use is to avoid LVM, and just create a crypted block device and use /dev/random as key. | 18:07 |
| Keybuk | /dev/sda2 + /dev/sdb2 -> /dev/md_crypt1 -> swap | 18:07 |
| Keybuk | /dev/sda3 + /dev/sdb2 -> /dev/md1 -> lvm ubuntu -> root -> ext3 / | 18:07 |
| Keybuk | so at least one of these should show up the bug :p | 18:08 |
| Keybuk | cjwatson: about half a dozen people have reported that udev seems to chase its own tail with inotify watches | 18:16 |
| Keybuk | ie. it makes the node, sets the inotify watch, and then runs some things that write to the block device, so loops doing it over and over | 18:17 |
| * lamont kills trackerd with 2+hours CPU time, wonders if it will ever be interesting enough to let it complete a run | 18:18 | |
| IntuitiveNipple | lamont: That's a bug - it writes its IntegrityCheck=1 value into the database back to front :) | 18:20 |
| lamont | huh? | 18:21 |
| alex-weej | jaunty broke some kind of very important library i think | 18:21 |
| alex-weej | a few weeks ago | 18:21 |
| IntuitiveNipple | lamont: https://bugs.edge.launchpad.net/ubuntu/+source/tracker/+bug/324300 | 18:21 |
| ubottu | Ubuntu bug 324300 in tracker "Incorrect parameter order for SetOption" [Unknown,Fix released] | 18:21 |
| alex-weej | i am trying to use apt to upgrade my system from the live cd | 18:21 |
| alex-weej | but chrooting doesn't work because i can't run a shell or any other command due to said breakage | 18:22 |
| alex-weej | so i need a way of telling dpkg to work on files in /some/mountpoint | 18:22 |
| lamont | trackerd uses sqlite? | 18:22 |
| lamont | ZOMFG | 18:22 |
| lamont | /dev/md4 968864600 386122036 572982160 41% /home | 18:23 |
| cjwatson | Keybuk: yeah, I saw - being called away now though, I'm afraid | 18:26 |
| geser | Keybuk: tested your patch, no improvement (it got only harder to stop it, had to use the init-script) | 18:28 |
| Mamarok | mdz: you around? | 18:33 |
| lamont | IntuitiveNipple: I've always assumed it just meant I needed to clean up /home :) | 18:34 |
| IntuitiveNipple | lamont: Well I thought it was just all my Evolution imap4 accounts and the number of mailing lists I'm subscribed to | 18:35 |
| lamont | then again, apt-get remove --purge tracker; killall -9 trackerd seems to fix it for me quite nicely | 18:35 |
| IntuitiveNipple | lamont: upstream have completely reworked the code now, and so I think we'll be left to patch what we have ourselves | 18:36 |
| lamont | though sometimes I wonder what I'm missing by doing that | 18:36 |
| IntuitiveNipple | I found google-desktop was better than trackerd | 18:36 |
| lamont | I choose not to share my desktop with google | 18:36 |
| Mithrandir | I choose not to share my desktop with tracker. | 18:37 |
| lamont | then again, on the rare times that I need to find something, uh... find works well enough for me | 18:37 |
| lamont | Mithrandir: what exactly does tracker purport to do? | 18:37 |
| directhex | ehm... track things? | 18:37 |
| lamont | duh | 18:37 |
| IntuitiveNipple | index files via metadata etc | 18:37 |
| Mithrandir | lamont: apart from filling up your home partition and burn in your CPU? | 18:37 |
| Mithrandir | lamont: dunno, I've taken to just tossing it out. | 18:38 |
| lamont | Mithrandir: well, yeah... /me is searching for any redeeming value in said burnage | 18:38 |
| lamont | Mithrandir: I mean, not all of the crack in the desktop is bad... | 18:40 |
| lamont | (and most of it isn't crack at all - fun distinctions to make) | 18:40 |
| Mithrandir | lamont: I think it's supposed to be a search engine. I tend to just use folders for organising stuff. | 18:41 |
| Mithrandir | (and most of the interesting bits where I want to search aren't on my desktop.) | 18:41 |
| lamont | yeah | 18:41 |
| lamont | as in it just looks in ~/Desktop? | 18:41 |
| lamont | that'd be a waste | 18:41 |
| Mithrandir | nah, as in ~ | 18:41 |
| lamont | ok | 18:42 |
| Mithrandir | still, I regularly use a bunch of different machines, and things like my email is not on this machine. | 18:42 |
| lamont | and yeah, the habits of actually organizing stuff that have grown over the past uh decade plus mean I don't really need something to find stuff for me | 18:42 |
| Mithrandir | I tend to have duplicate copies of stuff, but I generally find what I'm looking for | 18:43 |
| Mithrandir | else I have find and grep | 18:43 |
| lamont | hrm... I wonder how to bludgeon libvirt into putting the devices on the same bridge as the physical eth0 | 18:48 |
| alex-weej | if i can only run executables like this: /lib/ld-linux-x86-64.so.2 /bin/bash | 18:52 |
| alex-weej | then what do i need to do fix it? | 18:53 |
| Keybuk | geser: sure? my patch doesn't compile <g> | 18:56 |
| geser | Keybuk: it applied here, I build successfully a new source package and my pbuilder had no problems to build the deb | 18:57 |
| Keybuk | I think you're all going mad ;) | 19:00 |
| Keybuk | I just put together the most complicated setup I could think of, and still can't replicate the bug | 19:00 |
| alex-weej | help me please, my system is broken and i'm sure someone knows the quick answer | 19:01 |
| alex-weej | i can ONLY execute binaries when run under /lib/ld.so | 19:01 |
| ScottK | alex-weej: You really need to ask for help in #ubuntu or #ubuntu+1 if you are running Jaunty. | 19:01 |
| alex-weej | everyone there is just like "how do i get compiz to spin?" | 19:02 |
| ScottK | That doesn't make this a help channel. | 19:02 |
| alex-weej | ok let me rephrase my problem | 19:02 |
| alex-weej | apt HOSED my system. there is a bug somewhere. i am trying to find out what it has broken so it doesn't happen again | 19:02 |
| Keybuk | alex-weej: #ubuntu | 19:02 |
| Keybuk | this channel is for "I'm patching APT to ..." | 19:03 |
| alex-weej | i'm patching apt to not break my linker | 19:03 |
| alex-weej | but i need to know what the difference is between me manually running /lib/ld exec args and just asking the kernel to execute exec args | 19:03 |
| Keybuk | depends how the program you're execing is compiled | 19:04 |
| Keybuk | what linker is the program compiled to use? | 19:04 |
| alex-weej | well i would have thought /lib/ld-linux-x86-64.so.2 | 19:05 |
| alex-weej | but apparently not, as nothing works | 19:05 |
| Keybuk | don't think, look | 19:05 |
| Keybuk | if you don't know how, you're in the wrong channel ;) | 19:05 |
| alex-weej | "the program" is anything ubuntu has installed on my system, even /bin/true | 19:05 |
| alex-weej | Keybuk: you obviously know the answer and are just torturing me | 19:07 |
| alex-weej | :( | 19:07 |
| alex-weej | ubuntu@ubuntu:~$ sudo chroot /mnt /lib/ld-linux-x86-64.so.2 /bin/bash /usr/bin/ldd /bin/true | 19:08 |
| alex-weej | not a dynamic executable | 19:08 |
| Mithrandir | alex-weej: is /mnt mounted noexec? | 19:10 |
| alex-weej | Mithrandir: no. if it was, i wouldn't be able to run the linker ;) | 19:10 |
| Mithrandir | if you just cd to /mnt and run bin/bash, does that work correctly? | 19:11 |
| alex-weej | yes, but with the wrong libs obviously | 19:11 |
| alex-weej | wait -- ... | 19:12 |
| alex-weej | oh no, yes, ignore that. yes it works | 19:12 |
| Mithrandir | naturally. Try copying /mnt/lib into /mnt/lib.old or something and copy /lib/ld-linux-x86-64.so.2 into /mnt/lib and ditto for glibc, then chroot /mnt true and see if that works? | 19:12 |
| geser | Keybuk: I'm used to bugs which only a handful person can reproduce, in intrepid I had a kernel problem where only kees was affected too | 19:12 |
| alex-weej | Mithrandir: glibc is just libc.so.6 ? | 19:15 |
| Mithrandir | alex-weej: the file that points to, yes. | 19:15 |
| alex-weej | libc-2.8.90.so | 19:15 |
| alex-weej | yep got it, no luck | 19:15 |
| Mithrandir | can you strace it? | 19:16 |
| Keybuk | geser: are you around tomorrow? | 19:17 |
| geser | yes, starting from 10 UTC or so | 19:17 |
| alex-weej | Mithrandir: yeah. do you want me to reinstate the real lib folder? | 19:19 |
| Mithrandir | alex-weej: either one which fails should tell us something | 19:19 |
| alex-weej | i did tr this first but couldn't figure it out | 19:19 |
| alex-weej | Mithrandir: actually, do you want me to strace the chroot process or trying to exec a process within the chroot? | 19:20 |
| Mithrandir | alex-weej: you need to strace the chroot call. | 19:21 |
| Mithrandir | so sudo strace chroot /mnt /bin/true | 19:21 |
| Mithrandir | then pastebin that. | 19:21 |
| alex-weej | ok the other one is interesting though, i'll show you both | 19:21 |
| alex-weej | Mithrandir: http://rafb.net/p/N1GgmP21.html is what you asked for, and http://rafb.net/p/wVWnv565.html is the one within the chroot (running strace via ld and trying to execute "bash") | 19:24 |
| Mithrandir | alex-weej: can you try using true rather than bash? | 19:25 |
| Mithrandir | alex-weej: and can you do strings /mnt/bin/true | grep ^/lib ? | 19:25 |
| alex-weej | Mithrandir: sure | 19:35 |
| alex-weej | Mithrandir: http://rafb.net/p/UkEibD20.html and http://rafb.net/p/xTwDG588.html | 19:37 |
| alex-weej | also true has /lib64/ld-linux-x86-64.so.2 in it, that's it | 19:38 |
| === ssweeny_ is now known as ssweeny | ||
| Mithrandir | and that file exists and is executable and all, else nothing would have worked. | 19:38 |
| alex-weej | Mithrandir: indeed, there's no /lib64 in /mnt | 19:38 |
| Mithrandir | ah | 19:38 |
| Mithrandir | that'd explain it | 19:38 |
| alex-weej | so it looks like coreutils was upgraded or something and they changed to /lib64 | 19:38 |
| Mithrandir | just make it a symlink to /lib | 19:39 |
| Mithrandir | no, it's always been lib64 | 19:39 |
| alex-weej | this system used to work... | 19:39 |
| Mithrandir | yes, so something ate the symlink. | 19:39 |
| alex-weej | Mithrandir: ok now i can just chroot and indeed it seems to work fine | 19:40 |
| alex-weej | is strings the only way to check what linker a bin is supposed to use? | 19:40 |
| Mithrandir | it's at least an easy way to do so. :-) | 19:41 |
| alex-weej | ubuntu@ubuntu:/$ dpkg -S /lib64 | 19:41 |
| alex-weej | libc6: /lib64 | 19:41 |
| alex-weej | maybe a bug in libc6 packaging? | 19:41 |
| Mithrandir | it could be. | 19:41 |
| alex-weej | ok i'll get uptodate and see what happens | 19:42 |
| alex-weej | the fact that when i booted it just says "/sbin/init - no such file or directory" is a bug though i think | 19:42 |
| alex-weej | the missing linker is causing that error message and it's getting misrepresented by the looks of things | 19:43 |
| lhoersten | whenever I log out of gnome, my screen turns black (backlight still on) and my computer becomes unresponsive. ctrl + alt + backspace/delete do nothing. I don't see a cursor in the top left either. Anyone have any ideas how to debug this? | 20:33 |
| lhoersten | seems launchpad has nothing similar | 20:34 |
| IntuitiveNipple | Keybuk: I've managed to catch it in the act and log it. | 20:42 |
| lamont | wtf do I get EPERM from a write to a connected UDP socket on localhost? | 20:42 |
| lamont | *giggle* | 20:44 |
| === asac_ is now known as asac | ||
| mdeslaur | Keybuk: you can't reproduce it? | 21:52 |
| mdeslaur | Keybuk: here's the script I used to create my encrypted swap: http://paste.ubuntu.com/121574/ | 21:55 |
| hunger | Keybuk: I have that issue without any encryption. Just plain LVM. | 22:01 |
| hunger | Keybuk: I do not even have / on LVM... that is on boring plain partition. | 22:03 |
| cjwatson | Keybuk: you reassigned bug 328045 to partman-base - do you have any help to offer on it? | 22:26 |
| ubottu | Launchpad bug 328045 in partman-base "[jaunty] Jaunty CD installation problem during harddisk partitioning" [Undecided,New] https://launchpad.net/bugs/328045 | 22:26 |
| cjwatson | stgraber: any progress on bug 328097? | 22:27 |
| ubottu | Launchpad bug 328097 in partman-auto "preseeding partitionning isn't working anymore hardy 8.04.2" [Undecided,Incomplete] https://launchpad.net/bugs/328097 | 22:27 |
| stgraber | cjwatson: haven't had much time to look at it recently, I should be less busy next week now that we're feature-frozen so I hope to have some time to debug it | 22:35 |
| cjwatson | stgraber: thanks | 22:40 |
| === Daviey_ is now known as Daviey | ||
| LaserJock | cjwatson: with the latest DVD the preseeding is gone by d-i complains about the ubuntu seed file being gone | 22:47 |
| === rgreening_ is now known as rgreening | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!