#ubuntu-boot 2005-11-28 * ..[topic/#ubuntu-boot:fabbione] : http://lwn.net/Articles/159360/ <makx> jbailey: mentors has something for you. :) <jbailey> Lovely. <jbailey> klibc or initramfs? <makx> initramfs <makx> klibc is atm hindered by waldi <jbailey> Oh? <makx> well he removed the asm symlink in linux-headers-2.6.14 <makx> svenl and trave11er jumped onto the floar and said that i should use linux-kernel-headers <makx> i said that i know that and asked for a patch. <makx> none of which happened. <jbailey> Oh, is that why svenl has been talking about that on debian-glibc <jbailey> I think a patch is almost on its way. <makx> ooh cool #ubuntu-boot 2005-11-29 <fabbione> Keybuk: you got your ubuntulog <Keybuk> thanks <fabbione> Keybuk: anyway the best is to just send me a mail <fabbione> becuase the bot is like -20 in my priority list :) <Keybuk> is that nice -20, or ... ? :p <fabbione> ehhe <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 <makx> ubuntu is behind atm. <Keybuk> fsvo "behind" <Keybuk> all the changes in your 039 are irrelevant for ubuntu <makx> we have changes jbailey ok'ed but didn't want to push yet for breezy <Keybuk> and replaced by those in our 040, which won't work for Debian <Keybuk> (or whatever version we use for it) <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. <infinity> So, pick a version number at random, and make sure it has "ubuntu" in the name, and we'll sort it later. :/ <Keybuk> infinity: ok * 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. :) <Keybuk> am doing my changes right now :) so the lock will be released once these are done and uploaded <makx> you still don't have a manpage for update-initramfs <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 ? <makx> Keybuk: yes <makx> we already have an hooks/udev <makx> inifinity: please tell what is utter crack? <infinity> Keybuk : That would be beyond fine. <infinity> Keybuk : In fact, that's what we SHOULD be doing. <infinity> Keybuk : The less package-specific cruft we have in initramfs, the better. <infinity> Keybuk : If that approach can be done in both Debian and Ubuntu, our diffs may get very small again. <Keybuk> ok, because scripts/init-top/udev makes a lot of sense to me <Keybuk> along with hooks/udev to copy over things <infinity> (Which is one motivation for making it work that way) <Keybuk> and ship those in udev itself, rather than in initramfs-tools <infinity> makx : Nothing is "utter crack" so much as stuff that should be discussed. I was being overly dramatic for effect. :) <infinity> Keybuk : Yes please. <makx> infinity: evms will move to it's package what else is bad? <infinity> evms was one, yes. <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. <infinity> The more initramfs is kept as a flexible framework with very little actual "content", the better. <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 <infinity> I'm also wondering at what stage we should declare klibc a failed experiment, and just use glibc everywhere. <makx> do we have everything in busybox? <Keybuk> infinity: the klibc utilities are useful, but that's it <infinity> Keybuk : What does klibc ship that we couldn't get from turning on some busybox options? <infinity> (or building a few tiny binaries of our own, linked against glibc) <makx> would help a lot on Debian, klibc isn't ready for quite some archs <Keybuk> infinity: no idea, the binaries that come with klibc are tiny <Keybuk> we could just copy anything there we didn't have in busybox <Keybuk> run-init is probably the main one ;) <infinity> Reimplementing without klibc (whether or not we decide to use that branch) is definitely on my lis tof things to do. <infinity> So we'll see where that goes. <infinity> Right now, I should get back to making X build. * infinity shakes his lauren32@example.com. <infinity> If yo ukeep fixing my bugs, I'll have to keep fixing Daniel's bugs, and the world will go all topsy-turvy! <Keybuk> who's bugs is daniels fixing? <infinity> See, that may be where it all falls apart. <Keybuk> and who is fixing my bugs? <Keybuk> infinity: hmm, do we want firmware in the initramfs or not? <fabbione> Keybuk: no, you don't <fabbione> otherwise initramfs will explode <Keybuk> what if they want an nfsroot on a network card that needs firmware? <fabbione> Keybuk: tough luck... some initramfs are already too big <fabbione> and netboot on some machines is broken for that <infinity> Well, PXE on wireless is never going to happen, but do we have wired cards that require firmware to go? <fabbione> only wireless <fabbione> afaik <infinity> fabbione : firmware wouldn't explode the initramfs. Most firmware is way smaller than the driver it goes with. <fabbione> infinity: we are already fighting with oversize.. we need to put initramfs on a heavy diet <infinity> But, if we only ship firmware for wireless, it's not much of a win to have it in the initramfs IMO. <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. <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) <fabbione> infinity: ppc can't netboot.. it has been decided already :) <fabbione> starting from the amount of drivers will be in the udeb and so on... <Keybuk> Kamion: ping? <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 ;) <Kamion> it's nice to be able to 'mount /proc' without having to remember the arguments <Kamion> but file a bug on partman-target with rationale as to why it's actively bad to have it there <Keybuk> it's not so much actively bad, as misleading <Keybuk> it's never used by the main boot, so gives users the illusion that they can change it there and have some effect <Keybuk> and as /sys and /dev aren't alongside it, it looks strange <Kamion> need to also check that stuff in d-i doesn't rely on it <Kamion> (obviously it would be easy to change) <jbailey> Keybuk: wireless nfsroot will probably want firmware. <jbailey> fabbione: ppc can suck raw eggs. =) What we did in Debian for initrd was to set ppc to dep and not the others. <fabbione> dep? <fabbione> dude.. i have a ppc <fabbione> and i use netboot <fabbione> initramfs must work <fabbione> or i am going to make an offer this channel can't refure <fabbione> refuse even <jbailey> So set your initramfs generator to dep mode. <jbailey> Just because that arch is broken doesn't mean the others need to be penalised against a very useful use case. <fabbione> i still need to figure who does root over wireless <makx> jbailey: please upload latest initramfs-tools :) <jbailey> makx: I'd prefer in general that 'sync with ubuntu' contained some level of details. * jbailey builds. <jbailey> It's not that important since Ubuntu is upstream for you. <jbailey> But since that's the only changelog file, you're actually dropping information there. <jbailey> There's no way to trace what's changed without a debdiff. <jbailey> makx: Uploaded. <Keybuk> I'm confused, why can't ppc netboot? why does it have a maximum ramfs size? <fabbione> Keybuk: for some reasons OF can't load a file bigger than 6MB via tftp <Keybuk> sounds like a bug that can be fixed <Keybuk> just load the initramfs in 6MB chunks <jbailey> Keybuk: There seems to be a discussion about hostnames on the u-d. Didn't we solve this problem at ubz? <jbailey> ISTR you or someone asking about it. <Keybuk> no? <Keybuk> wasn't me <jbailey> Hmm <jbailey> Colin's apparently enabled hostname now which makes it harder to get rid of busybox if we want to at some point. <Keybuk> do we want to get rid of busybox? <infinity> I don't. busybox is love. <Keybuk> in busybox vs. klibc-utils, I err towards busybox IF we can get it to stop forking for its built-ins :) <infinity> Jeff is a purist, however, who thinks that eventually we can implement the whole thing as ed scripts. <jbailey> Keybuk: My idealist version is that it should be possibly to disable it and get a 20k initramfs in dep mode. =) <jbailey> possible, rather. <Keybuk> what shell would you use ? <Keybuk> and udev alone is about 150-200K <jbailey> Is it that big now? <jbailey> Hmm <jbailey> Okay, 100k then. <jbailey> initramfs' are gzip'd. <jbailey> Keybuk: There's no reason for things in there not to be ash friendly. <Keybuk> udevd is 55K, udevplug is 28K <Keybuk> all of the little helpers are about 240K together <Kamion> jbailey: harder to get rid of busybox> I don't understand how me enabling hostname makes it any harder? <Kamion> and busybox' shell *is* ash, near enough <infinity> You jus tgave us one more crutch? <Kamion> true <infinity> Not that I mind, terribly. <pitti> Keybuk: can we recognize ditital cameras by a device type argument, or do we need usermaps, just as with scanners? <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. <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. <infinity> I'm not sure there is much value in trying to make it tiny. <infinity> Making it not HUGE is good, but I dunno how tiny it needs to be. <Keybuk> pitti: where there's a usermap now, there's probably a good reason <infinity> Poeple booting from network and flash don't do it often enough to care about a few extra seconds' boot time. <Keybuk> you can do class-matching with the existing usermaps <infinity> (At least, they shouldn't be) <Keybuk> so I figure if they could, they would have <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. <pitti> Keybuk: ok, so I'm going to merge libgphoto2 for now (just wanted to ask whether it woudd be a complete waste) <infinity> jbailey : I'd argue that our bug lies elsewhere, then, that read speed is inexcusable. <jbailey> infinity: Limitation of pc bios. No dma, sucky short reads. <jbailey> That's why it's not a lauren32@example.com. <infinity> (And why are embedded device folk running Ubuntu kernels and bloated initrds anyway?) <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 <jbailey> infinity: CF != embedded in every case. <pitti> Keybuk: ok; Debian's libgphoto generates its own udev rules from the usermap ATM <jbailey> infinity: It can be thinclient as well. <pitti> Keybuk: that certainly works, but we might be able to speed it up with grepmap <Keybuk> pitti: exactly, I think we should stick with the usermap simply because the conversion sucks <pitti> Keybuk: oh, it would be a conversion in the other way <Keybuk> how do you mean? <pitti> Keybuk: the former print-usb-usermap (which generated the usermap) now changed syntax to look like udev rules <pitti> Keybuk: of course we can revert to the older version for that <Keybuk> oh right, what's the source of that? <Keybuk> ie. where does it get the ids <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... * 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 <Kamion> yenta_socket should be handled automatically now <Keybuk> Kamion: is there an event you can load them on? <Kamion> Keybuk: hard to tell - all my machines are yenta AFAIK <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. <infinity> (monolithic kernels, whatever) <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 <Keybuk> Kamion: grep for them in modules.alias <Kamion> Keybuk: I did; i82365 at least isn't there <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. <Kamion> nor is tcic <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. <Keybuk> Kamion: a lot of the non-yenta bridges are ISA or equally antiquated, aren't they? <infinity> jbailey : Which one report claimed didn't work. <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 <Kamion> i82092 is PCI <Kamion> (and in modules.alias) <Keybuk> the ISA ones are a bitch, because there's no way to detect them except with a stick <Keybuk> and some machines (usually Dells) don't like being poked with a stick <pitti> Keybuk: sorry, got distracted; I think the conversion tool parses it out of the C source <Keybuk> pitti: ok, use the existing conversion tool then :) I thought you meant they had a tool to convert usermaps into udev.rules <Keybuk> so for gphoto, we should use udev.rules and write them to /etc/udev/rules.d/85-gphoto.rules <Keybuk> what does libsane do? <pitti> Keybuk: for gphoto that's exactly how Debian does it now <pitti> Keybuk: are the udev rules pre-parsed into memory structures, or are the text files parsed every time? <Keybuk> pre-parsed now <pitti> Keybuk: OTOH, udev parsing shouldn't be that much slower than grepmap, or is it? <Keybuk> note that the order matters, and our ordering is different to Debian's, so the filename might need to be different <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 <Keybuk> Kamion: ok, we could steal that I guess <Kamion> yeah, I think what I'll do is write /lib/udev/pcmciautils that reads /etc/default/pcmcia and loads the module <makx> jbailey: thanks! :) <Kamion> and attach that to pcmcia_socket add <Keybuk> what adds pcmcia_socket ? <Keybuk> if the helper could output a list of modules, you can use a rule like: PROGRAM="/lib/udev/pcmciautils", RUN+="/sbin/modprobe $result" <Keybuk> and make the helper exit 1 if there aren't modules <Keybuk> that's then consistent with the other things that do exactly that <pitti> Keybuk: Debian uses udev rule symlink 25_* (gphoto); so 85 is ok for us? <Keybuk> 85-gphoto.rules file is what we should have <Keybuk> hmm <Keybuk> hang on <Keybuk> what do these rules do, just assign permissions? <Keybuk> can you paste one? <Kamion> Keybuk: what adds pcmcia_socket> cs.c, I think, in an __init <Keybuk> right, so how does that get loaded? <Keybuk> pitti: so, yeah, paste a rule example couldya for gphoto? <pitti> Keybuk: I didn't continue the merge during the meeting, gimme some minutes <Keybuk> :( <Keybuk> I guess I could just steal the debian package and peek <g> <Keybuk> pitti: so, these rules are really sucky <Keybuk> could I suggest a _little_ tweak :) <Kamion> Keybuk: it's part of pcmcia_core; good question exactly what loads that first <pitti> sure <Keybuk> right now it generates something that looks like ... <Keybuk> BUS!="usb", ACTION!="add", GOTO="libgphoto2_rules_end" <Keybuk> : rules here <Kamion> for PCI systems it'll be coldplugged as usual, since the world depends on it <Keybuk> LABEL="libgphoto2_rules_end" <Keybuk> so that has a problem already <Keybuk> you can't do BUS!= :) <Keybuk> change that to be SUBSYSTEM!="usb_device" <Keybuk> then the rules themselves, they look like <pitti> BUS != 'usb' looks a bit odd anyway? <Keybuk> SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", RUN+="/etc/hotplug/usb/usbcam" <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 <Keybuk> pitti: it's skipping the rules for anything not a usb add event <Kamion> I was hoping not to need an init script ... <pitti> ah, ok <Keybuk> and the script just assigns permissions to things <Keybuk> which is a bit doofus <Keybuk> so.... <Keybuk> could we change the output to be something like <pitti> set the permissoins right away, yes <Keybuk> SUBSYSTEM!="usb_device", GOTO="libgphoto2_rules_end" <Keybuk> SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", GROUP="plugdev", MODE="0660" <Keybuk> LABEL="libgphoto2_rules_end" <pitti> yes, that looks better <Keybuk> (and yes, I deliberately dropped the ACTION!=add thing) <pitti> I'll modify print-udev-rules-bla.c accordingly <Keybuk> then write the file as /etc/udev/rules.d/45-gphoto.rules <Keybuk> (45 not 85 so it doesn't get included in initramfs) <pitti> ok, sure <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 <Keybuk> initramfs doesn't have permissions, symlinks or programs ... so gets 0-39 and 90+ * jbailey removes 'initramfs' from his nick highlight list. <Keybuk> now, I shall make tea <Keybuk> then I shall get my laptop booting again, after I foolishly forgot to put udev.conf in the initramfs <g> <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 <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 <Keybuk> yeah, I don't think there is a way to do it with udev <Keybuk> udev reacts to events, if there's no event to react to, there's no way to do it <Keybuk> udev will correctly react to the modprobe, of course, so all you need to do is _start_ it <Keybuk> for most devices, the thing that starts stuff is udevplug, which walks sysfs and tickles everything the kernel's found so far <Keybuk> but if the kernel hasn't found legacy pcmcia buses, there needs to be a manual stick <Kamion> all the init script does is modprobe pcmcia_core, then if there's no /sys/class/pcmcia_socket/* yet modprobe $PCIC <Kamion> basically <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..) <Kamion> jbailey: it does, but only for PCI bridges <Keybuk> jbailey: it has been <Kamion> then once the bridge is up, the rest is a regular hotpluggable bus <Keybuk> jbailey: you still need something to modprobe the drivers for the old ISA pcmcia bridges though <jbailey> Ah, okay. <Keybuk> Kamion: ok ... beware that the /sys thing won't turn up straight away <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 <Keybuk> right <Kamion> and fixed it to detect i82092 as well, which is the only other PCI bridge I can see <Keybuk> that stuff's probably needless now <Keybuk> if there's a /sys/bus/pci/devices/*/class that's a yenta bridge, then yenta_socket will be loaded <Kamion> yeah, just a sanity-check to make sure we don't accidentally probe the wrong bridge <Keybuk> and you'll have /sys/bus/pcmcia <Keybuk> *nods* <Kamion> because apparently /etc/default/pcmcia is sometimes broken on old upgrades and says i82365 when it isn't <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 <Keybuk> ok, fixed udevplug bug, time for manual boot #3 <Keybuk> ugh @ /sbin/udevplug -Bide -Bscsi -Bi2o -Busb -Bieee1394 /class/mem /class/misc /class/tty /class/vc /block <Keybuk> I'm so aliasing that to /sbin/udevplug --whatever-initramfs-needs <Keybuk> anyone know what the serio, eisa or MCA buses are? <HiddenWolf> eisa is/was a competitor to ps/2 <jbailey> eisa was an extended isa bus. <jbailey> Supported some autoconfiguration, and a slightly wider bus path. <jbailey> The sockets could also take isa cards. <Keybuk> jbailey: anything on any of those we might need for initramfs? <Keybuk> ie. storage or hid controllers? <HiddenWolf> hm <jbailey> Keybuk: EISA *might* actually be autodetectable enough for initramfs. <Keybuk> /sys/bus/eisa/devices is empty on my system (at least on initial startup) <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, <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) <Keybuk> /sys/bus/MCA has turned up in 2.6.15 ... I think it wants to shout <jbailey> MCA is overloaded. <jbailey> Clasic MCA was a PS/2 architecture with autodetection. <Keybuk> I'll leave them out until someone bitches <jbailey> I think it's now something else. <Keybuk> we're already poking enough as it is <jbailey> I maintainer my argument that we don't actually care about anything pre-PCI for booting. =) <jbailey> maintain, rather =) <jbailey> Anything that old won't run gnome in any useful way. <Keybuk> what's i2o? <Keybuk> you put that in the spec when I wasn't looking <jbailey> It's a bus standard that was suppose to feature standarized drivers for high end hardware. <jbailey> I've never actually had one. Tollef has, though. <Keybuk> does it have root filesystems on it? <jbailey> It does on his box. <jbailey> initramfs-tools theoretically supports it in Breezy. <Keybuk> ok <Keybuk> # /sbin/udevplug -Bide <Keybuk> udevplug[4499] : scan_bus: unable to open bus 'ide' <Keybuk> \o/ <Keybuk> same thing for scsi, i2o, usb and ieee1394 <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) <Keybuk> hmm, is it really /sys/bus/ieee1394 ? I haven't got one <jbailey> jbailey@starshine:/sys/bus$ ls <jbailey> i2c ide ieee1394 macio of_platform pci pcmcia platform scsi usb vio <Keybuk> i2c ? is that different to i2o? <Keybuk> macio? vio? WHO INVENTED ALL THESE THINGS?! :) <Keybuk> my laptop has a /sys/bus/pci_express ... wonder whether we should look for controllers on that <jbailey> I think i2c is different, yes. <jbailey> I don't know how, though. <jbailey> jbailey@starshine:/sys/bus/i2c/drivers$ ls <jbailey> i2c_adapter PMac Keywest Audio therm_pm72 <Keybuk> I2C (pronounce: I squared C) is a protocol developed by Philips. It is a <Keybuk> slow two-wire protocol (10-400 kHz), but it suffices for many types of <Keybuk> devices. <Keybuk> oh <Keybuk> it's the fan-speed thing <pitti> Keybuk: hey, look at that nice rule: <Kamion> macio and vio are similar-ish I think - at least, vio uses /proc/device-tree too <pitti> # USB PTP Class Camera <pitti> SYSFS{bDeviceClass}=="06", GROUP="plugdev", MODE="0660" <pitti> Keybuk: ^ *that*'s what rules should look like :) <Keybuk> pitti: yeah, that one should work for a lot of things -- provided it's within a SUBSYSTEM!="usb_device", GOTO="..." thing <Kamion> Keybuk: fan speed, some Mac sound devices, random other stuff on Macs too <pitti> Keybuk: yes, it is, I did the conversion <Keybuk> kewl <Keybuk> right, now for the biiig test <pitti> crw-rw---- 1 root plugdev 189, 260 2005-11-24 17:25 /dev/usbdev3.5 <Keybuk> does /sbin/udevplug -Bpci -Iclass=0x010[01] * do the right thing? <Keybuk> hmm <Keybuk> that caused ide_core, alim15x3 and generic to be loaded <Keybuk> but, pointedly, no /dev/hda to appear <Keybuk> grr <pitti> Keybuk: now I'll try to convince libgphoto to actually talk to /dev/usbdev3.5 instead of /proc/bus/usb/003/004 <pitti> s/4$/5/ <Keybuk> pitti: it'll be /dev/bus/usb/003/004 with our naming rules <Keybuk> so you should just replace /proc with /dev <pitti> Keybuk: oh, ok, right now it's like above <pitti> but if that works in general, that should be fine <Keybuk> yeah, that's the "kernel-assigned" name for those devices <Keybuk> which is a bit boring <Keybuk> hmm <Keybuk> ok <Keybuk> /dev/hda, oh /dev/hda, wherefor art thou /dev/hda? <Keybuk> jbailey: ok, I'm clearly being stupid ... what provides those devices? <jbailey> Keybuk: Eh? It's in /sys/block <jbailey> What do you mean by what provides? <Keybuk> well <Keybuk> what module do I need to load? <Keybuk> they're not in /sys/block yet, because I haven't loaded the right module <jbailey> Oh <jbailey> your specific ide module <jbailey> ide-disk <jbailey> ide-generic <Keybuk> ok... so how do I know to load ide-disk? :P <jbailey> ide-generic must be last. <jbailey> You have to walk /proc/ide to get the info on each device. <Keybuk> no devices there yet ... you see <Keybuk> just /proc/ide/drivers <Keybuk> ohhh <Keybuk> I see the problem <jbailey> Right, but when you load cmd64x or whatever. <Keybuk> wtf is "generic" <jbailey> It'll be there. <Keybuk> not "ide-generic", "generic" <jbailey> Did they rename it? <Keybuk> no... <jbailey> And ide-generic doesn't have to be last, sorry, just has to be after any specific IDE drivers you want. <jbailey> But then /proc/ide will exist. <Keybuk> generic is what got loaded (along with ide-core and the specific module) when I walked the PCI bus <Keybuk> not ide-generic <jbailey> Ah. <jbailey> No idea what "generic" is. <jbailey> description=PCI driver module for generic PCI IDE <Keybuk> right, very odd <Keybuk> ok, so I need a rule in here somewhere to load ide-generic ... wonder how I'm going to shimmy that <pitti> Keybuk: how practical - our current libusb already checks for /dev/bus/usb before /proc/bus/usb :) <pitti> Keybuk: so I only need to teach it about /dev/usbdevX.Y <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 <Kamion> I'll look at those later <Keybuk> pitti: you probably don't need to do that <Keybuk> nobody is shipping without the /dev/bus/usb rules that I'm aware of <pitti> Keybuk: I could wait with the gphoto upload until you upload udev <pitti> Keybuk: we do at the moment :) <Keybuk> well, no, we don't TECHNICALLY :p <Keybuk> yeah, I'd wait and not support usbdevX.Y <Keybuk> hmm <pitti> Keybuk: ok, for testing I just modify my local udev rules, I guess <Keybuk> didn't we blacklist all of the framebuffer devices? <Keybuk> ahh <Keybuk> no <Keybuk> the old hotplug pci.agent just skipped them <Keybuk> hmm <Keybuk> udevplug doesn't do that, of course <Keybuk> I wonder whether there's some modprobe.d trick we can use to blacklist an entire class <pitti> Keybuk: yay, a symlink works nicely, great; thanks for your help <Keybuk> pitti: symlink? <pitti> Keybuk: /dev/bus/usb/003/008 -> /dev/usbdev3.8, just for testing <Keybuk> ahh <pitti> Keybuk: that's how your udev will create the devs? <Keybuk> it'll rename them <Keybuk> there won't be a /dev/usbdev3.8 <Keybuk> (ie. it uses NAME= not SYMLINK+=) <pitti> Keybuk: I mean /dev/bus/usb/xxx/yyy <Keybuk> oh <Keybuk> right <Keybuk> yes <pitti> ok, cool <pitti> then everything is settled <Keybuk> is that what gphoto actually looks for? it's not looking for /dev/bus/usb/3/8 ? <pitti> libsane uses libgphoto-port0, which uses libusb, which is prepared for your udev <pitti> Keybuk: I have to check the code if /3/8 is also supported <pitti> but since /proc/bus/usb always had three digits, that's what libusb currently looks for <Keybuk> cause I think that's how Debian named them (which I thought was a bug, so I prematurely fixed it just in case) <Keybuk> oooooh <Keybuk> my system has booted <pitti> Keybuk: 'k, /dev/bus/usb/3/9 works as well <Keybuk> pitti: ah, so it looks for both? <pitti> yes <Keybuk> which does it "prefer", looking at the code? <pitti> Keybuk: whatever comes first in asciibetical order <pitti> i. e. 00x, I suppose <Keybuk> oh right <pitti> oh, wait, that was a lie <pitti> it doesn't sort <pitti> so, whatever readdir() delivers first <pitti> not that it would matter so much <Keybuk> I mean which of /dev/bus/xxx/yyy, /dev/bus/x/y, /proc/bus/xxx/yyy does it look for first? <pitti> Keybuk: /dev is prefered over /proc, which is sane <pitti> Keybuk: the first two are indetermined <Keybuk> ok <pitti> Keybuk: it just walks the directory with readdir() <pitti> but that's fine AFAICS <Keybuk> oh, so it doesn't actually build the path? <pitti> the important part is /dev > /proc <Keybuk> right <Keybuk> so I now have 5 bugs <Keybuk> 1) ide-generic isn't loaded, so needs to be somehow <Keybuk> 2) /lib/udev/ide_media gets passed the wrong thing <Keybuk> 3) a typo in a rules file <Keybuk> 4) framebuffers need blacklisting <Keybuk> and <Keybuk> 5) kernel still panics <Keybuk> interestingly it did #5 quite a way down the boot sequence, when hal started <Keybuk> so maybe iz sysfs bug <Keybuk> jbailey: ping? <jbailey> Keybuk: pong <Keybuk> we utterly only support built-in IDE controllers or PCI IDE controllers, right? <Keybuk> or does ide-generic activate anything that the PCI walk didn't? <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? <Keybuk> hmm, deathly silence <jbailey> ide-generic should activate pretty much everything else that listens at the right addresses. <Keybuk> ok <jbailey> We added it in to support random embedded things and other bits that don't have the right chips. <Keybuk> the trouble is that a "modprobe ide-generic" won't wait <Keybuk> (for /dev/hda and stuff to appear) <Keybuk> right <Keybuk> modprobe -q ide-generic <Keybuk> udevstart -W <Keybuk> :) <Keybuk> uh s/udevstart/udevplug/ <jbailey> LOL <Keybuk> hmm, so I noticed one bug with leaving udevd running until the real filesystem <Keybuk> we move /dev out of the way :) <jbailey> The idea was to cd /dev first. <jbailey> Should solve that, no? <Keybuk> no, because it would still try and mknod /dev/foo <Keybuk> is ok though <Keybuk> if we kill it just before we exec init, and start it straight after, that's pretty short <Keybuk> we don't need it for exec init ... that's way after mountroot <Mithrandir> hiya <Keybuk> heyhey <Mithrandir> jbailey: you pung? <jbailey> Mithrandir: Scott wanted to know about i2o <jbailey> Mithrandir: Since you've actually touched one, I was hoping you could answer better than I. <Keybuk> no, I just wanted to know how dead I'd be if I didn't broke it on boot ;) <Mithrandir> sure, what's the question? <Keybuk> uh, PROBE it on boot <Keybuk> hello, freud <Mithrandir> Keybuk: well, the system would be completely unbootable. <Keybuk> that's pretty much what I wanted to know <Keybuk> i2o controllers are PCI storage controllers? <jbailey> Keybuk: I don't know what Norweigians do when they're angry, but that's what you'd have to deal with. <Mithrandir> unless one, for some insane reason has / on something non-i2o, that is. <jbailey> Tax you, or something. <Keybuk> jbailey: Tollef bites <Mithrandir> I also slap people with x40s <Keybuk> Mithrandir: like IDE or SCSI? <Keybuk> ... with their X40 <Mithrandir> yes, but why would you do that if you have an I2O controller? <Keybuk> I don't know what an i2o controller is <Keybuk> I've never seen one before * Keybuk wonders what his amd64 will have <jbailey> Mithrandir: That's the part you can fill in that I can't. =) <Keybuk> SATA I think <jbailey> Keybuk: sata, probably. =) <Mithrandir> it's a disk controller, most often SCSI on the disk interface, but can be anything. <jbailey> Mithrandir: Aren't there i2o nics too? <Mithrandir> i2o is a standardised interface, so you only have to have one driver for all kinds of hardware <Mithrandir> jbailey: possibly. <Keybuk> ah, yes <Keybuk> another standardised interface <Keybuk> the nice thing about those is there are so many of them <Keybuk> you just need one driver for each bloody standardised interface <Mithrandir> yes :-) <Keybuk> ok <Mithrandir> it's like if you had a single SCSI card adapter which worked for all scsi cards, though. <Keybuk> I'll leave -Bi2o in then <Keybuk> not that should actually have anything on it at that point <Keybuk> that probe is for stuff that got loaded *before* we probed the PCI bus for storage controllers <Keybuk> usually "elmo woz ere" type things <jbailey> Mithrandir: (and then couldn't find any scsi cards) <Mithrandir> s/adapter/driver/, though <Mithrandir> Keybuk: also, devices show up in /dev/i2o/hdX and not as /dev/hdX. <Keybuk> do they? <Keybuk> O:-) <Keybuk> perhaps you should rephrase that <Keybuk> maybe "could you make the devices show up in /dev/i2o" ... :) <Mithrandir> they should show up as /dev/i2o/hdX, not /dev/hdX. :-P <Keybuk> should they? <Mithrandir> that's what all the docs say, that's what the kernel default is and so on, so yes, I absolutely think so. <Keybuk> there isn't a kernel default <Keybuk> hmm <Mithrandir> MAKEDEV default, then <Mithrandir> unless you have a good reason for them to show up somewhere else. <Keybuk> there isn't a rule for that in current udev.rules ... so how does that work? <Keybuk> *shrug* <Keybuk> I guess it just does <Keybuk> kernel probably does something sick like DEVNAME=i2o/hdX <Mithrandir> on my i2o box (which runs hoary), I have both /dev/i2o_hda and /dev/i2o/hda <Keybuk> kooky <Mithrandir> (as well as i2o_hda1, i2o/hda1, etc) <Mithrandir> yeah, I think just i2o/hdX is good <Keybuk> could you do a udevinfo -q all -n /dev/i2o_hda <Keybuk> and udevinfo -q all -n /dev/i2o/hda <Mithrandir> : tfheen@my ~ > udevinfo -q all -n /dev/i2o_hda <Mithrandir> device not found in database <Mithrandir> : tfheen@my ~ > udevinfo -q all -n /dev/i2o/hda <Mithrandir> P: /block/i2o!hda <Mithrandir> N: i2o/hda <Mithrandir> S: <Mithrandir> : tfheen@my ~ > <Mithrandir> blank line after the S: <Keybuk> udevinfo -a -p '/block/i2o!hda' <Mithrandir> loads <Mithrandir> http://pastebin.com/437435 <Keybuk> interesting <Keybuk> well, I guess it works <Keybuk> unlike my IDE controller *sigh* <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. <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. <Keybuk> *nods* <Mithrandir> does that mean "please tell me when you've installed dapper on it and what breaks"? <Keybuk> yup <Keybuk> pretty much <Mithrandir> it'll be easy for me to give out access to the box when it's reinstalled, if you're interested. <Keybuk> sounds good <Keybuk> theoretically it should all be fine though <Keybuk> I can't see any special handling for i2o in Debian or SuSE's rules <Mithrandir> yeah, and in theory theory and practice are equal. <Keybuk> which probably means it was written a not-too-insane man <Keybuk> and the kernel actually knows how to drive it <Mithrandir> the original driver was written by a Mr. Cox. <Mithrandir> you might have heard of him. <Keybuk> indeed <Mithrandir> he's probably insane, but in the good sense of the word. <Keybuk> :o) * ..[topic/#ubuntu-boot:Keybuk] : http://people.ubuntu.com/~scott/bootcharts/dapper-20051124-1.png #ubuntu-boot 2005-11-30 <HiddenWolf> Keybuk, does that bootchart tell me y'all have managed to halve dapper boot times? <Keybuk> ish <Keybuk> certainly below 1m <infinity> Well, except for the part where there's no GDm there. <infinity> In fact, no runlevel 2 at all, if I'm not mistaken. <Keybuk> yeah, it's just rcS <HiddenWolf> ah <Keybuk> which has dropped from 55s to 39s <HiddenWolf> Hm, still amazing. <Keybuk> yeah, it's a start <Keybuk> there's probably another 10s or so in there <Keybuk> not loading framebuffer drivers should help a bit <Keybuk> and removing networking and pcmcia should too <HiddenWolf> It'd be sweet if things would only start if needed. <HiddenWolf> think hplib. <Keybuk> that starts after gdm <Keybuk> anything that starts after gdm isn't relevant <Keybuk> the game isn't time-until-end-of-rc2 ... but time-until-user-can-login <Keybuk> who cares if hplib and apache don't start until half way through their login? they probably won't <Mithrandir> it should probably be "time until user logged in or system-fully-booted, whichever is longer" <Keybuk> no it shouldn't <Keybuk> I only care up to the point gdm's greeter comes up <Keybuk> after that iz gtk bug :) <Keybuk> Windows plays the same trick, it brings the greeter up as soon as it can while still booting -- it gives the perception of a fast boot <infinity> <nod> <infinity> We need to see a useable GDM as soon as possible. <infinity> Anything beyond that is nice (we don't want to grind for 2 more minutes) but much less critical. <Keybuk> right <Keybuk> once gdm is up, it's all low-hanging <Mithrandir> Keybuk: I care about "machine usable and stuff working", not "shows me pretty junk" <Keybuk> define usable :) <Keybuk> your machine might not be usable until you plug in your pcmcia network card <Keybuk> and if we bootcharted the 5 minutes for you hunting through the crap on your desk, it'd be a loooong time <Keybuk> the best definition I can think of is that the user can do _something_ <Keybuk> ie. get them a greeter or getty as soon as you can <HiddenWolf> Keybuk, how much do you think is realisticly what you can still shave off it? <Keybuk> <----> that much <HiddenWolf> hah, ok. * HiddenWolf lurks on <HiddenWolf> get me <---------> this much, and I'll extend an open invitation to free beer. ;) <Keybuk> beer is over-rated <Mithrandir> beer is good <HiddenWolf> Keybuk, apple-juice for you then. :) <HiddenWolf> Keybuk, with a straw. :) <Keybuk> vodka! <HiddenWolf> Keybuk, Would I have to carry you out in that case? <Keybuk> I'm feeling daring <Keybuk> let's see if I can get to X <Keybuk> cor <Keybuk> I can <Keybuk> I still want to know what that strange sh/run-parts thing is in rcS <Keybuk> ahhhh <Keybuk> it's in a modprobe-post-install rule <HiddenWolf> Keybuk, you're working without X? <Keybuk> I was <Keybuk> I have X now <Keybuk> Kamion: any alarm bells ringing if I suggest making /tmp and /var/run tmpfs? <Kamion> the main problem is partman doesn't know how to do that :P <Keybuk> why does partman need to know? <Kamion> because it sets up fstab ... <Keybuk> virtual filesystems are mounted long before fstab is around :) <Kamion> er <Keybuk> cf. our discussion about the futility of having /proc in there <Kamion> you mean admins don't get to choose? I don't think that's so good <Kamion> my server has problems with /tmp being tmpfs, because (a) various applications I can't be bothered to fix write lots of stuff in there, (b) it's too low on memory for all the stuff they want to write <Keybuk> hmm, I can see the argument for being able to choose /tmp <Kamion> /var/run's probably ok <Keybuk> /var/run is never large, it's just pid files and sockets <Keybuk> (and having it as a tmpfs would solve a major ordering issue I'm currently having <g>) <Kamion> but by the same token I don't see why we need to force it in initramfs either ... oh? <Keybuk> there's a bunch of rcS stuff to clean up /var/run before things are started <Keybuk> but I'd have to move that all into the initramfs in case udev starts the things now <Keybuk> rcS should increasingly become "things udev doesn't do" <Keybuk> I'll have a think and a play with some different ideas, see which works best and doesn't break anything <Kamion> ah, hm <Keybuk> also having it as a tmpfs actually means we can start networking before the real filesystem, which is a current snag <Kamion> we'd have to make sure everything works with /var/run as a tmpfs; IIRC there were a few broken packages that installed files there in .debs or in the postinst <Keybuk> /etc/network/run would become /var/run/network, and all would be happy <Keybuk> Kamion: yeah, I checked main for them, and couldn't immediately see any -- have to check postinst yet though <Keybuk> at the moment I have the problem: <Keybuk> udevplug finds network card <Keybuk> udevd calls ifup <Keybuk> ifup can't write to /etc/network/run/ifstate <Keybuk> (time passes) <Keybuk> root filesystem gets checked and mounted rw <Keybuk> and, of course, if you swap the two... you get <Keybuk> root filesystem can't be chcked because /dev/hda1 doesn't exist <Keybuk> root filesystem remounted rw, and evil error gets shown <Keybuk> udevplug finds block device <Keybuk> udevd creates /dev/hda1 <Keybuk> :) * Kamion uploads ubuntu-meta to suck in new pcmciautils <Keybuk> heh <Kamion> I should probably start running around debian-installer preparing stuff for .15 <Keybuk> I haven't even started the udev udeb stuff yet :-/ <Keybuk> it's just a udeb with a bunch of binaries in <Kamion> <cjwatson@cairhien ~/src/ubuntu/debian-installer/debian-installer-20051026ubuntu3/build>$ wcgrep pcmcia-cs-udeb pkg-lists | wc -l <Kamion> 21 <Kamion> joy <Kamion> just try not to emulate Marco's trick of continually leaving stuff out of the udeb <Keybuk> lol <Keybuk> I guess I'll have to modify hw-detect too <Kamion> hm? what for? <Kamion> oh, udevplug <Keybuk> to make it call the right bits of udev <Kamion> I was planning to move that into rootskel, I'm fed up with running around modifying a billion different pieces <Kamion> tell me what's needed and I'll get it incorporated in the right place <Kamion> just run udevplug? <Keybuk> let me upload our new very-simple udev.init for you, so you can see <Kamion> for udev.init, the plan is for udev-udeb to ship /lib/debian-installer-startup.d/S02udev with whatever it needs to do <Keybuk> http://people.ubuntu.com/~scott/udev.init <Keybuk> basically it's <Keybuk> mount /dev <Keybuk> udevd <Keybuk> cp /lib/udev/devices into /dev <Mithrandir> Keybuk: do you want the udeb bits for bootchart submitted, or should I just upload them? <Keybuk> uidevplug <Keybuk> Mithrandir: just upload them, if they don't touch the ordinary boot stuff <Mithrandir> ok <Mithrandir> they don't. Or shouldn't, at least. <Kamion> Keybuk: take the start bit of that and make it /lib/debian-installer-startup.d/S02udev <Keybuk> ok, that's easy enough then -- without the initramfs stuff, I guess? <Keybuk> can I guarantee that the installer would have 2.6.15 so skip the "abort!abort!abort!" bit? <Kamion> you won't be in initramfs <Keybuk> ok <Kamion> hm, no, best have the error check, stuff is confusing enough at that stage <Keybuk> that's not "in initramfs", there's a check there to make sure that initramfs didn't run on a non-2.6.15 kernel <Keybuk> right <Kamion> well, let me rephrase that. you won't be in initramfs FOR NOW <Keybuk> lol <Kamion> that might change later, but if it does, it'll be initramfs for the whole installer <Keybuk> *blink* <Keybuk> is that "install a system, then exec run-init when done" ? :p <Kamion> nah, just initramfs as an initrd replacement <Keybuk> oh right <Kamion> although I suppose you could :) <Keybuk> thought you had the entire installer in an initramfs there <Keybuk> which would be kinda cute <Keybuk> it's /technically/ "only mounting the root filesystem" ... with the added bonus of making one first * Kamion grins <Keybuk> great for kiosk mode ... they reinstall themselves when they reboot <Kamion> network configuration would be amusing <Kamion> it'd be a bit like tccboot, only more so, especially if you did a gentoo version <Keybuk> you know it'd rock <Keybuk> gentubuntu <Keybuk> I bet jbailey would like it <Keybuk> I swear he wants X in the initramfs <Mithrandir> that'd make X start early enough in the boot, at least. <Mithrandir> can tcc be used to bootstrap gcc? <Keybuk> Google says yeah ... *cough* * Keybuk giggles at vorlon <Keybuk> OMG THIS NEW-FANGLED-SHINY-INIT VIOLATES POLICY! SEVERITY SHALLOW-GRAVE! <Keybuk> "oh, wait, it's sysv-rc ... uh, maybe it's policy's fault" <Kamion> jbailey: please remove that zoneinfo-udeb patch I did from glibc at your next convenience; the installer no longer needs it <Kamion> or tell me and I'll do it <Keybuk> Kamion: do you know what kind of /dev rules we want for d-i? <Keybuk> I guess we want the default naming rules, but do we also want things like /dev/disk/by-* ? <Kamion> default + devfs-compat <Kamion> not sure about /dev/disk/by-* <Kamion> probably not for now <Kamion> we can add them when we come up with a good reason <Keybuk> ugh, I'll have to rewrite devfs-compat *cry* <Keybuk> the old rules flat-out don't work anymore * Keybuk wonders whether Marco has already <Kamion> I believe Debian's d-i works when built with udev, so probably ... <Kamion> well, networking is apparently broken, haven't investigated for myself yet <Mithrandir> we could just rip out all the devfs names and use the old ones again. <Kamion> I'm not going for that degree of forkage from Debian <Kamion> there should be an abstraction layer <Kamion> that can go into Debian <Mithrandir> isn't debian going to go with udev soonish? <Kamion> yes but 2.4 will still be supported for a while <Mithrandir> hm, ok <Mithrandir> as in "for etch"? <Kamion> dunno <Keybuk> the problem is that the devfs names are about as reliable as daniels <Kamion> there are parts of d-i that still rely on walking /dev/discs to get at the list of disks on the system <Kamion> those need to be fixed to use parted/libparted <Kamion> but for now it's not just a trivial sed job to change them] <Kamion> and Linux paths have changed around so much in the last three years that I have zero belief that they won't change again, so having an abstraction layer in between d-i code and device paths is good for us anyway <Keybuk> yeah <Keybuk> Linux paths are now totally non-fixed <Keybuk> it's up to the distro/app to pick them <Keybuk> the trouble with the devfs paths is that they're a bit racey <Keybuk> when devfs was around, it was easy, because the kernel could keep track of the enum with a BKL around it <Keybuk> but in userspace, we've no idea how to make a number that truly counts the number of (e.g.) cdroms <Keybuk> so with udev, you end up with /dev/cdroms/cdrom0 /dev/cdroms/cdrom4 /dev/cdroms/cdrom9 <Keybuk> which makes most things (including hw-detect) sulk <Keybuk> or, worse, you end up with two things trying to be /dev/cdroms/cdrom2 <Kamion> right, I'm happy to move for special cases where it really bites us, but I don't want to commit to doing so for everything <Mithrandir> as long as you can find all the cd-roms in the system, that's not a problem, really. <Kamion> and for those, I'd rather make the code fall back to devfs paths so that I can keep in sync with Debian <Keybuk> heh <Keybuk> annoyingly there isn't a way to do that anyway <Keybuk> none of the buses expose the media type in /sys <Keybuk> and then you have SATA, which is fucked <Keybuk> IDE devices appear as SCSI generic devices <Keybuk> so they don't show up in /proc/ide .. and you can't use the device name to decide what it is <Keybuk> which is why d-i doesn't work on Acer laptops <Keybuk> (amongst other things) <Mithrandir> vendor for my SATA stuff seems to be set to ATA.. <Mithrandir> no idea if that can be used for something <Keybuk> dunno, I'll play with that more when quest arrives I guess <Mithrandir> which quest is that named after? <Keybuk> all of them <Keybuk> I've not thought of a better name yet <jbailey> Keybuk: Wha? <jbailey> Keybuk: What would I do with X in the initramfs? <jbailey> Kamion: Thanks! <Keybuk> jbailey: like the idea #ubuntu-boot 2006-11-13 <SimonAnibal> When I install Ubuntu Edgy on a Dell 210L, the new upstart screen doesn't work. Is this normal? #ubuntu-boot 2006-11-19 <ag_> Any S-ATA partition experts out there? <ag_> Does Ubuntu use boot preferences to determine HDx for Grub? <ag_> Can't get grub to see my linux partition, which sits at /dev/sda2 <ag_> xp sits in /dev/sda1 <ag_> I have two IDE drives plus a S-ATA drive. The IDE drives are storage <ag_> OS's are on the S-ATA drive. Any thoughts? #ubuntu-boot 2006-11-20 <AG28> Anyone home?? :) #ubuntu-boot 2006-11-22 <Nimism1> idk if any of you are here or not but if you are... I have recantly installed ubuntu as a dual boot on this system with XP. Now when I select XP from GRUB to boot; it just makes my system repost and starts all over again #ubuntu-boot 2007-11-06 <guest> hello? #ubuntu-boot 2007-11-25 <alexander> Hi I have a strange login response. can you help? <alexander> hello. I have a strange login response when I mis-enter a password. After the incorrect password is entered, the two fields (user and passwd) are greyed out. I cannot enter any text, otherwise the GUI is responsive. Has anyone seen this beofre? <alexander> I should add that I am using kubuntu #ubuntu-boot 2007-11-30 <digitaldevoter> Hi can you help me #ubuntu-boot 2008-11-04 <d00kiejones> hello <d00kiejones> having a hibernate problem <d00kiejones> i installed on a usb hdd with my internal unplugged <d00kiejones> and i cant resume from hibernate it
{'channel': 'ubuntu-boot', 'month': 11}