[12:03] It needs to be loaded in the initrd on IDE root systems, though. [12:03] I had to add ide-generic to get my laptop to boot, anyway. [12:03] oh, you aren't using hotplug in your initrds? [12:04] No, the plan had been to have hotplug in userspace give me a list of the drivers, and then I loaded all of those manually. [12:04] That way hotplug at bootup got the coldplugging events. [12:04] hmm [12:04] Or rather at sysvinit time. [12:04] proper hotplug in the initrd has many benefits [12:04] (I tend to think of boot up being after I've chained to the proper init) [12:05] like not having to mangle the initrd if your root device moves [12:05] Yup. The downside is that it means all the boot drivers and stuff need to be in the initrd. [12:05] Doable, though. [12:05] That would actually make my task so far way easier. [12:05] storage drivers and network drivers should be there [12:05] (network to support NFS-root) [12:05] and usb keyboard. [12:05] yeah [12:05] that would address another class of bugs too [12:05] Yup [12:06] it'd do two coldplugging rounds, one with the initrd modules only, and a second one with all modules [12:06] Cool. Id' been chatting with dilinger about various ways to convince hotplug to give me a list of the devices that it would need for any given kernel version. This saves that hassle at the cost of a larger initramfs. [12:07] this is what I thought you were talking about earlier [12:07] when you said you were doing it so as to replace initrd-tools [12:07] mdz: Nope. I wanted to keep the initramfs small so do it at generate time. [12:08] Doing it at boot time is a simpler version of it. [12:08] so either way, using the hotplug infrastructure rather than mkinitrd's hacks [12:08] Yes. =) [12:08] but we were thinking of two different approaches [12:08] we're already using hotplug in d-i [12:08] so we've got its dependencies down to a manageable level [12:09] Yeah, saw that on the hoary goals. [12:09] it basically works with busybox-cvs + module-init-tools, I think [12:09] *sigh* hotplug doesn't apply all of its patches cleanly on a fresh apt-get source. [12:09] oh? [12:10] I've been using the tools that come with klibc, but I've seen that other people have gotten hotplug running with klibc. [12:10] unstable or hoary? [12:10] hoary [12:10] they all apply for me in hoary [12:10] ppc box. The only non-ubuntu thing on here is dvdcss and the debian ppc kernel (Hoary's doesn't boot on the pegasos box. The grub2 update on Monday should fix) [12:10] Applying patch debian/patches/./blacklist2-eepro100 failed! [12:11] how weird [12:11] it's possible that it's never been built on powerpc before [12:11] but I see no reason why that should matter [12:11] Applying patch debian/patches/./blacklist2-eepro100 successful. [12:12] Nothing in the hotplug Makefile or the spec file about klibc, but hopefully it's not too much elbow grease to beat it into shape. [12:13] hotplug doesn't have any binaries [12:13] it's all scripts [12:13] Oh, is it all shell? [12:13] btw, as of 2.6.10, there's no /sys/bus/pci/devices/xx/driver symlink - helps with coldplug [12:13] Nice. =) [12:13] s/no // [12:13] the only C bit is grepmap, which is 1) in a separate package, 2) extremely simple (should be fine with klibc), and 3) optional :-) [12:14] it really helps performance, though, so I recommend bringing it into the initrd [12:14] when you have only few modules in initramfs, performance does not matter [12:14] (or initrd, whatever) [12:15] and, using modules.alias instead of modules.*map for most things speed things up further [12:15] I'm not sure how few we'll end up with [12:16] hotplug doesn't seem to have any support for modules.alias whatsoever [12:16] mdz: i think we talked with you about this very stuff a while back, no? ;) [12:16] yes [12:17] modules.alias works for pci - the most important thing. inputmap (where modules.alias does not work) is small [12:17] but you're arguing a nonexistent solution against an existent one, and the existent one always wins :-) [12:17] non-existing? [12:17] hotplug does not use modules.alias [12:17] it uses modules.*map only [12:18] the version we're using, anyway [12:18] while read alias module; do case $deviceid in $alias) echo $module;; done < modules.alias -- that's all that is needed [12:18] dash rocks, btw [12:19] or, rather, while read junk alias module; do ... [12:19] that, getting deviceid into the right format, and testing it for a few thousand user=months, yeah, that's all :-P [12:19] s/=/-/ [12:19] eh? [12:20] printf "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02X" $vendor $device $s_vendor $s_device $baseclass $subclass $if [12:20] that's the $deviceid [12:21] for PCI devices [12:21] vendor etc are from /sys/bus/pci/device/xx/vendor etc directly [12:21] yes [12:21] the main case [12:21] I see no incentive whatsoever for us to switch to using modules.alias, honestly [12:21] usb is even simpler [12:21] that switch makes grepmap even more optional [12:22] I'm not entirely convinced of that [12:22] just doing a while/read loop over the pcimap took longer than running grepmap [12:22] note modprobe handles wildcards for you, so that while.. loop is not needed [12:22] mdz: At 200k uncompressed, I don't want to use more than I have to. =) [12:22] but that loop is fast - much faster than current cruft in pci.agent etc [12:23] jbailey: I don't see much choice about adding busybox to that, if we're going to use hotplug [12:23] that's ~128k [12:23] btw, module stuff in busybox is sorta broken [12:24] yes, that's why we don't use it [12:24] not even in the installer or initrd [12:24] and busybox is a very good thing to have in an initrd [12:24] helps alot if something goes wrong [12:25] mdz: There are reports on the hoplug list that maked it look like udev, hotplug, klibc, and modprobe should be enough. [12:25] we need busybox for a shell toolbox, not for module utilities [12:25] (saved my ass several times with broken root raid stuff ;) [12:25] jbailey: the hotplug scripts use cut, all sorts of stuff that's not built into dash [12:26] some of them even use awk, but those are not needed in initrd [12:26] grep [12:26] cut - where? in tape.agent? [12:27] grep - in net.agent? [12:27] grep is used _everywhere_ [12:27] Yeah. The utilities in klibc doesn't have grep or cut. [12:27] sed is used _everywhere_ [12:27] cat false insmod ln mkfifo nuke run-init true uname chroot fstype ipconfig minips mount pivot_root sh udev dd gzip kinit mkdir nfsmount printf sleep umount [12:27] in hotplug.functions, really [12:28] mjt: in functions in hotplug.functions which are called from _everywhere_ [12:28] yeah [12:28] http://sourceforge.net/mailarchive/forum.php?thread_id=6319817&forum_id=3157 is the email that I'm looking at. [12:29] busybox gives you everything needed to run hotplug at a small cost [12:29] though if you're doing initramfs rather than initrd, that would make busybox a build-dep of the kernel, no? [12:29] grep $MODULE /proc/modules - ugh, isn't it simpler to use [ -d /sys/module/$MODULE ] ? Or just let modprobe to do its work? ;) [12:29] the former is portable across 2.4 and 2.6 [12:30] hell, 2.2 [12:30] is 2.4 supported in ubuntu? [12:30] mdz: No. initramfs can be generated anytime after. You can just make a cpio image and hand it to the kernel the same way you hand it an initrd. [12:30] no [12:30] but it's supported by hotplug === Kaloz [kaloz@arrakis.dune.hu] has joined #ubuntu-devel [12:30] hotplug is not specific to ubuntu :-) [12:31] mdz: If we *did* make it a dependancy of the kernel, we could just ship an already configured initrd. Apparently (I haven't tested) you can hand in multiple cpio files and it'll unpack them all. [12:31] initramfs works the same way as any other sort of initrd. except of the way you do final pivot_root/whatever stuff - for initramfs, there's special utility in klibc for that. [12:31] a preconfigured initrd would be pretty fly [12:31] mdz: So that way the only bit to be done is just light config files (mostly for sane net booting), but those can also be handed in on the command line. [12:31] jbailey: is cpio like tar; you can just concatrenate stuff? [12:32] jbailey: there's so much potential for weird bugs generating the initrd on the fly [12:32] neither tar nor cpio can be concatenated ;) [12:32] sladen: Eh? [12:32] you can concatenate new files to a tar [12:32] s/concatenate/append/ [12:32] mjt: okay, remove the 2kB of zeros from the end :) [12:32] New files, yes. Not multple tars. [12:32] after removing the trailer, yes [12:33] Yeah. [12:33] both tar and cpio have a trailer record [12:33] mdz: Ayup [12:33] btw, generating initramfs (the cpio part) is umm.. not easy [12:33] mdz: So... I'll need to do a version of busybox that's built with klibc. [12:33] mjt: http://people.ubuntu.com/~jbailey =) [12:33] jbailey: we would need to build-dep on non-kernel stuff anyway, I guess; klibc seems to lack a shell ;-) [12:33] mdz: klibc has ash. [12:34] i've written something in shell to do that (cpio) -- pretty fun stuff [12:34] oh? [12:34] in how many places do we need to duplicate this stuff? :-) [12:34] BTW, you really want a newer version of the mkinitramfs than is there. I found a bug a minute or so ago. =) [12:34] mdz: As few as possible, ideally. =) But we don't live in an ideal worls. [12:34] jbailey: can yours be used as non-root? [12:34] we already fork loads of stuff into busybox [12:35] btw, why klibc? [12:35] mjt: Yes. (cd ${TMPDIR} && find . | cpio --quiet --dereference -o -H newc | gzip -9 >${outfile}) [12:35] there's nothing that stops using other stuff (dietlibc, uclibc, even glibc but it's large) in initramfs [12:36] mjt: The difference is that klibc is eventually being targetted to be integrated in with the kernel build anyway. [12:36] mjt: udev is already prewired for udev, as is the replacement for pivot_root [12:37] what does the pivot_root replacement do differently? [12:37] jbailey: hmm. that cpio example - 2 probs. first of all, it packs ./ instead of / - last time i checked kernel chocked on that (that's why i wrote "my own cpio" in shell - pretty easy really); and 2), that way requires mknod, which is root-only [12:38] mdz: It cd's into the mounted root directory, deletes everything on the parent filesystem, overmounts the mounted directory as /, unmounts the previous one. [12:38] mdz: So it's all done in userspace, no in kernel magic. [12:38] mdz: take a look at kinit in klibc [12:38] mjt: It's working fine on two systems here with the ./, and there are no devices in there. [12:38] jbailey: hmm, I hope that doesn't mean pivot_root(2) is going away [12:38] mjt: The kernel provides /dev/console automatiically. Everything else is done with udev. [12:39] mdz: I beleive that it does. [12:39] pivot_root isn't needed with initramfs [12:39] what about kernel threads? [12:39] they find their way to the new root ok? [12:39] mdz: I'm using run-init. kinit isn't quite useful yet. [12:40] er.. how it's not useful? [12:40] oh /me bad [12:41] kinit in klibc 0.198 seems to use pivot_root [12:41] i really meant run-init, not kinit ;) [12:41] oh, run-init is the example [12:41] mjt: It's a conglomerate tool that basically just combined run-init and nfsmount. It doesn't have anything in the way of extra magic. I think I had another concern about it, but it's not coming to mind. [12:41] utils/run-init.c [12:41] yeah - sorry for the noise [12:41] I would not have expected mount(".", "/", NULL, MS_MOVE, NULL) to work :-) [12:42] mjt: No, all good. =) I'm still learning the new initramfs stuff. I went to a workshop at OLS on it and come out with more questions than I went it with. [12:42] but I can certainly adapt casper to that when pivot_root goes away, assuming kernel threads dtrt [12:42] what's wrong with kernel threads and that initramfs/run-init stuff? [12:42] Oh! Something that occured to me. If we build the initramfs right into the kernel, would could probably still do thge DSDT update by handing it in using the initrd= method. [12:43] mdz: Casper? [12:43] jbailey: the live CD magic [12:43] it uses pivot_root(8) [12:44] so just replace pivot_root(8) with run-init(to-be-8) ;) [12:44] pretty easy to integrate into busybox, btw [12:44] more likely replace pivot_root(8) with similar mount/chroot stuff [12:45] it needs to do a few more things before execing init [12:45] and it doesn't exec init, even, it lets init do that [12:45] yes - deleting old stuff [12:45] no, I meant casper needs to do more things [12:45] mdz: I need to bug off to a dinner engagement... Anything else you need before I run off? [12:46] sleep tight guys... i'm off [12:46] i once tried to pivot_root and umount /initrd with initramfs - the kernel freezes... ;) [12:46] jbailey: nah, I need to run myself [12:46] jbailey: you want to take on #1763 for Hoary? [12:46] it would clean up a lot of mess [12:48] mdz: Yeah. I've just assigned it to me. [12:50] ok, thanks [12:50] I've been pretending to get around to it for too long [12:50] jbailey: the DSDT updates can be done at the moment by appending it onto the initrd [12:51] sladen: If we're talking about shipping a pre-generated config, though, it would be nice to not muck with the shipped kernel at all, and have grub hand it in. [12:51] jbailey: from what I remember the initramfs includes a more formal way of doing that [12:51] sladen: That way it's completely independant with no magic. [12:52] jbailey: I was originally thinking of hacking grub to do the appending at load time, but I think other people were keener on doing it in mkinitrd [12:52] sladen: I don't know enough about it yet. I'm lucky. Aside from being fubar with 2.6.10, my laptop's acpi Just Works(tm) === dholbach [~dholbach@td9091b16.pool.terralink.de] has left #ubuntu-devel [] [12:53] Kamion: how much of a headache would it be to rename /install to /boot (or some such) on the CDs? [12:53] sladen: I gotta run, sorry. [12:53] *poof* === T-Bone is now known as T-Gone [12:59] jdub: when the about ubuntu page moves into yelp, will we be able to translate it then? === eruin [~eruin@eruin.user] has joined #ubuntu-devel === Nigelenki [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-devel [01:20] Hey, can someone help me with a packaging problem I'm having. It seems like it's a simple thing I'm overlooking (a make error) but, strangely, the .deb file builds and works fine (although it bugs out before it can ask for my password) [01:22] .deb file should not ask for any passwords... [01:22] Err yeah it gets there and then bugs out before signing the dsc === decko_ is now known as decko [01:23] if there's a "make error", it should not build. error in signing (as dpkg-buildpackage performs) is non-fatal [01:26] would enabling extended attributes on the home directory by default [01:26] inpact performance [01:26] impact [01:28] just enabling EAs makes no difference [01:28] beagle needs it :) [01:28] so I wonder if it be worth while for ubuntu to enable it [01:28] enabling and *using* ACLs (which are built on top of EAs) will impact performance a little [01:29] does ubuntu create a seperate partition for /home if you select default install? [01:29] lupus_: no [01:29] your question was like "if i put this dir there, will it impact on peformance?" -- the answer is "yes, if you will hit the dir hard" ;) [01:30] rehi all [01:30] isn't it safer for the user if ubuntu would create a seperate partition for /home and maybe /var [01:31] I remember my slackware box not working anymore after 8gig of logs :) in /var hehe [01:31] gig = GB === thully [~thully@151.144.199.217] has joined #ubuntu-devel === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #ubuntu-devel === Sparhawk_ [~sparhawk@c-24-14-121-93.client.comcast.net] has joined #ubuntu-devel [01:36] I can officially say that the timezone bug is GONE! Just tested w/system clock on local time (and Windows installed) and everything seems to be working fine [01:37] nice :) [01:42] which $TZ bug it was? === lamm3r [~xkill@techno.inviter.com.br] has joined #ubuntu-devel === lamm3r [~xkill@techno.inviter.com.br] has left #ubuntu-devel [] === syn-ack [~meskes@ip68-228-61-85.tc.ph.cox.net] has joined #ubuntu-devel === thully [~thully@151.144.196.157] has joined #ubuntu-devel [01:58] mdz: when the about ubuntu page is docbook based, the doc team can set up i18n infrastructure for it [01:58] mdz: yelp will handle i18n/docbook === kent [~kent@83.249.62.252] has joined #ubuntu-devel === lupus_ [~lupus@dC38296D1.access.telenet.be] has joined #ubuntu-devel === Sparhawk_ [~sparhawk@c-24-14-121-93.client.comcast.net] has joined #ubuntu-devel [02:12] mdz: you still need me? [02:13] mako: no, I was looking for a copy of the keyring from Mataro, but I ended up finding them all on keyservers anyway [02:13] . o O { don't throw away please } [02:13] I am posting this link again :) if anyone has remarks or other stuff, mail me and I'd appriciate it : the new g-s-t pkg should have ubunut's 2 default profiles for creating users, default (unprivileged) and Desktop , link: [02:13] http://muse.19inch.net/~sivan/g-s-t/ [02:14] mdz: i think it's at people.u.c/~mako/ksp-mataro/ [02:14] mako: that page lies and says that it will be there by the time of the keysigning [02:14] but there's no link [02:14] ok.. i forgot to turn on the link [02:14] i did upload it [02:14] let me fix that [02:15] speaking of repeating "postings".. what to do with videocard driver problem in xorg package? Just file a bugreport? === sivang is out for the night. Night all! [02:16] mdz: fixed [02:16] mjt: bug report on xserver-xorg [02:16] (i've a prob with trident_drv - xv extension does not work; while using that driver from xfree-4.3 helps - surprizingly it works with xserver-xorg) [02:17] er [02:17] so the next question is - how to file a bugreport against ubuntu package? I've a mix of debian/ubuntu right now, and don't even know where's the ubuntu bug tracking system... ;) [02:18] if you have a mix of Debian and Ubuntu, try reproducing your problem with only Ubuntu first [02:18] that is not a supported configuration [02:19] it does not really matter in this case [02:19] booting a Hoary daily live CD would be a good test [02:19] don't be so sure === thully___ [~thully@151.144.199.185] has joined #ubuntu-devel [02:20] eh-heh.. I't be nice to have live CD here... ;) [02:20] for some reason it isn't available in russian stores ;) [02:21] it is available on russian Internet [02:22] http://cdimage.ubuntu.com/daily-live/current/ [02:22] sure it is [02:23] 497Mb / 3Kb/s = 165666 sec = 46 hours ;) === mjt hides... [02:23] gah, openGL apps are still hanging my laptop [02:25] speaking of benig sure -- what else, except of the xserver package (well, all packages from xorg source, really) can be a problem in this case? === Icy [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-devel [02:26] i see no other possibility === thully___ [~thully@151.144.199.185] has left #ubuntu-devel ["Leaving"] [02:31] it is inappropriate to file bugs based on a mixed system [02:31] it is documented extensively that we neither recommend nor support this === Icy [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-devel [02:33] mjt: you have no idea the amount of weird problems that can spring from Debian with half the Ubuntu X.Org packages on them, trust me [02:34] i think i do have that idea... ;) [02:34] been there myself ;) [02:36] this very prob is driver-vs-hardware, not software-vs-software issue [02:38] mjt: your request would be better received if you partitioned, ran a pure ubuntu hoary system, and THEN checked for the problem, and filed the bugreport [02:39] ok [02:39] you should choose whether you want to run Debian or Ubuntu; neither project will want to receive bug reports from a system with both sets of packages [02:40] i really just wanted to know whenever i can solve the prob directly, with a help from someone more expirienced with that area [02:40] for now it works for me, after "downgrading" the driver to xfree-4.3, so i'm all set [02:41] no "broken" bugreports (from mixed install/whatever), that is. === Nigelenki [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-devel [02:43] maybe someday i will have some time to debug/fix it myself, who knows.. [02:45] thanks for understanding [02:48] oh well === robertj [~robertj@66-188-77-153.cpe.ga.charter.com] has joined #ubuntu-devel === Nigelenki [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-devel [02:50] mdz: email sent to ubuntu-devel [02:51] YokoZar: I hope that you don't intend to notify me of each message sent to ubuntu-devel ;-) [02:51] ehh, nah. Just the first big one we were talking about last night [02:51] there are quite a few of them, and I am subscribed to the list, so they are sent to me automatically [02:52] mdz: is there going to be an install updates automatically option on update-manager? [02:52] i see the download option all there by it's lonely self [02:53] robertj: very tentative maybe once some other bits fall into place [02:53] no, I don't expect there will be [02:53] it isn't wise to install Ubuntu updates unattended [02:54] robertj: but vveeeerrrryyy tentative [02:54] especially not on a development branch [02:54] mdz: well on the dev branch I understand, but for stable it seems like a good idea [02:54] mdz: once we've got "you need to re-login" and "you need to reboot" flags for upgrades, letting users turn automagic installs on stable systems would be fairly sane [02:55] jdub: might I add that XP does not behave smartly in this regard [02:55] I disagree; packages are not designed with that in mind [02:55] if you don't respond to the dialog it will automatically reboot your system, which is just great when you are playing a game [02:55] haha [02:55] nice one. [02:56] the user takes an explicit action, saying "it is OK if things get a bit weird until I am finished with this operation" [02:56] and things do get weird [02:56] auto download is a nice (and already implemented in apt) option [02:56] mdz: security updates should minimize wierdness though [02:56] Perhaps we should incorporate more XP annoyances like that into Wine, to make it more compatible. [02:56] firefox upgrade == weird! [02:56] YokoZar! DUDE! [02:56] man, i've been trying to catch you :) [02:56] Ah [02:56] hey [02:57] installing during an idle time might be nice [02:58] what's an idle time? [02:59] mdz: you can answer the autopackage question :) [02:59] HrdwrBoB: when does your screensaver start? :) [02:59] yeah, it's good enough for most users [02:59] jdub: yes, but when I come back to my desk and firefox is all bizarre because it updated while I was at lunch [02:59] or all the windows have closed [03:00] or you get those wonderful xul errors [03:00] "you can't quit because