[09:07] <HiddenWolf> Keybuk, does that bootchart tell me y'all have managed to halve dapper boot times?
[09:07] <Keybuk> ish
[09:07] <Keybuk> certainly below 1m
[09:07] <infinity> Well, except for the part where there's no GDm there.
[09:08] <infinity> In fact, no runlevel 2 at all, if I'm not mistaken.
[09:09] <Keybuk> yeah, it's just rcS
[09:10] <HiddenWolf> ah
[09:10] <Keybuk> which has dropped from 55s to 39s
[09:12] <HiddenWolf> Hm, still amazing.
[09:13] <Keybuk> yeah, it's a start
[09:13] <Keybuk> there's probably another 10s or so in there
[09:13] <Keybuk> not loading framebuffer drivers should help a bit
[09:13] <Keybuk> and removing networking and pcmcia should too
[09:14] <HiddenWolf> It'd be sweet if things would only start if needed.
[09:14] <HiddenWolf> think hplib.
[09:14] <Keybuk> that starts after gdm
[09:14] <Keybuk> anything that starts after gdm isn't relevant
[09:14] <Keybuk> the game isn't time-until-end-of-rc2 ... but time-until-user-can-login
[09:15] <Keybuk> who cares if hplib and apache don't start until half way through their login?  they probably won't
[09:15] <Mithrandir> it should probably be "time until user logged in or system-fully-booted, whichever is longer"
[09:16] <Keybuk> no it shouldn't
[09:17] <Keybuk> I only care up to the point gdm's greeter comes up
[09:17] <Keybuk> after that iz gtk bug :)
[09:17] <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

[09:19] <infinity> We need to see a useable GDM as soon as possible.
[09:19] <infinity> Anything beyond that is nice (we don't want to grind for 2 more minutes) but much less critical.
[09:20] <Keybuk> right
[09:20] <Keybuk> once gdm is up, it's all low-hanging
[09:21] <Mithrandir> Keybuk: I care about "machine usable and stuff working", not "shows me pretty junk"
[09:22] <Keybuk> define usable :)
[09:22] <Keybuk> your machine might not be usable until you plug in your pcmcia network card
[09:23] <Keybuk> and if we bootcharted the 5 minutes for you hunting through the crap on your desk, it'd be a loooong time
[09:23] <Keybuk> the best definition I can think of is that the user can do _something_
[09:23] <Keybuk> ie. get them a greeter or getty as soon as you can
[09:52] <HiddenWolf> Keybuk, how much do you think is realisticly what you can still shave off it?
 that much
[09:52] <HiddenWolf> hah, ok.
[09:53] <HiddenWolf> get me <---------> this much, and I'll extend an open invitation to free beer. ;)
[09:55] <Keybuk> beer is over-rated
[09:56] <Mithrandir> beer is good
[10:07] <HiddenWolf> Keybuk, apple-juice for you then. :)
[10:07] <HiddenWolf> Keybuk, with a straw. :)
[10:07] <Keybuk> vodka!
[10:11] <HiddenWolf> Keybuk, Would I have to carry you out in that case?
[10:39] <Keybuk> I'm feeling daring
[10:39] <Keybuk> let's see if I can get to X
[10:41] <Keybuk> cor
[10:41] <Keybuk> I can
[10:45] <Keybuk> I still want to know what that strange sh/run-parts thing is in rcS
[10:49] <Keybuk> ahhhh
[10:49] <Keybuk> it's in a modprobe-post-install rule
[11:10] <HiddenWolf> Keybuk, you're working without X?
[11:11] <Keybuk> I was
[11:11] <Keybuk> I have X now
[11:20] <Keybuk> Kamion: any alarm bells ringing if I suggest making /tmp and /var/run tmpfs?
[11:31] <Kamion> the main problem is partman doesn't know how to do that :P
[11:31] <Keybuk> why does partman need to know?
[11:31] <Kamion> because it sets up fstab ...
[11:31] <Keybuk> virtual filesystems are mounted long before fstab is around :)
[11:32] <Kamion> er
[11:32] <Keybuk> cf. our discussion about the futility of having /proc in there
[11:32] <Kamion> you mean admins don't get to choose? I don't think that's so good
[11:32] <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
[11:33] <Keybuk> hmm, I can see the argument for being able to choose /tmp
[11:33] <Kamion> /var/run's probably ok
[11:33] <Keybuk> /var/run is never large, it's just pid files and sockets
[11:33] <Keybuk> (and having it as a tmpfs would solve a major ordering issue I'm currently having <g>)
[11:33] <Kamion> but by the same token I don't see why we need to force it in initramfs either ... oh?
[11:33] <Keybuk> there's a bunch of rcS stuff to clean up /var/run before things are started
[11:34] <Keybuk> but I'd have to move that all into the initramfs in case udev starts the things now
[11:34] <Keybuk> rcS should increasingly become "things udev doesn't do"
[11:35] <Keybuk> I'll have a think and a play with some different ideas, see which works best and doesn't break anything
[11:35] <Kamion> ah, hm
[11:36] <Keybuk> also having it as a tmpfs actually means we can start networking before the real filesystem, which is a current snag
[11:36] <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
[11:36] <Keybuk> /etc/network/run would become /var/run/network, and all would be happy
[11:36] <Keybuk> Kamion: yeah, I checked main for them, and couldn't immediately see any -- have to check postinst yet though
[11:38] <Keybuk> at the moment I have the problem:
[11:38] <Keybuk> udevplug finds network card
[11:38] <Keybuk> udevd calls ifup
[11:38] <Keybuk> ifup can't write to /etc/network/run/ifstate
[11:38] <Keybuk>  (time passes)
[11:38] <Keybuk> root filesystem gets checked and mounted rw
[11:41] <Keybuk> and, of course, if you swap the two... you get
[11:42] <Keybuk> root filesystem can't be chcked because /dev/hda1 doesn't exist
[11:42] <Keybuk> root filesystem remounted rw, and evil error gets shown
[11:42] <Keybuk> udevplug finds block device
[11:42] <Keybuk> udevd creates /dev/hda1
[11:42] <Keybuk> :)
[12:00] <Keybuk> heh
[12:00] <Kamion> I should probably start running around debian-installer preparing stuff for .15
[12:00] <Keybuk> I haven't even started the udev udeb stuff yet :-/
[12:01] <Keybuk> it's just a udeb with a bunch of binaries in
[12:01] <Kamion> <cjwatson@cairhien ~/src/ubuntu/debian-installer/debian-installer-20051026ubuntu3/build>$ wcgrep pcmcia-cs-udeb pkg-lists | wc -l
[12:01] <Kamion> 21
[12:01] <Kamion> joy
[12:01] <Kamion> just try not to emulate Marco's trick of continually leaving stuff out of the udeb
[12:01] <Keybuk> lol
[12:01] <Keybuk> I guess I'll have to modify hw-detect too
[12:01] <Kamion> hm? what for?
[12:01] <Kamion> oh, udevplug
[12:01] <Keybuk> to make it call the right bits of udev
[12:02] <Kamion> I was planning to move that into rootskel, I'm fed up with running around modifying a billion different pieces
[12:02] <Kamion> tell me what's needed and I'll get it incorporated in the right place
[12:02] <Kamion> just run udevplug?
[12:02] <Keybuk> let me upload our new very-simple udev.init for you, so you can see
[12:03] <Kamion> for udev.init, the plan is for udev-udeb to ship /lib/debian-installer-startup.d/S02udev with whatever it needs to do
[12:03] <Keybuk> http://people.ubuntu.com/~scott/udev.init
[12:03] <Keybuk> basically it's
[12:03] <Keybuk> mount /dev
[12:03] <Keybuk> udevd
[12:04] <Keybuk> cp /lib/udev/devices into /dev
[12:04] <Mithrandir> Keybuk: do you want the udeb bits for bootchart submitted, or should I just upload them?
[12:04] <Keybuk> uidevplug
[12:04] <Keybuk> Mithrandir: just upload them, if they don't touch the ordinary boot stuff
[12:04] <Mithrandir> ok
[12:04] <Mithrandir> they don't.  Or shouldn't, at least.
[12:04] <Kamion> Keybuk: take the start bit of that and make it /lib/debian-installer-startup.d/S02udev
[12:05] <Keybuk> ok, that's easy enough then -- without the initramfs stuff, I guess?
[12:05] <Keybuk> can I guarantee that the installer would have 2.6.15 so skip the "abort!abort!abort!" bit?
[12:05] <Kamion> you won't be in initramfs
[12:05] <Keybuk> ok
[12:06] <Kamion> hm, no, best have the error check, stuff is confusing enough at that stage
[12:06] <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
[12:06] <Keybuk> right
[12:06] <Kamion> well, let me rephrase that. you won't be in initramfs FOR NOW
[12:06] <Keybuk> lol
[12:06] <Kamion> that might change later, but if it does, it'll be initramfs for the whole installer
[12:06] <Keybuk> *blink*
[12:07] <Keybuk> is that "install a system, then exec run-init when done" ? :p
[12:07] <Kamion> nah, just initramfs as an initrd replacement
[12:07] <Keybuk> oh right
[12:07] <Kamion> although I suppose you could :)
[12:07] <Keybuk> thought you had the entire installer in an initramfs there
[12:07] <Keybuk> which would be kinda cute
[12:08] <Keybuk> it's /technically/ "only mounting the root filesystem" ... with the added bonus of making one first
[12:08] <Keybuk> great for kiosk mode ... they reinstall themselves when they reboot
[12:08] <Kamion> network configuration would be amusing
[12:08] <Kamion> it'd be a bit like tccboot, only more so, especially if you did a gentoo version
[12:08] <Keybuk> you know it'd rock
[12:09] <Keybuk> gentubuntu
[12:10] <Keybuk> I bet jbailey would like it
[12:10] <Keybuk> I swear he wants X in the initramfs
[12:11] <Mithrandir> that'd make X start early enough in the boot, at least.
[12:11] <Mithrandir> can tcc be used to bootstrap gcc?
[12:13] <Keybuk> Google says yeah ... *cough*
[12:15] <Keybuk> OMG THIS NEW-FANGLED-SHINY-INIT VIOLATES POLICY! SEVERITY SHALLOW-GRAVE!
[12:15] <Keybuk> "oh, wait, it's sysv-rc ... uh, maybe it's policy's fault"
[12:19] <Kamion> jbailey: please remove that zoneinfo-udeb patch I did from glibc at your next convenience; the installer no longer needs it
[12:20] <Kamion> or tell me and I'll do it
[12:28] <Keybuk> Kamion: do you know what kind of /dev rules we want for d-i?
[12:29] <Keybuk> I guess we want the default naming rules, but do we also want things like /dev/disk/by-* ?
[12:29] <Kamion> default + devfs-compat
[12:29] <Kamion> not sure about /dev/disk/by-*
[12:29] <Kamion> probably not for now
[12:29] <Kamion> we can add them when we come up with a good reason
[12:32] <Keybuk> ugh, I'll have to rewrite devfs-compat *cry*
[12:33] <Keybuk> the old rules flat-out don't work anymore
[12:35] <Kamion> I believe Debian's d-i works when built with udev, so probably ...
[12:35] <Kamion> well, networking is apparently broken, haven't investigated for myself yet
[12:36] <Mithrandir> we could just rip out all the devfs names and use the old ones again.
[12:38] <Kamion> I'm not going for that degree of forkage from Debian
[12:38] <Kamion> there should be an abstraction layer
[12:38] <Kamion> that can go into Debian
[12:38] <Mithrandir> isn't debian going to go with udev soonish?
[12:38] <Kamion> yes but 2.4 will still be supported for a while
[12:39] <Mithrandir> hm, ok
[12:39] <Mithrandir> as in "for etch"?
[12:39] <Kamion> dunno
[12:39] <Keybuk> the problem is that the devfs names are about as reliable as daniels
[12:39] <Kamion> there are parts of d-i that still rely on walking /dev/discs to get at the list of disks on the system
[12:39] <Kamion> those need to be fixed to use parted/libparted
[12:40] <Kamion> but for now it's not just a trivial sed job to change them] 
[12:40] <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
[12:45] <Keybuk> yeah
[12:45] <Keybuk> Linux paths are now totally non-fixed
[12:45] <Keybuk> it's up to the distro/app to pick them
[12:45] <Keybuk> the trouble with the devfs paths is that they're a bit racey
[12:45] <Keybuk> when devfs was around, it was easy, because the kernel could keep track of the enum with a BKL around it
[12:46] <Keybuk> but in userspace, we've no idea how to make a number that truly counts the number of (e.g.) cdroms
[12:46] <Keybuk> so with udev, you end up with /dev/cdroms/cdrom0 /dev/cdroms/cdrom4 /dev/cdroms/cdrom9
[12:46] <Keybuk> which makes most things (including hw-detect) sulk
[12:46] <Keybuk> or, worse, you end up with two things trying to be /dev/cdroms/cdrom2
[12:47] <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
[12:47] <Mithrandir> as long as you can find all the cd-roms in the system, that's not a problem, really.
[12:47] <Kamion> and for those, I'd rather make the code fall back to devfs paths so that I can keep in sync with Debian
[12:48] <Keybuk> heh
[12:48] <Keybuk> annoyingly there isn't a way to do that anyway
[12:48] <Keybuk> none of the buses expose the media type in /sys
[12:49] <Keybuk> and then you have SATA, which is fucked
[12:49] <Keybuk> IDE devices appear as SCSI generic devices
[12:49] <Keybuk> so they don't show up in /proc/ide .. and you can't use the device name to decide what it is
[12:49] <Keybuk> which is why d-i doesn't work on Acer laptops
[12:49] <Keybuk> (amongst other things)
[12:51] <Mithrandir> vendor for my SATA stuff seems to be set to ATA..
[12:51] <Mithrandir> no idea if that can be used for something
[12:51] <Keybuk> dunno, I'll play with that more when quest arrives I guess
[12:52] <Mithrandir> which quest is that named after?
[12:52] <Keybuk> all of them
[12:52] <Keybuk> I've not thought of a better name yet
[01:07] <jbailey> Keybuk: Wha?
[01:07] <jbailey> Keybuk: What would I do with X in the initramfs?
[01:07] <jbailey> Kamion: Thanks!
[01:08] <Keybuk> jbailey: like the idea