| === sethmahoney [n=seth@67-42-7-62.ptld.qwest.net] has joined #ubuntu-boot | ||
| === sethmahoney [n=seth@67-42-7-62.ptld.qwest.net] has left #ubuntu-boot [] | ||
| === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-boot | ||
| === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-boot | ||
| === Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-boot | ||
| fabbione | Keybuk: you got your ubuntulog | 08:33 |
|---|---|---|
| Keybuk | thanks | 08:33 |
| fabbione | Keybuk: anyway the best is to just send me a mail | 08:34 |
| fabbione | becuase the bot is like -20 in my priority list :) | 08:35 |
| Keybuk | is that nice -20, or ... ? :p | 08:35 |
| fabbione | ehhe | 08:36 |
| Keybuk | infinity: random question; are we leading the initramfs-tools versions or are Debian? ... I'm making quite major changes, so it would feel more natural to release it was 0.40ubuntu1 or something | 09:12 |
| makx | ubuntu is behind atm. | 09:22 |
| Keybuk | fsvo "behind" | 09:23 |
| Keybuk | all the changes in your 039 are irrelevant for ubuntu | 09:23 |
| makx | we have changes jbailey ok'ed but didn't want to push yet for breezy | 09:23 |
| Keybuk | and replaced by those in our 040, which won't work for Debian | 09:24 |
| Keybuk | (or whatever version we use for it) | 09:24 |
| infinity | We haven't merged with Debian yet, nor have I had time to tell makx what Debian changes I think are utter crack so we can merge the other direction. | 09:24 |
| infinity | So, pick a version number at random, and make sure it has "ubuntu" in the name, and we'll sort it later. :/ | 09:24 |
| Keybuk | infinity: ok | 09:24 |
| === infinity has been too busy to do much of anything with it and, frankly, has been ignoring initramfs while you've had your hardware activation lock on it. | ||
| infinity | So, hurry the heck up. :) | 09:25 |
| Keybuk | am doing my changes right now :) so the lock will be released once these are done and uploaded | 09:25 |
| makx | you still don't have a manpage for update-initramfs | 09:26 |
| Keybuk | infinity: one thing I'm considering ... would it make more sense to provide initramfs-tools hooks and scripts in udev, which will just get copied in, rather than hardcoding use of udev into initramfs-tools ? | 09:26 |
| makx | Keybuk: yes | 09:27 |
| makx | we already have an hooks/udev | 09:27 |
| makx | inifinity: please tell what is utter crack? | 09:28 |
| infinity | Keybuk : That would be beyond fine. | 09:28 |
| infinity | Keybuk : In fact, that's what we SHOULD be doing. | 09:28 |
| infinity | Keybuk : The less package-specific cruft we have in initramfs, the better. | 09:28 |
| infinity | Keybuk : If that approach can be done in both Debian and Ubuntu, our diffs may get very small again. | 09:29 |
| Keybuk | ok, because scripts/init-top/udev makes a lot of sense to me | 09:29 |
| Keybuk | along with hooks/udev to copy over things | 09:29 |
| infinity | (Which is one motivation for making it work that way) | 09:29 |
| Keybuk | and ship those in udev itself, rather than in initramfs-tools | 09:29 |
| infinity | makx : Nothing is "utter crack" so much as stuff that should be discussed. I was being overly dramatic for effect. :) | 09:30 |
| infinity | Keybuk : Yes please. | 09:30 |
| makx | infinity: evms will move to it's package what else is bad? | 09:31 |
| infinity | evms was one, yes. | 09:31 |
| infinity | Realistically, anything that can be factored back out (and our own implementation was guilty of this before you started hacking on it) should be removed. | 09:31 |
| infinity | The more initramfs is kept as a flexible framework with very little actual "content", the better. | 09:32 |
| Keybuk | actually, now I think about it, it should be init-premount as otherwise it'll happen before module loading -- and conf/modules should happen first | 09:32 |
| infinity | I'm also wondering at what stage we should declare klibc a failed experiment, and just use glibc everywhere. | 09:33 |
| makx | do we have everything in busybox? | 09:33 |
| Keybuk | infinity: the klibc utilities are useful, but that's it | 09:33 |
| infinity | Keybuk : What does klibc ship that we couldn't get from turning on some busybox options? | 09:33 |
| infinity | (or building a few tiny binaries of our own, linked against glibc) | 09:34 |
| makx | would help a lot on Debian, klibc isn't ready for quite some archs | 09:34 |
| Keybuk | infinity: no idea, the binaries that come with klibc are tiny | 09:35 |
| Keybuk | we could just copy anything there we didn't have in busybox | 09:35 |
| Keybuk | run-init is probably the main one ;) | 09:35 |
| infinity | Reimplementing without klibc (whether or not we decide to use that branch) is definitely on my lis tof things to do. | 09:38 |
| infinity | So we'll see where that goes. | 09:38 |
| infinity | Right now, I should get back to making X build. | 09:38 |
| === infinity shakes his fist at keybuk. | ||
| infinity | If yo ukeep fixing my bugs, I'll have to keep fixing Daniel's bugs, and the world will go all topsy-turvy! | 10:09 |
| Keybuk | who's bugs is daniels fixing? | 10:12 |
| infinity | See, that may be where it all falls apart. | 10:13 |
| Keybuk | and who is fixing my bugs? | 10:14 |
| === pitti_ [n=pitti@195.227.105.180] has joined #ubuntu-boot | ||
| Keybuk | infinity: hmm, do we want firmware in the initramfs or not? | 10:25 |
| fabbione | Keybuk: no, you don't | 10:26 |
| fabbione | otherwise initramfs will explode | 10:26 |
| Keybuk | what if they want an nfsroot on a network card that needs firmware? | 10:27 |
| fabbione | Keybuk: tough luck... some initramfs are already too big | 10:29 |
| fabbione | and netboot on some machines is broken for that | 10:29 |
| infinity | Well, PXE on wireless is never going to happen, but do we have wired cards that require firmware to go? | 10:38 |
| fabbione | only wireless | 10:39 |
| fabbione | afaik | 10:39 |
| infinity | fabbione : firmware wouldn't explode the initramfs. Most firmware is way smaller than the driver it goes with. | 10:39 |
| fabbione | infinity: we are already fighting with oversize.. we need to put initramfs on a heavy diet | 10:40 |
| infinity | But, if we only ship firmware for wireless, it's not much of a win to have it in the initramfs IMO. | 10:40 |
| infinity | fabbione : Putting it on a diet is as simple as changing the mode used to build it. It's undecided at the moment if we WANT to do that, though. | 10:40 |
| infinity | (The current mode has the advantage of being portable between hardware devices, whereas the smart detection modes mean if you chage your hardware, your system may not boot) | 10:40 |
| fabbione | infinity: ppc can't netboot.. it has been decided already :) | 10:41 |
| fabbione | starting from the amount of drivers will be in the udeb and so on... | 10:41 |
| Keybuk | Kamion: ping? | 10:54 |
| Keybuk | Kamion: (for your scrollback pleasure) ... could we nuke the d-i/base-config/debootstrap/whatever-does-it thing that adds /proc to /etc/fstab ... it's absolutely useless ;) | 10:56 |
| Kamion | it's nice to be able to 'mount /proc' without having to remember the arguments | 11:01 |
| Kamion | but file a bug on partman-target with rationale as to why it's actively bad to have it there | 11:01 |
| Keybuk | it's not so much actively bad, as misleading | 11:04 |
| Keybuk | it's never used by the main boot, so gives users the illusion that they can change it there and have some effect | 11:04 |
| Keybuk | and as /sys and /dev aren't alongside it, it looks strange | 11:04 |
| Kamion | need to also check that stuff in d-i doesn't rely on it | 11:05 |
| Kamion | (obviously it would be easy to change) | 11:05 |
| === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-boot | ||
| jbailey | Keybuk: wireless nfsroot will probably want firmware. | 01:24 |
| jbailey | fabbione: ppc can suck raw eggs. =) What we did in Debian for initrd was to set ppc to dep and not the others. | 01:25 |
| fabbione | dep? | 01:26 |
| fabbione | dude.. i have a ppc | 01:26 |
| fabbione | and i use netboot | 01:26 |
| fabbione | initramfs must work | 01:27 |
| fabbione | or i am going to make an offer this channel can't refure | 01:27 |
| fabbione | refuse even | 01:27 |
| jbailey | So set your initramfs generator to dep mode. | 01:29 |
| jbailey | Just because that arch is broken doesn't mean the others need to be penalised against a very useful use case. | 01:29 |
| fabbione | i still need to figure who does root over wireless | 01:30 |
| makx | jbailey: please upload latest initramfs-tools :) | 01:32 |
| jbailey | makx: I'd prefer in general that 'sync with ubuntu' contained some level of details. | 01:37 |
| === jbailey builds. | ||
| jbailey | It's not that important since Ubuntu is upstream for you. | 01:38 |
| jbailey | But since that's the only changelog file, you're actually dropping information there. | 01:38 |
| jbailey | There's no way to trace what's changed without a debdiff. | 01:39 |
| jbailey | makx: Uploaded. | 01:39 |
| Keybuk | I'm confused, why can't ppc netboot? why does it have a maximum ramfs size? | 02:14 |
| fabbione | Keybuk: for some reasons OF can't load a file bigger than 6MB via tftp | 02:15 |
| Keybuk | sounds like a bug that can be fixed | 02:15 |
| Keybuk | just load the initramfs in 6MB chunks | 02:16 |
| jbailey | Keybuk: There seems to be a discussion about hostnames on the u-d. Didn't we solve this problem at ubz? | 02:17 |
| jbailey | ISTR you or someone asking about it. | 02:17 |
| Keybuk | no? | 02:17 |
| Keybuk | wasn't me | 02:17 |
| jbailey | Hmm | 02:17 |
| jbailey | Colin's apparently enabled hostname now which makes it harder to get rid of busybox if we want to at some point. | 02:17 |
| Keybuk | do we want to get rid of busybox? | 02:18 |
| infinity | I don't. busybox is love. | 02:19 |
| Keybuk | in busybox vs. klibc-utils, I err towards busybox IF we can get it to stop forking for its built-ins :) | 02:19 |
| infinity | Jeff is a purist, however, who thinks that eventually we can implement the whole thing as ed scripts. | 02:19 |
| === HiddenWolf [n=HiddenWo@136.76.dynamic.phpg.net] has joined #ubuntu-boot | ||
| jbailey | Keybuk: My idealist version is that it should be possibly to disable it and get a 20k initramfs in dep mode. =) | 02:20 |
| jbailey | possible, rather. | 02:20 |
| Keybuk | what shell would you use ? | 02:21 |
| Keybuk | and udev alone is about 150-200K | 02:21 |
| jbailey | Is it that big now? | 02:21 |
| jbailey | Hmm | 02:21 |
| jbailey | Okay, 100k then. | 02:21 |
| jbailey | initramfs' are gzip'd. | 02:21 |
| jbailey | Keybuk: There's no reason for things in there not to be ash friendly. | 02:22 |
| Keybuk | udevd is 55K, udevplug is 28K | 02:22 |
| Keybuk | all of the little helpers are about 240K together | 02:23 |
| Kamion | jbailey: harder to get rid of busybox> I don't understand how me enabling hostname makes it any harder? | 02:24 |
| Kamion | and busybox' shell *is* ash, near enough | 02:24 |
| infinity | You jus tgave us one more crutch? | 02:24 |
| Kamion | true | 02:24 |
| infinity | Not that I mind, terribly. | 02:25 |
| pitti | Keybuk: can we recognize ditital cameras by a device type argument, or do we need usermaps, just as with scanners? | 02:25 |
| jbailey | Kamion: What he said. It's only an issue if there's still value in reducing the initramfs size by switching to really tiny utilities. | 02:26 |
| jbailey | Kamion: My argument is that there is, based on the fact that reading things over the network in grub is suck, as is reading off of flash. | 02:26 |
| infinity | I'm not sure there is much value in trying to make it tiny. | 02:26 |
| infinity | Making it not HUGE is good, but I dunno how tiny it needs to be. | 02:27 |
| Keybuk | pitti: where there's a usermap now, there's probably a good reason | 02:27 |
| infinity | Poeple booting from network and flash don't do it often enough to care about a few extra seconds' boot time. | 02:27 |
| Keybuk | you can do class-matching with the existing usermaps | 02:27 |
| infinity | (At least, they shouldn't be) | 02:27 |
| Keybuk | so I figure if they could, they would have | 02:27 |
| jbailey | infinity: Having an embedded device be usable in 5 to 10 seconds is good. Loading the current sized initramfs off of CF was reported to be in the 1 to 2 minute range. | 02:27 |
| pitti | Keybuk: ok, so I'm going to merge libgphoto2 for now (just wanted to ask whether it woudd be a complete waste) | 02:28 |
| infinity | jbailey : I'd argue that our bug lies elsewhere, then, that read speed is inexcusable. | 02:28 |
| jbailey | infinity: Limitation of pc bios. No dma, sucky short reads. | 02:29 |
| jbailey | That's why it's not a problem at runtime. | 02:29 |
| infinity | (And why are embedded device folk running Ubuntu kernels and bloated initrds anyway?) | 02:30 |
| Keybuk | pitti: I think we should keep both usermaps, we can support them for free; and only remove them if we're damned sure we can replace them for every device they use | 02:31 |
| jbailey | infinity: CF != embedded in every case. | 02:32 |
| pitti | Keybuk: ok; Debian's libgphoto generates its own udev rules from the usermap ATM | 02:32 |
| jbailey | infinity: It can be thinclient as well. | 02:32 |
| pitti | Keybuk: that certainly works, but we might be able to speed it up with grepmap | 02:32 |
| Keybuk | pitti: exactly, I think we should stick with the usermap simply because the conversion sucks | 02:32 |
| pitti | Keybuk: oh, it would be a conversion in the other way | 02:32 |
| Keybuk | how do you mean? | 02:33 |
| pitti | Keybuk: the former print-usb-usermap (which generated the usermap) now changed syntax to look like udev rules | 02:33 |
| pitti | Keybuk: of course we can revert to the older version for that | 02:33 |
| Keybuk | oh right, what's the source of that? | 02:33 |
| Keybuk | ie. where does it get the ids | 02:33 |
| infinity | jbailey : It could be, yes. I did thin clients with IDE-CF once. Of course, I also don't recall them being that shit-slow at loading kernels off the CF either, so... | 02:33 |
| === Kamion wonders if there's any way to load i82365 or the other PCMCIA bridges using udev rules rather than an init script | ||
| Keybuk | for that one, it sounds like we should use the udev rules then -- call it /etc/udev/rules.d/85-gphoto.rules or something | 02:34 |
| Kamion | yenta_socket should be handled automatically now | 02:34 |
| Keybuk | Kamion: is there an event you can load them on? | 02:34 |
| Kamion | Keybuk: hard to tell - all my machines are yenta AFAIK | 02:34 |
| infinity | jbailey : Oh well. I can see that there are corner cases for tiny initrds, but I'm not sure it's a case I'm inclined to optimise for. People who really need a tiny boot can figure out how to make one. | 02:34 |
| infinity | (monolithic kernels, whatever) | 02:34 |
| Kamion | hm, well, I could move the dodgy logic from pcmcia-cs' init script into a udev rule that gets called on pcmcia_socket add | 02:35 |
| Keybuk | Kamion: grep for them in modules.alias | 02:35 |
| Kamion | Keybuk: I did; i82365 at least isn't there | 02:35 |
| jbailey | infinity: I'm not arguing to optimse for that. Certainly I'm inclined to include busybox in every common case - I like having ls around if nothing else when I'm troubleshooting. | 02:35 |
| Kamion | nor is tcic | 02:35 |
| jbailey | infinity: But if there are reasonable things we can do (like poking the value into proc rather than using hostname) I think it's worth doing. | 02:36 |
| Keybuk | Kamion: a lot of the non-yenta bridges are ISA or equally antiquated, aren't they? | 02:36 |
| infinity | jbailey : Which one report claimed didn't work. | 02:37 |
| Kamion | Keybuk: i82365 is ISA; I can't quite figure out what the hell tcic is, but it at least only does PCMCIA not Cardbus | 02:37 |
| Kamion | i82092 is PCI | 02:38 |
| Kamion | (and in modules.alias) | 02:38 |
| Keybuk | the ISA ones are a bitch, because there's no way to detect them except with a stick | 02:39 |
| Keybuk | and some machines (usually Dells) don't like being poked with a stick | 02:39 |
| pitti | Keybuk: sorry, got distracted; I think the conversion tool parses it out of the C source | 02:41 |
| Keybuk | pitti: ok, use the existing conversion tool then :) I thought you meant they had a tool to convert usermaps into udev.rules | 02:41 |
| Keybuk | so for gphoto, we should use udev.rules and write them to /etc/udev/rules.d/85-gphoto.rules | 02:41 |
| Keybuk | what does libsane do? | 02:41 |
| pitti | Keybuk: for gphoto that's exactly how Debian does it now | 02:42 |
| pitti | Keybuk: are the udev rules pre-parsed into memory structures, or are the text files parsed every time? | 02:42 |
| Keybuk | pre-parsed now | 02:42 |
| pitti | Keybuk: OTOH, udev parsing shouldn't be that much slower than grepmap, or is it? | 02:42 |
| Keybuk | note that the order matters, and our ordering is different to Debian's, so the filename might need to be different | 02:42 |
| Kamion | Keybuk: pcmcia-cs already has a pcic_probe and /etc/default/pcmcia that you can frob if you need to; all I need to do is check /etc/default/pcmcia and load what it says to load, more or less | 02:42 |
| Keybuk | Kamion: ok, we could steal that I guess | 02:42 |
| Kamion | yeah, I think what I'll do is write /lib/udev/pcmciautils that reads /etc/default/pcmcia and loads the module | 02:43 |
| makx | jbailey: thanks! :) | 02:43 |
| Kamion | and attach that to pcmcia_socket add | 02:43 |
| Keybuk | what adds pcmcia_socket ? | 02:44 |
| Keybuk | if the helper could output a list of modules, you can use a rule like: PROGRAM="/lib/udev/pcmciautils", RUN+="/sbin/modprobe $result" | 02:45 |
| Keybuk | and make the helper exit 1 if there aren't modules | 02:45 |
| Keybuk | that's then consistent with the other things that do exactly that | 02:45 |
| === infinity [n=adconrad@loki.0c3.net] has left #ubuntu-boot [] | ||
| pitti | Keybuk: Debian uses udev rule symlink 25_* (gphoto); so 85 is ok for us? | 02:58 |
| Keybuk | 85-gphoto.rules file is what we should have | 02:58 |
| Keybuk | hmm | 02:59 |
| Keybuk | hang on | 02:59 |
| Keybuk | what do these rules do, just assign permissions? | 02:59 |
| Keybuk | can you paste one? | 02:59 |
| Kamion | Keybuk: what adds pcmcia_socket> cs.c, I think, in an __init | 03:28 |
| Keybuk | right, so how does that get loaded? | 03:29 |
| Keybuk | pitti: so, yeah, paste a rule example couldya for gphoto? | 04:04 |
| pitti | Keybuk: I didn't continue the merge during the meeting, gimme some minutes | 04:04 |
| Keybuk | :( | 04:04 |
| === infinity [n=adconrad@loki.0c3.net] has joined #ubuntu-boot | ||
| Keybuk | I guess I could just steal the debian package and peek <g> | 04:05 |
| Keybuk | pitti: so, these rules are really sucky | 04:07 |
| Keybuk | could I suggest a _little_ tweak :) | 04:07 |
| Kamion | Keybuk: it's part of pcmcia_core; good question exactly what loads that first | 04:07 |
| pitti | sure | 04:07 |
| Keybuk | right now it generates something that looks like ... | 04:07 |
| Keybuk | BUS!="usb", ACTION!="add", GOTO="libgphoto2_rules_end" | 04:07 |
| Keybuk | : rules here | 04:07 |
| Kamion | for PCI systems it'll be coldplugged as usual, since the world depends on it | 04:07 |
| Keybuk | LABEL="libgphoto2_rules_end" | 04:07 |
| Keybuk | so that has a problem already | 04:08 |
| Keybuk | you can't do BUS!= :) | 04:08 |
| Keybuk | change that to be SUBSYSTEM!="usb_device" | 04:08 |
| Keybuk | then the rules themselves, they look like | 04:08 |
| pitti | BUS != 'usb' looks a bit odd anyway? | 04:08 |
| Keybuk | SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", RUN+="/etc/hotplug/usb/usbcam" | 04:08 |
| Kamion | we have a 'modprobe pcmcia' in the pcmcia_socket add udev rule for ISA systems etc., but I'm not sure what would cause that rule to actually get called on such systems | 04:08 |
| Keybuk | pitti: it's skipping the rules for anything not a usb add event | 04:08 |
| Kamion | I was hoping not to need an init script ... | 04:08 |
| pitti | ah, ok | 04:09 |
| Keybuk | and the script just assigns permissions to things | 04:09 |
| Keybuk | which is a bit doofus | 04:09 |
| Keybuk | so.... | 04:09 |
| Keybuk | could we change the output to be something like | 04:09 |
| pitti | set the permissoins right away, yes | 04:09 |
| Keybuk | SUBSYSTEM!="usb_device", GOTO="libgphoto2_rules_end" | 04:09 |
| Keybuk | SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", GROUP="plugdev", MODE="0660" | 04:10 |
| Keybuk | LABEL="libgphoto2_rules_end" | 04:10 |
| pitti | yes, that looks better | 04:10 |
| Keybuk | (and yes, I deliberately dropped the ACTION!=add thing) | 04:10 |
| pitti | I'll modify print-udev-rules-bla.c accordingly | 04:10 |
| Keybuk | then write the file as /etc/udev/rules.d/45-gphoto.rules | 04:10 |
| Keybuk | (45 not 85 so it doesn't get included in initramfs) | 04:10 |
| pitti | ok, sure | 04:10 |
| Keybuk | the rule numbers are set up in such a way that 50-xxx is the perfect place for user rules ... 20 assigns names, 40 permissions, 60 symlinks, 80 runs programs and 90 runs modprobe | 04:11 |
| Keybuk | initramfs doesn't have permissions, symlinks or programs ... so gets 0-39 and 90+ | 04:12 |
| === jbailey removes 'initramfs' from his nick highlight list. | ||
| Keybuk | now, I shall make tea | 04:14 |
| Keybuk | then I shall get my laptop booting again, after I foolishly forgot to put udev.conf in the initramfs <g> | 04:14 |
| Kamion | ok, I'm going to give pcmciautils an init script that does the bridge module probe if it needs to; I don't see a way to do this within udev | 05:02 |
| Kamion | and I'll make it take a copy of /etc/default/pcmcia as /etc/default/pcmciautils so that I don't have to deal with pcmcia-cs.postrm removing the former | 05:03 |
| Keybuk | yeah, I don't think there is a way to do it with udev | 05:03 |
| Keybuk | udev reacts to events, if there's no event to react to, there's no way to do it | 05:04 |
| Keybuk | udev will correctly react to the modprobe, of course, so all you need to do is _start_ it | 05:04 |
| Keybuk | for most devices, the thing that starts stuff is udevplug, which walks sysfs and tickles everything the kernel's found so far | 05:04 |
| Keybuk | but if the kernel hasn't found legacy pcmcia buses, there needs to be a manual stick | 05:05 |
| Kamion | all the init script does is modprobe pcmcia_core, then if there's no /sys/class/pcmcia_socket/* yet modprobe $PCIC | 05:05 |
| Kamion | basically | 05:05 |
| jbailey | I thought all of the pccard love was supposed to just get folded in so that it behaved the same as any other pluggable bus (usb, ieee1394, etc..) | 05:05 |
| Kamion | jbailey: it does, but only for PCI bridges | 05:05 |
| Keybuk | jbailey: it has been | 05:05 |
| Kamion | then once the bridge is up, the rest is a regular hotpluggable bus | 05:05 |
| Keybuk | jbailey: you still need something to modprobe the drivers for the old ISA pcmcia bridges though | 05:05 |
| jbailey | Ah, okay. | 05:05 |
| Keybuk | Kamion: ok ... beware that the /sys thing won't turn up straight away | 05:06 |
| Kamion | Keybuk: no harm done if it doesn't, I think; I've stolen the code from pcmcia-cs.init to check whether there's a yenta bridge there by poking in /sys/bus/pci/devices/*/class | 05:06 |
| Keybuk | right | 05:06 |
| Kamion | and fixed it to detect i82092 as well, which is the only other PCI bridge I can see | 05:06 |
| Keybuk | that stuff's probably needless now | 05:07 |
| Keybuk | if there's a /sys/bus/pci/devices/*/class that's a yenta bridge, then yenta_socket will be loaded | 05:07 |
| Kamion | yeah, just a sanity-check to make sure we don't accidentally probe the wrong bridge | 05:07 |
| Keybuk | and you'll have /sys/bus/pcmcia | 05:07 |
| Keybuk | *nods* | 05:07 |
| Kamion | because apparently /etc/default/pcmcia is sometimes broken on old upgrades and says i82365 when it isn't | 05:08 |
| Kamion | and we check /sys/class/pcmcia_socket/* before any of this too, so if boot-time events loaded the bridge then none of this will happen anyway | 05:08 |
| Keybuk | ok, fixed udevplug bug, time for manual boot #3 | 05:08 |
| Keybuk | ugh @ /sbin/udevplug -Bide -Bscsi -Bi2o -Busb -Bieee1394 /class/mem /class/misc /class/tty /class/vc /block | 05:10 |
| Keybuk | I'm so aliasing that to /sbin/udevplug --whatever-initramfs-needs | 05:10 |
| Keybuk | anyone know what the serio, eisa or MCA buses are? | 05:12 |
| HiddenWolf | eisa is/was a competitor to ps/2 | 05:15 |
| jbailey | eisa was an extended isa bus. | 05:15 |
| jbailey | Supported some autoconfiguration, and a slightly wider bus path. | 05:15 |
| jbailey | The sockets could also take isa cards. | 05:15 |
| Keybuk | jbailey: anything on any of those we might need for initramfs? | 05:15 |
| Keybuk | ie. storage or hid controllers? | 05:15 |
| HiddenWolf | hm | 05:15 |
| jbailey | Keybuk: EISA *might* actually be autodetectable enough for initramfs. | 05:15 |
| Keybuk | /sys/bus/eisa/devices is empty on my system (at least on initial startup) | 05:16 |
| HiddenWolf | It was somewhat expensive to implement (though not as much as MCA), so it never became particularly popular in desktop PCs. However, it was reasonably successful in the server market, | 05:16 |
| jbailey | On a truly ancient system, yeah. It was a good way of actually getting harddrive controllers in. I think my alpha has eisa. But it was popular in servers (and freaking expensive) | 05:16 |
| Keybuk | /sys/bus/MCA has turned up in 2.6.15 ... I think it wants to shout | 05:16 |
| jbailey | MCA is overloaded. | 05:17 |
| jbailey | Clasic MCA was a PS/2 architecture with autodetection. | 05:17 |
| Keybuk | I'll leave them out until someone bitches | 05:17 |
| jbailey | I think it's now something else. | 05:17 |
| Keybuk | we're already poking enough as it is | 05:17 |
| jbailey | I maintainer my argument that we don't actually care about anything pre-PCI for booting. =) | 05:18 |
| jbailey | maintain, rather =) | 05:18 |
| jbailey | Anything that old won't run gnome in any useful way. | 05:18 |
| Keybuk | what's i2o? | 05:18 |
| Keybuk | you put that in the spec when I wasn't looking | 05:18 |
| jbailey | It's a bus standard that was suppose to feature standarized drivers for high end hardware. | 05:18 |
| jbailey | I've never actually had one. Tollef has, though. | 05:19 |
| Keybuk | does it have root filesystems on it? | 05:19 |
| jbailey | It does on his box. | 05:19 |
| jbailey | initramfs-tools theoretically supports it in Breezy. | 05:19 |
| Keybuk | ok | 05:19 |
| Keybuk | # /sbin/udevplug -Bide | 05:19 |
| Keybuk | udevplug[4499] : scan_bus: unable to open bus 'ide' | 05:19 |
| Keybuk | \o/ | 05:19 |
| Keybuk | same thing for scsi, i2o, usb and ieee1394 | 05:20 |
| Keybuk | (those bits are only for compile-your-own idiots ... those buses should be missing at this point, as we haven't probed the pci bus for storage controllers yet) | 05:21 |
| Keybuk | hmm, is it really /sys/bus/ieee1394 ? I haven't got one | 05:21 |
| jbailey | jbailey@starshine:/sys/bus$ ls | 05:21 |
| jbailey | i2c ide ieee1394 macio of_platform pci pcmcia platform scsi usb vio | 05:21 |
| Keybuk | i2c ? is that different to i2o? | 05:22 |
| Keybuk | macio? vio? WHO INVENTED ALL THESE THINGS?! :) | 05:22 |
| Keybuk | my laptop has a /sys/bus/pci_express ... wonder whether we should look for controllers on that | 05:22 |
| jbailey | I think i2c is different, yes. | 05:23 |
| jbailey | I don't know how, though. | 05:23 |
| jbailey | jbailey@starshine:/sys/bus/i2c/drivers$ ls | 05:23 |
| jbailey | i2c_adapter PMac Keywest Audio therm_pm72 | 05:23 |
| Keybuk | I2C (pronounce: I squared C) is a protocol developed by Philips. It is a | 05:23 |
| Keybuk | slow two-wire protocol (10-400 kHz), but it suffices for many types of | 05:23 |
| Keybuk | devices. | 05:23 |
| Keybuk | oh | 05:23 |
| Keybuk | it's the fan-speed thing | 05:24 |
| pitti | Keybuk: hey, look at that nice rule: | 05:24 |
| Kamion | macio and vio are similar-ish I think - at least, vio uses /proc/device-tree too | 05:24 |
| pitti | # USB PTP Class Camera | 05:24 |
| pitti | SYSFS{bDeviceClass}=="06", GROUP="plugdev", MODE="0660" | 05:24 |
| pitti | Keybuk: ^ *that*'s what rules should look like :) | 05:24 |
| Keybuk | pitti: yeah, that one should work for a lot of things -- provided it's within a SUBSYSTEM!="usb_device", GOTO="..." thing | 05:25 |
| Kamion | Keybuk: fan speed, some Mac sound devices, random other stuff on Macs too | 05:25 |
| pitti | Keybuk: yes, it is, I did the conversion | 05:25 |
| Keybuk | kewl | 05:25 |
| Keybuk | right, now for the biiig test | 05:25 |
| pitti | crw-rw---- 1 root plugdev 189, 260 2005-11-24 17:25 /dev/usbdev3.5 | 05:26 |
| Keybuk | does /sbin/udevplug -Bpci -Iclass=0x010[01] * do the right thing? | 05:26 |
| Keybuk | hmm | 05:26 |
| Keybuk | that caused ide_core, alim15x3 and generic to be loaded | 05:27 |
| Keybuk | but, pointedly, no /dev/hda to appear | 05:27 |
| Keybuk | grr | 05:27 |
| pitti | Keybuk: now I'll try to convince libgphoto to actually talk to /dev/usbdev3.5 instead of /proc/bus/usb/003/004 | 05:27 |
| pitti | s/4$/5/ | 05:27 |
| Keybuk | pitti: it'll be /dev/bus/usb/003/004 with our naming rules | 05:28 |
| Keybuk | so you should just replace /proc with /dev | 05:28 |
| pitti | Keybuk: oh, ok, right now it's like above | 05:29 |
| pitti | but if that works in general, that should be fine | 05:29 |
| Keybuk | yeah, that's the "kernel-assigned" name for those devices | 05:31 |
| Keybuk | which is a bit boring | 05:31 |
| Keybuk | hmm | 05:32 |
| Keybuk | ok | 05:32 |
| Keybuk | /dev/hda, oh /dev/hda, wherefor art thou /dev/hda? | 05:32 |
| Keybuk | jbailey: ok, I'm clearly being stupid ... what provides those devices? | 05:35 |
| jbailey | Keybuk: Eh? It's in /sys/block | 05:36 |
| jbailey | What do you mean by what provides? | 05:36 |
| Keybuk | well | 05:36 |
| Keybuk | what module do I need to load? | 05:36 |
| Keybuk | they're not in /sys/block yet, because I haven't loaded the right module | 05:36 |
| jbailey | Oh | 05:38 |
| jbailey | your specific ide module | 05:38 |
| jbailey | ide-disk | 05:38 |
| jbailey | ide-generic | 05:39 |
| Keybuk | ok... so how do I know to load ide-disk? :P | 05:39 |
| jbailey | ide-generic must be last. | 05:39 |
| jbailey | You have to walk /proc/ide to get the info on each device. | 05:39 |
| Keybuk | no devices there yet ... you see | 05:39 |
| Keybuk | just /proc/ide/drivers | 05:40 |
| Keybuk | ohhh | 05:40 |
| Keybuk | I see the problem | 05:40 |
| jbailey | Right, but when you load cmd64x or whatever. | 05:40 |
| Keybuk | wtf is "generic" | 05:40 |
| jbailey | It'll be there. | 05:40 |
| Keybuk | not "ide-generic", "generic" | 05:40 |
| jbailey | Did they rename it? | 05:40 |
| Keybuk | no... | 05:40 |
| jbailey | And ide-generic doesn't have to be last, sorry, just has to be after any specific IDE drivers you want. | 05:40 |
| jbailey | But then /proc/ide will exist. | 05:40 |
| Keybuk | generic is what got loaded (along with ide-core and the specific module) when I walked the PCI bus | 05:41 |
| Keybuk | not ide-generic | 05:41 |
| jbailey | Ah. | 05:41 |
| jbailey | No idea what "generic" is. | 05:41 |
| jbailey | description=PCI driver module for generic PCI IDE | 05:41 |
| Keybuk | right, very odd | 05:42 |
| Keybuk | ok, so I need a rule in here somewhere to load ide-generic ... wonder how I'm going to shimmy that | 05:42 |
| pitti | Keybuk: how practical - our current libusb already checks for /dev/bus/usb before /proc/bus/usb :) | 05:57 |
| pitti | Keybuk: so I only need to teach it about /dev/usbdevX.Y | 05:57 |
| Kamion | ok, that's pcmciautils updated; the only thing I think pcmcia-cs is needed for now is setting up the resource database on installation, and possibly some CIS bits | 05:57 |
| Kamion | I'll look at those later | 05:57 |
| Keybuk | pitti: you probably don't need to do that | 05:58 |
| Keybuk | nobody is shipping without the /dev/bus/usb rules that I'm aware of | 05:58 |
| pitti | Keybuk: I could wait with the gphoto upload until you upload udev | 05:58 |
| pitti | Keybuk: we do at the moment :) | 05:58 |
| Keybuk | well, no, we don't TECHNICALLY :p | 05:58 |
| Keybuk | yeah, I'd wait and not support usbdevX.Y | 05:59 |
| Keybuk | hmm | 05:59 |
| pitti | Keybuk: ok, for testing I just modify my local udev rules, I guess | 05:59 |
| Keybuk | didn't we blacklist all of the framebuffer devices? | 05:59 |
| Keybuk | ahh | 06:00 |
| Keybuk | no | 06:00 |
| Keybuk | the old hotplug pci.agent just skipped them | 06:00 |
| Keybuk | hmm | 06:00 |
| Keybuk | udevplug doesn't do that, of course | 06:00 |
| Keybuk | I wonder whether there's some modprobe.d trick we can use to blacklist an entire class | 06:01 |
| pitti | Keybuk: yay, a symlink works nicely, great; thanks for your help | 06:03 |
| Keybuk | pitti: symlink? | 06:04 |
| pitti | Keybuk: /dev/bus/usb/003/008 -> /dev/usbdev3.8, just for testing | 06:05 |
| Keybuk | ahh | 06:05 |
| pitti | Keybuk: that's how your udev will create the devs? | 06:05 |
| Keybuk | it'll rename them | 06:05 |
| Keybuk | there won't be a /dev/usbdev3.8 | 06:05 |
| Keybuk | (ie. it uses NAME= not SYMLINK+=) | 06:06 |
| pitti | Keybuk: I mean /dev/bus/usb/xxx/yyy | 06:06 |
| Keybuk | oh | 06:06 |
| Keybuk | right | 06:06 |
| Keybuk | yes | 06:06 |
| pitti | ok, cool | 06:06 |
| pitti | then everything is settled | 06:06 |
| Keybuk | is that what gphoto actually looks for? it's not looking for /dev/bus/usb/3/8 ? | 06:06 |
| pitti | libsane uses libgphoto-port0, which uses libusb, which is prepared for your udev | 06:06 |
| pitti | Keybuk: I have to check the code if /3/8 is also supported | 06:07 |
| pitti | but since /proc/bus/usb always had three digits, that's what libusb currently looks for | 06:07 |
| Keybuk | cause I think that's how Debian named them (which I thought was a bug, so I prematurely fixed it just in case) | 06:07 |
| Keybuk | oooooh | 06:10 |
| Keybuk | my system has booted | 06:10 |
| pitti | Keybuk: 'k, /dev/bus/usb/3/9 works as well | 06:10 |
| Keybuk | pitti: ah, so it looks for both? | 06:10 |
| pitti | yes | 06:10 |
| Keybuk | which does it "prefer", looking at the code? | 06:10 |
| pitti | Keybuk: whatever comes first in asciibetical order | 06:10 |
| pitti | i. e. 00x, I suppose | 06:11 |
| Keybuk | oh right | 06:11 |
| pitti | oh, wait, that was a lie | 06:11 |
| pitti | it doesn't sort | 06:11 |
| pitti | so, whatever readdir() delivers first | 06:11 |
| pitti | not that it would matter so much | 06:11 |
| Keybuk | I mean which of /dev/bus/xxx/yyy, /dev/bus/x/y, /proc/bus/xxx/yyy does it look for first? | 06:12 |
| pitti | Keybuk: /dev is prefered over /proc, which is sane | 06:12 |
| pitti | Keybuk: the first two are indetermined | 06:12 |
| Keybuk | ok | 06:12 |
| pitti | Keybuk: it just walks the directory with readdir() | 06:12 |
| pitti | but that's fine AFAICS | 06:12 |
| Keybuk | oh, so it doesn't actually build the path? | 06:13 |
| pitti | the important part is /dev > /proc | 06:13 |
| Keybuk | right | 06:13 |
| Keybuk | so I now have 5 bugs | 06:13 |
| Keybuk | 1) ide-generic isn't loaded, so needs to be somehow | 06:14 |
| Keybuk | 2) /lib/udev/ide_media gets passed the wrong thing | 06:14 |
| Keybuk | 3) a typo in a rules file | 06:14 |
| Keybuk | 4) framebuffers need blacklisting | 06:14 |
| Keybuk | and | 06:14 |
| Keybuk | 5) kernel still panics | 06:14 |
| Keybuk | interestingly it did #5 quite a way down the boot sequence, when hal started | 06:19 |
| Keybuk | so maybe iz sysfs bug | 06:19 |
| Keybuk | jbailey: ping? | 06:26 |
| jbailey | Keybuk: pong | 06:26 |
| Keybuk | we utterly only support built-in IDE controllers or PCI IDE controllers, right? | 06:26 |
| Keybuk | or does ide-generic activate anything that the PCI walk didn't? | 06:27 |
| Keybuk | ie. should I put "modprobe ide-generic" in a udev rule if we find a PCI IDE controller, or does it need to be out of the main sequence? | 06:27 |
| Keybuk | hmm, deathly silence | 06:31 |
| jbailey | ide-generic should activate pretty much everything else that listens at the right addresses. | 06:34 |
| Keybuk | ok | 06:34 |
| jbailey | We added it in to support random embedded things and other bits that don't have the right chips. | 06:34 |
| Keybuk | the trouble is that a "modprobe ide-generic" won't wait | 06:35 |
| Keybuk | (for /dev/hda and stuff to appear) | 06:35 |
| Keybuk | right | 06:41 |
| Keybuk | modprobe -q ide-generic | 06:41 |
| Keybuk | udevstart -W | 06:41 |
| Keybuk | :) | 06:41 |
| Keybuk | uh s/udevstart/udevplug/ | 06:41 |
| jbailey | LOL | 06:44 |
| Keybuk | hmm, so I noticed one bug with leaving udevd running until the real filesystem | 06:44 |
| Keybuk | we move /dev out of the way :) | 06:44 |
| jbailey | The idea was to cd /dev first. | 07:17 |
| jbailey | Should solve that, no? | 07:17 |
| Keybuk | no, because it would still try and mknod /dev/foo | 07:36 |
| Keybuk | is ok though | 07:50 |
| Keybuk | if we kill it just before we exec init, and start it straight after, that's pretty short | 07:50 |
| Keybuk | we don't need it for exec init ... that's way after mountroot | 07:50 |
| === Mithrandir [n=tfheen@c5100BC63.inet.catch.no] has joined #ubuntu-boot | ||
| Mithrandir | hiya | 09:23 |
| Keybuk | heyhey | 09:26 |
| Mithrandir | jbailey: you pung? | 09:26 |
| jbailey | Mithrandir: Scott wanted to know about i2o | 09:26 |
| jbailey | Mithrandir: Since you've actually touched one, I was hoping you could answer better than I. | 09:26 |
| Keybuk | no, I just wanted to know how dead I'd be if I didn't broke it on boot ;) | 09:26 |
| Mithrandir | sure, what's the question? | 09:26 |
| Keybuk | uh, PROBE it on boot | 09:26 |
| Keybuk | hello, freud | 09:26 |
| Mithrandir | Keybuk: well, the system would be completely unbootable. | 09:27 |
| Keybuk | that's pretty much what I wanted to know | 09:27 |
| Keybuk | i2o controllers are PCI storage controllers? | 09:27 |
| jbailey | Keybuk: I don't know what Norweigians do when they're angry, but that's what you'd have to deal with. | 09:27 |
| Mithrandir | unless one, for some insane reason has / on something non-i2o, that is. | 09:27 |
| jbailey | Tax you, or something. | 09:27 |
| Keybuk | jbailey: Tollef bites | 09:27 |
| Mithrandir | I also slap people with x40s | 09:27 |
| Keybuk | Mithrandir: like IDE or SCSI? | 09:28 |
| Keybuk | ... with their X40 | 09:28 |
| Mithrandir | yes, but why would you do that if you have an I2O controller? | 09:28 |
| Keybuk | I don't know what an i2o controller is | 09:28 |
| Keybuk | I've never seen one before | 09:28 |
| === Keybuk wonders what his amd64 will have | ||
| jbailey | Mithrandir: That's the part you can fill in that I can't. =) | 09:28 |
| Keybuk | SATA I think | 09:28 |
| jbailey | Keybuk: sata, probably. =) | 09:28 |
| Mithrandir | it's a disk controller, most often SCSI on the disk interface, but can be anything. | 09:28 |
| jbailey | Mithrandir: Aren't there i2o nics too? | 09:28 |
| Mithrandir | i2o is a standardised interface, so you only have to have one driver for all kinds of hardware | 09:29 |
| Mithrandir | jbailey: possibly. | 09:29 |
| Keybuk | ah, yes | 09:29 |
| Keybuk | another standardised interface | 09:29 |
| Keybuk | the nice thing about those is there are so many of them | 09:29 |
| Keybuk | you just need one driver for each bloody standardised interface | 09:29 |
| Mithrandir | yes :-) | 09:29 |
| Keybuk | ok | 09:29 |
| Mithrandir | it's like if you had a single SCSI card adapter which worked for all scsi cards, though. | 09:30 |
| Keybuk | I'll leave -Bi2o in then | 09:30 |
| Keybuk | not that should actually have anything on it at that point | 09:30 |
| Keybuk | that probe is for stuff that got loaded *before* we probed the PCI bus for storage controllers | 09:30 |
| Keybuk | usually "elmo woz ere" type things | 09:30 |
| jbailey | Mithrandir: (and then couldn't find any scsi cards) | 09:30 |
| Mithrandir | s/adapter/driver/, though | 09:31 |
| Mithrandir | Keybuk: also, devices show up in /dev/i2o/hdX and not as /dev/hdX. | 09:31 |
| Keybuk | do they? | 09:33 |
| Keybuk | O:-) | 09:33 |
| Keybuk | perhaps you should rephrase that | 09:33 |
| Keybuk | maybe "could you make the devices show up in /dev/i2o" ... :) | 09:33 |
| Mithrandir | they should show up as /dev/i2o/hdX, not /dev/hdX. :-P | 09:34 |
| Keybuk | should they? | 09:34 |
| Mithrandir | that's what all the docs say, that's what the kernel default is and so on, so yes, I absolutely think so. | 09:34 |
| Keybuk | there isn't a kernel default | 09:34 |
| Keybuk | hmm | 09:34 |
| Mithrandir | MAKEDEV default, then | 09:34 |
| Mithrandir | unless you have a good reason for them to show up somewhere else. | 09:34 |
| Keybuk | there isn't a rule for that in current udev.rules ... so how does that work? | 09:35 |
| Keybuk | *shrug* | 09:35 |
| Keybuk | I guess it just does | 09:35 |
| Keybuk | kernel probably does something sick like DEVNAME=i2o/hdX | 09:35 |
| Mithrandir | on my i2o box (which runs hoary), I have both /dev/i2o_hda and /dev/i2o/hda | 09:36 |
| Keybuk | kooky | 09:36 |
| Mithrandir | (as well as i2o_hda1, i2o/hda1, etc) | 09:36 |
| Mithrandir | yeah, I think just i2o/hdX is good | 09:37 |
| Keybuk | could you do a udevinfo -q all -n /dev/i2o_hda | 09:37 |
| Keybuk | and udevinfo -q all -n /dev/i2o/hda | 09:37 |
| Mithrandir | : tfheen@my ~ > udevinfo -q all -n /dev/i2o_hda | 09:37 |
| Mithrandir | device not found in database | 09:37 |
| Mithrandir | : tfheen@my ~ > udevinfo -q all -n /dev/i2o/hda | 09:37 |
| Mithrandir | P: /block/i2o!hda | 09:37 |
| Mithrandir | N: i2o/hda | 09:37 |
| Mithrandir | S: | 09:37 |
| Mithrandir | : tfheen@my ~ > | 09:37 |
| Mithrandir | blank line after the S: | 09:37 |
| Keybuk | udevinfo -a -p '/block/i2o!hda' | 09:38 |
| Mithrandir | loads | 09:40 |
| Mithrandir | http://pastebin.com/437435 | 09:40 |
| Keybuk | interesting | 09:43 |
| Keybuk | well, I guess it works | 09:46 |
| Keybuk | unlike my IDE controller *sigh* | 09:46 |
| Mithrandir | I'm going to get that particular machine available for testing in a few days, so I can do any kinds of testing you want. | 09:46 |
| Mithrandir | it's probably going back into production in not too long, though, as it's a dual 250 and we like to keep those busy. | 09:46 |
| Keybuk | *nods* | 09:47 |
| Mithrandir | does that mean "please tell me when you've installed dapper on it and what breaks"? | 09:57 |
| Keybuk | yup | 09:57 |
| Keybuk | pretty much | 09:57 |
| Mithrandir | it'll be easy for me to give out access to the box when it's reinstalled, if you're interested. | 09:58 |
| Keybuk | sounds good | 09:58 |
| Keybuk | theoretically it should all be fine though | 09:59 |
| Keybuk | I can't see any special handling for i2o in Debian or SuSE's rules | 09:59 |
| Mithrandir | yeah, and in theory theory and practice are equal. | 09:59 |
| Keybuk | which probably means it was written a not-too-insane man | 09:59 |
| Keybuk | and the kernel actually knows how to drive it | 09:59 |
| Mithrandir | the original driver was written by a Mr. Cox. | 09:59 |
| Mithrandir | you might have heard of him. | 09:59 |
| Keybuk | indeed | 10:00 |
| Mithrandir | he's probably insane, but in the good sense of the word. | 10:00 |
| Keybuk | :o) | 10:00 |
| === ..[topic/#ubuntu-boot:Keybuk] : http://people.ubuntu.com/~scott/bootcharts/dapper-20051124-1.png | ||
| === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-boot | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
