#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 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!
<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 problem at runtime.
<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 2005-12-01
<tjj> anyone here know much about partman recipes
<tjj> I am trying to create boot,root,swap,opt,usr,home,var,tmp,recovery partitions and it creates named partitions for all but var and tmp and creates unamed paritiions for var and tmp
<tjj> seems like the / partition gets directories named var and tmp and the two partitions created are just unamed empty space
#ubuntu-boot 2005-12-03
<makx> Keybuk: have you split out udev into hooks?
* makx looks into the ubuntu patches.
<Keybuk> yes, our udev package will ship its own udev hook script and normal scripts
<infinity> (But he hasnt made those uploads yet, so looking for patches is useless)
<Keybuk> I've also taken the hook out of initramfs and the code itself out of the source
<makx> nice
<Keybuk> infinity: I'm gonna do them today
<infinity> \o/
* makx is fed up of running after Md.
<Keybuk> is lrm ready?
<infinity> I'm doing LRM today.
<makx> #341014 new udev related rc bug.
<infinity> BenC is doing one last kernel upload tomorrow before we do -meta.
<Keybuk> cool
<Keybuk> makx: yeah, there's a zillion copies of that one -- doesn't affect us :)
<infinity> (Which will be an ABI bump and another LRM, but that's no big deal)
<makx> Keybuk: haven't looked at it yet.
<makx> didn't know there are more than this one.
<infinity> Keybuk : Is there any chance of us converging with Debian's udev again, or are we forking too far to come back at this point?
<Keybuk> makx: afaict it's a user using a udev that requires 2.6.15 on 2.6.14
<Keybuk> infinity: forking it and never looking back
<Keybuk> upstream is our rock for udev now
<makx> Keybuk: any recommendation how i should handle that bug?
* makx wanted initramfs-tools to migrate to testing.
<makx> but udev keeps it away atm.
<makx> d-i needs initramfs-tools in testing.
<Keybuk> Depends: linux-image-2.6.15-<abi> would work
<Kamion> kernel tomorrow? OK, Flight 2 is officially next week, not this week
<Kamion> I'm not going to try to get it out two days after a major kernel upgrade
<makx> hmm newer udev works on my box
<makx> even with 2.6.14 *strange*
<infinity> Kamion : Wimp. :)
<infinity> Kamion : After some of my other tasks are settled, CD buildability/installability is moving up my personal priority list.
<infinity> Kamion : Have you decided what to do about cdebconf and libgtk+2.0-directfb-dev?
<makx> bahh could reproduce while recreating initramfs
<Kamion> infinity: not yet
<Kamion> inclined to rip it out of cdebconf for the moment until it stabilises upstream, though
<fabbione> Kamion: can i safely assume that architectures that have special /boot requirements are properly coded in partman-auto recipes?
<fabbione> it looks to me that it is a "true" statement and that the recipes are done in such a way that / is always on an ext3 fs
<fabbione> if so, that will simplify my life of a magnitude
<makx> Keybuk: i've fixes for udev 0.76, will integrate your separation after.
<Kamion> fabbione: the partman-auto recipes shouldn't create anything incorrect
<Kamion> by themselves
<fabbione> Kamion: ok.. i did recheck and it looks like i am right.. in that case i can save a few tons of code :)
<Mithrandir> Kamion lshttp://people.ubuntu.com/~tfheen/bzr/cdebconf-keystep/
<Mithrandir> grr
<Mithrandir> Kamion: http://people.ubuntu.com/~tfheen/bzr/cdebconf-keystep/ and http://people.ubuntu.com/~tfheen/bzr/cdebconf/ might be interesting.
<Mithrandir> they should be pullable now
<Kamion> I'll have a look later; buried in syslinux right now
<Mithrandir> sure, have fun. :-)
<Kamion> unlikely :-/
* Kamion idly curses Fabian
<Kamion> "please apply 3000 lines of assembly patch, kthxbye"
<Kamion> +.nosusedata:
<Kamion> NO, THIS ISN'T DISTRO-SPECIFIC AT ALL, WHY DO YOU ASK?
<Mithrandir> it's early enough that you can't use C sensibly?
<Kamion> syslinux is mostly assembly, yes
<Kamion> there's some C in the higher-level areas, but this is all very low-level
<Kamion> +lxrc_data      db ' SuSE='
<Mithrandir> heh
<Mithrandir> Kamion: it's debian-cd which generates the syslinux configuration for the install CDs, right?
<Kamion> Mithrandir: currently, yes
<Kamion> colin.watson@canonical.com--2005/debian-cd--ubuntu--0
<Mithrandir> cheers
<Mithrandir> I think I have a somewhat ugly hack for it to reboot after checking.  Set MENU to /bin/cdrom-checker;/sbin/reboot
<fabbione> i think i got partman-auto-lvm to do exactly what we want
<fabbione> Kamion: is the latest parted (with lvm support on ppc) in dapper?
<Kamion> fabbione: yes
<Kamion> <cjwatson@cairhien ~>$ bash
<Kamion> <cjwatson@cairhien ~>$ MENU='foo;id'
<Kamion> <cjwatson@cairhien ~>$ exec echo $MENU
<Kamion> foo;id
<Kamion> Mithrandir: I don't think that will work, no
<fabbione> Kamion: thanks
<Kamion> Mithrandir: shouldn't we just arrange for cdrom-checker to exit 12 in some mode? that will cause rootskel to reboot
<Mithrandir> Kamion: oh, it does?  If so, that's a trivial change.
<Mithrandir> isn't export MENU=${1:-/usr/bin/main-menu}
<Mithrandir> bloody unuseful, since it's always called from inittab?
<Kamion> you can run debian-installer by hand when debugging stuff
<Kamion> in fact I often do :)
<Kamion> yes, it's useless in the default path
<Mithrandir> yes, but that piece of code means you can't do my hack which was just to set MENU on the syslinux command line
<Mithrandir> so I'm wondering if it should leave $MENU alone if it's set.
<Mithrandir> any thoughts on that?
<Kamion> but your hack wouldn't work anyway because variable expansion doesn't work the way you need
<Kamion> oh, without ; you mean?
<Kamion> sure, it probably should
<Mithrandir> true, so cdrom-checker would need a small adjustment as well
<Kamion> anyone here know what the SuSE= kernel argument does on SuSE kernels?
<Mithrandir> to exit 12 instead of EXIT_SUCCESS if strcmp(argv[0] ,getenv("MENU")) == 0 or something like that.
<Kamion> that would work ...
<Mithrandir> it's a hack, but I don't think it's undesirable.
* Kamion nods
<Mithrandir> I'll just commit it upstream, I can't see any reason not to take that.
<Keybuk> Kamion: does /lib/modules/.../modules.ofmap exist and contain data for you?
<Kamion> Keybuk: not on Debian; should I reboot into dapper?
<Keybuk> it may need new module-init-tools
<Keybuk> ok, I won't worry for now
<Kamion> oh, use-case for having proc in fstab; upgrading chroots and being too lazy to type 'mount -t proc proc /proc' (some packages require mounted /proc to upgrade cleanly)
<Keybuk> true, but then we'd also need /sys in there
<Keybuk> not to mention /dev
<Kamion> 'mount /sys' seems to work without it being in fstab
<Kamion> (hmm, maybe /proc would too, haven't tried)
<Kamion> the minimal set of device nodes debootstrap sticks in /dev is generally enough to get by for just upgrading stuff
<Kamion> you don't really need hardware devices there, just the virtual ones
<Keybuk> I guess
<Keybuk> I'm not too concerned which way we go
<Keybuk> if we have /proc in fstab, we should have /sys too, both with a note that everything is ignored and it's just there so you can "mount /proc"
* fabbione hits lvm & co straight in the balls
<infinity> Kamion : People mount proc from inside their chroots?... I mount proc from the base system into all the chroots.
<fabbione> GO LVM
<fabbione> DIE DIE DIE
<Mithrandir> Kamion: would you rather that I backport my changes (so we have to merge them later), or should I just upload the packages in Debian and wait for them to trickle through to us?  It's rootskel and cdrom-checker.
<Kamion> Mithrandir: just do it in Debian, I think
<Kamion> particularly since we're in sync with rootskel right now
<Mithrandir> ok, sure
<Mithrandir> do we sync installer components automatically?
<Kamion> yes
<Kamion> coo, syslinux supports assembling multiple initramfs pieces now
* fabbione builds d-i to test pal on ppc
<fabbione> we need to switch to .15
<fabbione> or i will be forever doomed to build custom d-i
<jbailey> fabbione: What's blocking it?
<fabbione> jbailey: that my ppc is not supported in .12?
<fabbione> so i had to patch .12 to get a kernel that can actually install on my ppc
<jbailey> Kamion: I think it has since at least OLS.
<jbailey> Kamion: HPA and I talked about it there.
<fabbione> bah
<fabbione> pal still hates me on ppc
<fabbione> ok.. it's tomorrow's work to get it fixed
<Mithrandir> Kamion: some people might think you're slightly obsessive in your branding when you are changing Debian to Ubuntu inside comment strings in the source. ;-)
<Kamion> :-)
<fabbione> hmmm
<Kamion> yeah, should probably drop those patches
<fabbione> Kamion: do you think you can help me a second?
<Kamion> sure
<fabbione> for some reasons a d-i build from today on ppc
<fabbione> doesn't have libselinux
<fabbione> and lvm2 basically doesn't work
<fabbione> using the last daily install on i386 works.. and i am assuming it has libselinux
<Kamion> it needs libselinux in the udeb build? that's fucked
<Kamion> there's no point having libselinux in d-i and I'd rather it weren't there
<fabbione> pvs: error while loading shared ..
<fabbione> ok
<Kamion> there's no selinux udeb
<fabbione> so i guess i need to play with lvm2 to make 2 different builds
<Kamion> yes
<fabbione> that's ok
<fabbione> it's only linked
<fabbione> "only"
<Kamion> if it's linked as a shared object (and if not, why not?) then there needs to be a udeb
<fabbione> either i got the merge wrong
<fabbione> (lvm2)
<fabbione> or we need that
<fabbione> but right now i am too tired to figure it out
<fabbione> the new pal should work just fine once this is fixed
<Keybuk> Kamion: so, what do you reckon?  should I upload new udev and friends now, or wait until wednesday morning
<Keybuk> (on the basis that I'm not contactable at all tomorrow)
<infinity> Will it break the current default kernel?
<infinity> If 2.6.12-9 continues to work right until I update linux-meta, upload it now.
<infinity> Otherwise, drop the upload somewhere where I can get at it, and I'll do it all together.
* Kamion agrees with infinity
<Keybuk> it'll braek
<infinity> Now I tihnk I'm going to dirnk myself into a stupor and attempt to get some stress-relieved sleep.
<infinity> Keybuk : Then sign the uplooad, put it somewhere, and mail me the location.
<infinity> Keybuk : I'll make the upload together with linux-meta.
<Keybuk> http://people.ubuntu.com/~scott/packages/new-udev
<jbailey> Keybuk: How brave do we have to be? =)
<Keybuk> works for me :)
* jbailey builds
<jbailey> Do I need to be on 2.6.15?
<jbailey> Last I checked that was still b0rked on ppc64
<jbailey> dpkg-source: error: file udev_076.orig.tar.gz has size 4903 instead of expected 281735
<Keybuk> yes, you do
<jbailey> Keybuk: How are you planning to handle the migration from Breezy to Dapper?
<Keybuk> uh, try now
<Keybuk> "migration" ?
<jbailey> Making sure that a person has the new kernel loaded.
<jbailey> Works this time, thanks.
<Keybuk> it checks whether /sys/class/mem/null/uevent exists, if not unmounts /dev and puts the old static one back
<jbailey> Ah, cool.
<Keybuk> it seemed a sane one to look for <g>
<jbailey> Ooo, cuddly.  It provides the initramfs-tools hooks itself.
<Keybuk> yes
<jbailey> Nice.  The hooks are quite clean.
<jbailey> I'll ask Ben about 2.6.15 when he's on later, and then test it on ppc64 and sparc for you.
<Keybuk> right, gonna have lunch, then go down south -- back wednesday
<makx> hello jbailey
<makx> i've got an upldate for the debian version.
<makx> new udev upstream..
<makx> closes 1 rc bug, haven't packaged yet.
<jbailey> makx: Cool.
<makx> will ping you in one hour when it's on mentors.
<jbailey> makx: Note that Ubuntu and Debian udev packages are about to diverge heavily.
<makx> yes please tell me
<jbailey> makx: It might be worth taking a look at some of the hacks that Scott's done in his repository.  It splits all of the udev stuff into the udev package.
<makx> you are stabilizing?
<makx> i know
<jbailey> For Debian, you might want to take those hooks and package them into the initramfs-tools package directly.
<makx> is it uploaded already to ubuntu?
<makx> spoke with Md he will take those hooks in middle term
<makx> enough running after udev.. ;)
* makx looks up packages.u.c
<makx> uugh missing /dev/input/mouse
<makx> has your kernel also modular mousedev
<jbailey> Yes.
<makx> :(
<makx> Keybuck: where can i find latest udev?
<makx> jbailey uploaded 1 min ago initramfs-tools 0.41 -> http://mentors.debian.net/debian/pool/main/i/initramfs-tools/
<makx> bug reporter did test that version with udev from incoming
<makx> solved all issues for him+me.
<makx> again an high urgency upload.
<makx> also vorlon is letting initramfs-tools 0.40 into testing
<makx> as it works against the udev which is in etch.
<makx> :)
<makx> Kamion: initramfs-tools migrated to testing :)
<Kamion> hooray, we can revert that hack after the mirror push then
<fabbione> Kamion: still around?
<Kamion> fabbione: yes
<fabbione> Kamion: do you think we can schedule a 20/30 minutes work together tomorrow?
<Kamion> yeah, probably. I have to go into town at some point though
<fabbione> other than between 10:30 UTC and 12:30 UTC ( i have to go to the dentist)
<fabbione> yeah you tell me when it's best for you outside that slot and i am fine
<fabbione> there are some issues with pal i need to look at together with you
<fabbione> because i am not sure 100% how to address them
<Kamion> 15:00 UTC?
#ubuntu-boot 2005-12-04
<fabbione> should work fine for me
<fabbione> it's nothing extremely urgent.. so if we can't make it, tough, we can always reschedule it
<fabbione> good night Kamion :)
<Kamion> sure, night :)
<fabbione> bah
<fabbione> it looks like that libselinux in lvm2-udeb is not lvm2 fault
<fabbione> there is something wrong with the build environment
* sivang wonders if this channel shares any of the properties of #debian-boot :)
<infinity> Well, it has -boot in the name.
<fabbione> yeah but here there are only a bunch of bastards
<fabbione> :)
<sivang> hehe
<sivang> well, it's probably specially created for speeding up the boot process?
<sivang> err,
<sivang> thqat is for discussing that stuff
<fabbione> Kamion: ok the problem is way more complicated than it did look in the beginning
<fabbione> lvm2-udeb manages to link to libselinux via libdevmapper
<fabbione> even if --disable-selinux is forced
<fabbione> so libselinux is pulled in indirectly
<fabbione> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315505 <-
<fabbione> but they didn't realize that device mapper will still break the world
<fabbione> Kamion: ok.. i got lvm2 back to normal.. just waiting for the packages/dep-wait & co to propagate
<Kamion> sivang: #debian-boot's name is historical, from boot-floppies; it should really be #debian-installer now, but we can't be bothered to move
<sivang> Kamion: ofcourse :)
<Kamion> we created this channel primarily to coordinate the move to 2.6.15 and the new udev and co. for dapper; no doubt it will be used for other related things
<infinity> (on unrelated ones)
<infinity> Side note: The only thing worse than not being able to make something work for hours on end is MAKING IT WORK, BUT NOT BEING SURE HOW.
<infinity> I think  Ineed a brain-break.
* Mithrandir break infty's brane
<Mithrandir> s/break/&s/
<sivang> infinity: indeed.
<fabbione> yeah
<fabbione> good new steps forward
<fabbione> Kamion: pal is still broken on ppc :).. but at least it seems that manual LVM works.. so that makes my life still very simple. I think i am hitting a very stupid problem but i will work on it after the dentist
<Mithrandir> so, I suck.  This won't work, since cdrom-checker complains about not finding the cdrom device.
<Kamion> oh yeah, you'll need to make cdrom-detect run first
<Kamion>    * Make ext2=m on all arch's.
<Kamion> oh great, more d-i changes ...
<Mithrandir> hmm, should I add a hack to cdrom-chooser for that, or should I wrap it in a small shell script which just does udpkg --configure cdrom-detect ; udpkg --configure cdrom-checker?
<Kamion> cdrom-chooser depends on cdrom-detect ...
<Kamion> so perhaps if your menu hook is udpkg --configure cdrom-checker rather than running /var/lib/dpkg/info/cdrom-checker.postinst directly, it'll work?
<Kamion> s/chooser/checker/ above
<Mithrandir> I'll try.
<Kamion> (can't remember if udpkg --configure follows dependencies)
<Mithrandir> it does, iirc
<Kamion> hm, doesn't seem to
<Kamion> maybe udpkg --configure cdrom-checker cdrom-detect
<Kamion> er, other way round
<Mithrandir> if DODEPENDS is #defined, it should
<Mithrandir> which is not default
<Mithrandir>         ./configure --without-depends --without-debug \
<Mithrandir>                 --without-remove --with-admindir=/var/lib/dpkg
<Kamion> only for --install
<Kamion> not --configure
<Kamion> (in the current code)
<Mithrandir> yeah, and it's compiled out anyway, so..
<Mithrandir> "export: 5: --configre: bad variable name"
<Mithrandir> configure, even
<Kamion> quoting?
<Mithrandir> yeah, in rootskel
<Mithrandir> I'm sure joeyh is going to love me for first breaking rootskel, then uploading it twice in a day.
<Mithrandir> oh, boot faster, xoog
<Mithrandir> heh, debconf complains about --configure.  I think I'll just write a tiny wrapper in cdrom-checker instead.
<Kamion> ok
<Mithrandir> gnnr, I just get a black screen with a single grey line on it.
<Mithrandir> hw-detect seems to be hanging.
<Mithrandir> Kamion: any great ideas?  Running it by hand works, but well, is kinda wrong.
<Kamion> I'd boot with BOOT_DEBUG=3, use the "before init" debugshell to replace /sbin/debian-installer in /etc/inittab with /bin/sh, and then run through it step by step
<Kamion> maybe debconf isn't connected up right
<Mithrandir> it blows up when I run debconf -o d-i /bin/cdrom-detect-menu (which just runs udpkg --configure cdrom-checker cdrom-detect)
<Mithrandir> even from tty2
<Kamion> you'd want UDPKG_QUIET=y in cdrom-detect-menu at least
<Kamion> (perhaps the witter is confusing debconf)
<Mithrandir> yeah, I'll try that
<Kamion> I dunno, in general I'd be trying to imitate what main-menu does
<Kamion> hmm, you might also like to look at the setup/* scripts in kickseed; they're run using MENU
<Kamion> export UDPKG_QUIET=y
<Kamion> udpkg --force-configure --configure "$1" 2>&1 | logger -t kickseed
<Kamion> that could become log-output these days, but otherwise that works in a MENU in kickseed
<Kamion> # without this, debconf clients will talk debconf protocol to syslog
<Kamion> . /usr/share/debconf/confmodule
<Kamion> hah, right
<Kamion> Mithrandir: source the confmodule at the top of cdrom-detect-menu; that's probably your problem
<Mithrandir> doh.
<Kamion> I knew I'd solved this problem before ;-)
<Mithrandir> Kamion: I'll buy you a beer on Sunday.
<Kamion> Sunday?
<Mithrandir> you're around Cambridge, aren't you?
<Mithrandir> Karianne and I are in London from Saturday until Wednesday, with a small detour to Cambridge on Sunday.
<Kamion> oh, right, cool
<Kamion> I'll check with Kirsten what we're doing on Sunday; I'd forgotten about your visit :)
<Mithrandir> I mailed debian-uk about it last afternoon
<Mithrandir> iirc
<Mithrandir> no idea if it managed to traverse sauce, though
<Kamion> 6 Tollef Fog Heen                            1  [Debian-uk]  Beer in Cambridge Sunday 2005-11-04
<Kamion> ^-- trn on chiark
<Mithrandir> goodie
<Mithrandir> Kamion: hmm, main in cdrom-checker seems to include crack such as system("touch /tmp/test") system("logger init"), etc.  I'll just get rid of those if you don't mind.
<Kamion> sure :)
<jbailey> Anyone here bored and willing to take the grub merge from me?
<Kamion> I suspect it was a very early udeb
<Kamion> jbailey: I'll grab it
<Mithrandir>  -- Martin Sjogren <sjogren@debian.org>  Sat, 22 Feb 2003 00:40:06 +0100
<Kamion> not bored as *such*, but I've merged grub before
<jbailey> Kamion: Thanks.  My bit of distro time left is best spent finishing the glibc bits.
<Mithrandir> so, it works, except reboots don't.
<infinity> jbailey : Will that include the creation of libc6-dev-i386, or -ENOTIME for that?
<jbailey> infinity: I started looking at that last night.  The next upload won't have it.  I want that to be primarily things that are really needed for the locales-in-langpacks stuff.
<jbailey> infinity: We're aiming to have that all in for flight-2.
<jbailey> infinity: Do you have a more urgent need for tha libc6-dev-i386 stuff?
<infinity> Nope. I couldn't care less if it happens soon, or even by release, it's just a wart I'd like to see go away "sometime"
<fabbione> yo
<fabbione> ok
<Kamion> right
<fabbione> i am having a bunch of problems with p-a-l and i need some help/advices on how to fix them
<fabbione> if you can get the code handy, it might help
<Kamion> ok; note I merged partman-auto last night
<fabbione> yes i saw that
<Kamion> but there shouldn't have been much relevant in there
<fabbione> i need to retest on i386 because ppc is farting on me
<fabbione> and i can't see why
<fabbione> but that's not the main issue for now
<fabbione> i will figure it later on
<fabbione> the first problem i wanted to talk with you was the way to restart parted
<Kamion> yeah, I noticed you disabled my change there
<fabbione> you did change the hugly code i did copy from somewhere
<fabbione> to something like:
<fabbione> stop_parted
<fabbione> start_partsomething
<fabbione> but i have issues with that
<fabbione> but i can't understand why
<fabbione> perhaps you can help me to shed some light on it
<Kamion> I'm just hunting down the svn changeset
<fabbione> if you have a test machine that you can trash
<fabbione> sure
<Mithrandir> Kamion: how can I get a status message from cdrom-checker through udpkg to cdrom-checker-menu?  Any ideas?
<Kamion> no test machine handy unfortunately
<fabbione> you can see it almost immediatly becuase you run pal
<fabbione> and the visuals are all wrong
<Kamion> Mithrandir: exit status, ideally ...
<Kamion> all wrong?
<fabbione> while using my restart code looks ok
<fabbione> if you are familiar with LVM a bit
<fabbione> and you have seen how partitions show up at partman? main menu
<fabbione> you will see that with your code the partitions do not show up the same way as when you do manual LVM
<fabbione> that's first "optical" symptom
<fabbione> and if you ask to commit the changes, it will fail
<fabbione> returning back to the main menu, everything looks ok again (like if parted is restarted the same way i do)
<fabbione> and a second commit will work
<Kamion> well, that's bizarre, because the function calls I replaced that code with contain identical code
<fabbione> ah
<Kamion> it's restarting in precisely the same way - the code's just in a common place now
<fabbione> hmmmm
<Kamion> if you can see a difference there, I'm all ears - I've got the diff in front of me and can't find anything
<fabbione> do you remember from what pkg is coming?
<Kamion> partman-base/definitions.sh
<fabbione> the common code i mean
<Kamion> hmm, unless 'exit 255' behaves differently in a function
<fabbione> eh
<fabbione> that could be
<fabbione> in a function you should return
<Kamion> seems unlikely; I'll test
<fabbione> i can test it
<Kamion> you can exit from a function
<fabbione> don
<fabbione> don't worry
<fabbione> i am only seeking ideas
<Kamion> ~ $ foo () { echo; exit 255; echo; }
<Kamion> ~ $ foo
<Kamion> <cjwatson@cairhien ~>$ echo $?
<Kamion> 255
<Kamion> seems to work as desired
<fabbione> also in dash or the busybox built-in?
<Kamion> fabbione: to be honest my first resort would be to stick 'set -x' at the top of perform_recipe_by_lvm and see what it's doing ...
<Kamion> fabbione: that's in busybox sh
<fabbione> yes i can stick set -x but where the hell does the output go?
<Kamion> /var/log/syslog
<fabbione> ok
<fabbione> perfect
<Kamion> it's not amazingly conveniently formatted but it should work
<fabbione> i am ok with that
<fabbione> given that it works :)
<Kamion> you can probably 'exec 2>/tmp/randomfile' if you like
<fabbione> i am happy if the out goes somewhere
<fabbione> i can figure the formatting
<fabbione> ok
<fabbione> the next problem is:
<fabbione> # check if the recipe contains lvmok tags otherwise fail
<fabbione> if [ -z "$(echo "$scheme" | grep "lvmok")" ] ; then
<fabbione>   XXXX: how do we bailout properly?
<fabbione>   exit 0
<fabbione> fi
<fabbione> let say that we are asked to perform a recipe on arch foo
<fabbione> where arch foo has recipes that contains no lvmok tags
<fabbione> i need to bailout
<fabbione> what's the proper way to do it?
<fabbione> at that point in time i didn't write anything to the disk
<fabbione> so it's easy
<fabbione> no actually
<fabbione> i already trashed the disk
<fabbione> but i need to bailout
<Kamion> you're supposed to do that check before trashing the disk!
<fabbione> ok i can do that
<fabbione> that's not an issue
<fabbione> but i need to know how to bailout properly
<fabbione> i don't think exit 0 is the way it's meant to be
<Kamion> make automatically_partition/some_device_lvm/choices only print the LVM choice if it can actually do it
<Kamion> see resize_use_free, which does that sort of thing
<fabbione> the problem is that we don't know the recipe yet at that time
<fabbione> do we?
<Kamion> choices is right before do_option ...
<fabbione> so we already have the recipe..
<fabbione> if so ok...
<Kamion> they're both run from ask_user, and there's no recipe selection in between
<Kamion> no, you probably don't
<Kamion> hmm, maybe
<Kamion> let me hunt around
<fabbione> ok
<Kamion> your script chooses the recipe itself
<Kamion> so there's no issue
<Kamion> choose_recipe "$free_size" || exit $?
<fabbione> that's from do_option
<fabbione> to hide the selecion, it needs to be done from choices
<Kamion> ah, I see what you mean, you don't want to ask questions from choices
<Kamion> well in that case just do the lvmok check before trashing the disk
<fabbione> yes and i am ok with doing that check...
<Kamion> all that logic is in your do_option so you can easily move it up
<Kamion> exit 1 should be fine to bail out
<fabbione> ok
<fabbione> perfect :)
<fabbione> exit 1 is all i was searching for ;)
<Kamion> you should probably db_input/db_go an error template of some kind first
<fabbione> that would make sense
<Kamion> look at perform_recipe, which does that
<fabbione> i guess we have some kind of standard error template
<fabbione> ok
<fabbione> i will
<Kamion> or in the choose_recipe function for that matter
<fabbione> ok
<fabbione> i can still move code up
<Kamion> hm, no, you'll probably need a new one since the text will need translated
<fabbione> i have no issues for that
<fabbione> the last problem i would like to address are unclean disks
<Kamion> my advice from bitter experience is to get new template text upstream as soon as possible, otherwise merging is HELL
<fabbione> ok. i want to finish pal no later than this week
<fabbione> modulo bugs
<fabbione> because i have other tons of stuff to do as well
<Kamion> sure
<fabbione> so let say you install breezy/dapper or whatever on lvm
<fabbione> you decide to reinstall dapper on it using pal
<fabbione> there is a big problem with LVM that finds the old install
<fabbione> pal in that case is dumb
<fabbione> it doesn't fail
<fabbione> it doesn't clean
<fabbione> the result can be a mess
<fabbione> so i was wondering what kind of approach i should use to that
<fabbione> like:
<fabbione> - send big fat warning to dd the disk before attempting
<fabbione> - try to cleanup automatically
<fabbione> - do it and hpe evertyhing will work right afterwards
<Kamion> my advice would be to just not offer it
<fabbione> ok
<Kamion> well, I guess you do want to be able to wipe the disk
* fabbione didn't think about it
<fabbione> well the point is exactly that one
<fabbione> there is no clean way to wipe a disk that had LVM other dd or a bunch of lvm commands that might fail
<Kamion> really? what goes wrong?
<Kamion> you do a NEW_LABEL ...
<fabbione> the LVM metadata are all around the disk
<fabbione> lvm doesn't care about the LABEL data
<fabbione> i did try that.. trust me
<fabbione> hitted my head on it for 4 hours
<Kamion> is there a command to wipe that? I thought there was
<Kamion> I remember we discussed this before and found one
<fabbione> you need to do a set of commands
<fabbione> lvremove -> vgremove -> pvremove
<fabbione> then you can add the new LABEL
<fabbione> that was for the RAID
<Kamion> ah
<fabbione> not for lvm
<fabbione> RAID has metadata in one place only for each disk
<fabbione> lvm is all around the disk
<fabbione> sort of inodes
<Kamion> surely it won't look through the whole disk if it doesn't find its superblock-equivalent though
<fabbione> of course not
<Kamion> so dd over that :)
<fabbione> dd means dd the entire disk
<fabbione> you don't know where the inodes are
<fabbione> not all of them at least
<fabbione> but yeah.... dd would be the best :)
<Kamion> can we use pvremove --force?
<Kamion> sorry, -ff
<Kamion>         /* we must have -ff to overwrite a non orphan */
<fabbione> that will kill the metadata for the partition
<Kamion> or indeed -ffy - should be a big enough hammer
<fabbione> i can try that.. yes
<fabbione> i mean i can test it easily
<Kamion> right, so if we do that for each partition, then NEW_LABEL, then autopartition, that should probably work
<fabbione> given i need to cleanup my disk each time i try pal
<fabbione> that should be sufficient i assume
<Kamion> yeah, I think s
<Kamion> so
<fabbione> ok
<fabbione> i guess i will start with these stuff
<Kamion> do we already have a big "you are about to WIPE your DISK!" warning?
<fabbione> hmmmmm
<fabbione> i don't think so
<fabbione> probably partman-auto does
<fabbione> i don't
<Kamion> ah, you do, but only on sun disklabels because they need to be committed
<fabbione> "it sucks to be you if you choose LVM and it didn't work"
<Kamion> I think you should probably just remove the two label_type = sun conditionals
<fabbione> that's code i did copy from autopartitioning i think
<fabbione> or from somewhere inside partman-auto
<fabbione> why should i?
<Kamion> right, but you're now becoming a different case because you're doing non-undoable stuff to the disk
<Kamion> autopartition is only doing stuff that partman can unwind
<fabbione> right
<Kamion> up until you actually accept the changes
<fabbione> true
<Kamion> ideally p-a-l would be the same, but that sounds non-trivial
<fabbione> you can't really...
<Kamion> well, actually, where does stuff go wrong? at the autopartition stage, or later?
<fabbione> it depends...
<fabbione> as it is now it works
<Kamion> if it only goes wrong later, then you could do the pvremove -ffy in a commit.d script
<Kamion> and then you can preserve the ability to undo changes, which is really nice to have
<fabbione> yeah but you won't be able to unwind the main partitions
<Kamion> why not?
<Kamion> do you actually write them to disk in autopartition?
<fabbione> because you need to COMMIT to access the partition that will be lvm
<Kamion> oh, ok
<fabbione> if you see also manual LVM, it does exactly the same
<fabbione> it asks you to commit before accessing the LVM menu
<fabbione> and it makes sense
<Kamion> right, just pvremove -ffy up front then, and display the warnings unconditionally
<fabbione> yeps
<fabbione> if it fails.. well sucks to be you
<fabbione> buty
<Kamion> better partman/LVM integration would involve having a representation of LVM partitions in /var/lib/partman/devices/, so that you wouldn't need to commit beforehand
<fabbione> yeah that's true
<fabbione> but there are also other problems
<fabbione> like roundings
<fabbione> all sizes will be highly incorrect
<fabbione> but well.. minor details
<Kamion> mm
<fabbione> (sorry i need to wake up my wife)
<fabbione> re
<fabbione> ok i think for now i am all set
<fabbione> at least...
<fabbione> i think i am :)
<fabbione> thanks a lot Kamion
<fabbione> it's really nice to work with you
<Kamion> hope it all works :)
<fabbione> oh don't worry
<fabbione> i will come back if it doesnt :P
<Kamion> heh
<fabbione> right now i want to get the code to be in a decent state and work
<fabbione> the next cleanup step will be merging and removing all the duplicate with partman-auto
<fabbione> because there is really a tons
<fabbione> that doesn't need to be there
<fabbione> but for now it's easier for me so that i can fork and merge as i need without disrupting all of partman-auto
<Kamion> have you got upstream commit access yet? you probably should
<Kamion> ask joeyh
<infinity> Kamion : Will d-i be using the same udev firmware-loading mechanism as the base system?  (ie: should I be installing udeb firmware to the same filesystem location?)
<Kamion> infinity: yeah, more or less the same mechanism anyway
<fabbione> Kamion: no i don't and i would like not to. I will push the patches as they come
<fabbione> i am keeping the interdiffs
<fabbione> pvremove -ffy seems to do the trick :)
<Kamion> cool!
* Mithrandir scratches his head and wonder if he should just use a flag file instead of the return value.  Not so pretty, but certainly less work, since something keeps eating the exit status.
<Mithrandir> it's so weird coming back into #debian-boot.  Nothing has changed, kinda, except I'm not part of the crowd yet/any more.. I guess it'll work itself out over a few days or weeks.
<Kamion> Mithrandir: mostly the effect of trying to get used to the now-rather-enormous codebase again?
<Kamion> I do love design discussions like that one just now with joeyh though ... makes me feel like d-i is a real project ;-)
<Kamion> (real as in big commercial blah)
<Mithrandir> Kamion: nah, more the "I'm not sure whose feet I tread on when doing random crap"
<Kamion> Mithrandir: http://people.debian.org/~fjp/d-i/authors.html might help
<Mithrandir> has tausq or tbm done anything to d-i lately?
<Mithrandir> or Marvin?
<Mithrandir> (not accusing, more "are they still around?"
<Mithrandir> )
<Kamion> tausq hasn't, tbm has done various bits and pieces
<Kamion> don't think sjogren has been around much at all
<Mithrandir> he was around _a lot_ in the early phases
<Kamion> yeah
<Kamion> tsauter's mostly vanished too
<Mithrandir> shame that. :-/
#ubuntu-boot 2006-12-02
<litwel> hello
<litwel> do you know where I could find some more info on the graphical boot menu?
#ubuntu-boot 2007-11-30
<digitaldevoter> Hi can you help me
#ubuntu-boot 2009-11-27
<jtmink1> hey guys i have a unique problem, i've found some hits on the forums but nothing that nails it on the head. It has to do w/ grub2 and windows7... think you can help?
#ubuntu-boot 2010-11-30
<ShacakaL> Hi
#ubuntu-boot 2011-11-28
<ubuntu> hello?
#ubuntu-boot 2011-11-29
<chuckatpdo2> quit
#ubuntu-boot 2013-11-26
<vats_monroe> hello
#ubuntu-boot 2018-11-26
<victorh> it's so quiet
