#ubuntu-boot 2005-12-05
<Kamion> mckinstry's still a bit active, although more on console-* than on d-i itself now
* Kamion -> bed
<Mithrandir> fjp, smarenka, sferriol, zinoviev are the new people I don't know.  That is, I've met fjp and he's friendly enough.  No idea who the rest of the crowd is, though.
<Mithrandir> sleep tight
<Kamion> zinoviev's not around much - he's the partman god but kind of in a Judaeo-Christian way ;-)
<Mithrandir> heh, 'k
<Kamion> he lives in Bulgaria and AFAIK has net access once a month or something
<Mithrandir> partman is scary.
<Mithrandir> I wonder what'll replace it.  Something scarier with pluggable components.
<Kamion> oh, btw, I checked with Kirsten and we're free on Sunday; fancy coming up to our local in North Cambridge for lunch?
<Mithrandir> that'd be very nice, absolutely.
<Kamion> cool
<Kamion> anyway, really bed now :)
<Mithrandir> :-)
<fabbione> WOO HOOO
<fabbione> pal is working on ppc now
<Kamion> infinity: so are we doing new udev today? pretty please?
<infinity> I'm tryin', I'm tryin'...
<infinity> Last round of tests for LRM.. I hope.
<infinity> Unless I find glaring bugs, I'll upload this, and worry about the small bugs later.
<Kamion> hmm. since I have to switch d-i's initrd filesystem *anyway* since BenC helpfully modularised ext2 everywhere, it's tempting to just make the jump to initramfs
<fabbione> eh
<fabbione> hmm
<fabbione> initramfs++
<Kamion> might as well break everything AT ONCE
<infinity> \o/
<Mithrandir> I'll upload my cdrom-checker thingy to make sure to break that as well, then.
<fabbione> hmmm
<fabbione> i have some mixed feeling about slamming swap on lvm
<fabbione> it's good for server, but bad for desktops
<fabbione> since it looks like the kernel can't resume from swap on lvm
<fabbione> but it's a kernel bug
<fabbione> what do you suggest guys?
<infinity> This isn't going to be a default, is it?
<fabbione> no
<fabbione> it's a selectable option
<fabbione> Kamion: can i take a lock on partman-auto?
<infinity> Then I don't see the problem in letting people select it.
<fabbione> well you don't get asked for: do you want partition foo on lvm?
<Kamion> fabbione: yes
<infinity> If we have the capacity to warn them that swap-on-lvm means no suspend/resume, that might be nice.
<fabbione> you just select: "Trash my disk and install on LVM"
<infinity> Oh, I see.  It's all or nothing.
<infinity> Hrm.
<fabbione> infinity: i was more thinking to do: if server install swap on lvm, otherwise swap on disk
<infinity> Then maybe it's better to leave the swap ina real partition, unless we can fix the kernel bug (misfeature?)
<fabbione> Kamion: thanks.
<fabbione> but i am not sure if we can actually detect that at that stage of the installation
<infinity> Keybuk : Is that the real you, or a floating IRC client?
<Keybuk> real me
<infinity> Cool. I'm dangerously close to declaring "enough testing is enough testing, damnit" and finally uploading LRM.
<Keybuk> ok, I can upload my packages when you're done -- just ping me
<Mithrandir> Kamion: does busybox d-i now include nanosleep?
<Keybuk> Mithrandir: note that there is no "nanosleep" binary now, I modified the klibc sleep binary to support 0.4 type arguments
<Kamion> Mithrandir: not AFAI
<Kamion> K
<Mithrandir> Keybuk: 'k
<Mithrandir> Kamion: can we do the same to busybox?
<Kamion> Mithrandir: feel free, it's in coreutils/sleep.c
<Mithrandir> thanks
<Kamion> might want to make it a config option
<infinity> Alright, I declare nvidia on amd64 good, screw i386 (it should work if amd64 did), and now to double-check fglrx on i386 and upload.
<infinity> Anything that breaks after that, I'll fix later.
<Mithrandir> we're using busybox or busybox-cvs those days?
<Kamion> busybox
<infinity> So, another 30-60 mins, guys, then you can stop hating me.
* Mithrandir ruffles infinity 
<Mithrandir> grr, it uses doubles explicitly.  Silly thing.
<Kamion> what's silly about that?
<Mithrandir> sorry, longs.
<Mithrandir> is strtotimespec a somewhat standard function?  All the references I find to it are klibc refs.
<Keybuk> no, it's just a klibc utility function
<Mithrandir> grr, handling stuff like 0.5m is harder than it seems.
<Keybuk> yes
<fabbione> code reduciont++
<fabbione> reduction even
<fabbione> Kamion: already removed 1.5K of duplicated code... this stuff rock hard
<fabbione> Kamion: i blame you for one thing only.. you didn't drag me into d-i earlier ;)
<Kamion> heh
<Kamion> fun, isn't it
<infinity> Okay, rsync to chinstrap going.  For better or worse, this is it.
<infinity> When Australia's done fucking with my head (about 48 mins, according to rsync), I'll upload to jackass.
* infinity goes to the store while he waits.
<Mithrandir> compiles now, at least \o/
<Mithrandir> it seems to work as well
<Mithrandir> Kamion: want to see the diff or should I just upload it?
<Kamion> Mithrandir: just upload
* Kamion is buried in partman.deb again. Quite fun though, just wrote basic code to merge multiple build-dependencies with differing relations/versions
* fabbione kills more duplicate code
<fabbione>  8 -rw-r--r--  1 fabbione fabbione 4542 2005-11-30 14:12 shared.sh
* infinity sheds a tear for his closed connection, and starts again, remembering --partial this time.  <sigh>
<fabbione> hhahah
<fabbione> ARGH GRRR HUPMEHIEIHUA#)(J
<Mithrandir> I'll make bootchart run in d-i if it sees "bootchart" on the kernel command line, sounds good?
<Mithrandir> so we can have it in the default images.
<infinity> Sounds workable to me.
<infinity> Might be  anice change to the real bootchart package too.  I'm not sure if "I have it installed" should mean "I want to generate a chart on every single boot".
<Mithrandir> yup, it's a one-line change, so.
<Mithrandir> Keybuk: any comment on that?
<infinity> Is that the keybuk who JUST uploaded bootchart? :)
<infinity> (But not with that change)
<Mithrandir> yes
<Keybuk> why would you have it installed if you didn't want bootcharting?
<Mithrandir> uhm, as in just a week ago, just just?
<Mithrandir> you might not want to chart every boot.
<infinity> As in, just a few minutes ago.
<Keybuk> it's annoyingly irritating to add a kernel command-line option to use something you have installed
<Mithrandir> blah
<Keybuk> *shrug* just ignore the charts you didn't want
<Keybuk> it doesn't overwrite them
<Kamion> Mithrandir: how big is bootchart-udeb?
<Mithrandir> it makes the boot slower. :-P
<Keybuk> so?
<Keybuk> only sliiightly slower
<Keybuk> about 1.2s slower for me
<infinity> Yeah, but I assume it slows down the boot process, which is a bit counter-intuitive, given why one installed it. :)
<infinity> Oh, if it's only a second or two, whatever.
<Kamion> for bootchart-udeb it definitely makes sense for it to be optional
<infinity> Indeed.
<Mithrandir> Kamion: -rw-r--r-- 1 tfheen tfheen 1796 2005-11-30 14:41 ../bootchart-udeb_0.9-0ubuntu3_all.udeb
<Keybuk> ubuntu3 is already in the archive ;)
<Mithrandir> Keybuk: that's irrelevant. :-P
<Keybuk> was an update to the right update-initramfs call
<Mithrandir> (in this context)
<Mithrandir> Kamion: so "tiny".  It's a couple of shell scripts.
<Keybuk> did you make java udebs? :)
<Mithrandir> no. :-)
<Mithrandir> so you need to move the data out of the system to get it rendered.
<Keybuk> so the only bit of the package that actually makes a significant impact on the boot isn't there anyway?
<Mithrandir> uhm, remember that it writes this to ramfs-es, and the primary use case is the live CD.
<Mithrandir> hence, it should not run by default, we use too much memory already.
<Keybuk> I guess there's that
<Mithrandir> and boot times on live CDs can easily reach into a few minutes, so the hit will be even bigger.
<Kamion> Mithrandir: ok
<Kamion> Mithrandir: you want it in pkg-lists/base then?
<Kamion> after you fix this
<Mithrandir> Kamion: yes.
<Mithrandir> Kamion: do you require a main inclusion report?
<Kamion> Mithrandir: no, not for new binaries
<Kamion> (from existing sources)
<Mithrandir> the bootchart source isn't in main
<Kamion> oh
<Kamion> yes, will do then
<Keybuk> uggggh
<Mithrandir> Keybuk: ugggh?
<Keybuk> is all of the java stuff I'm using in the real one in main?
<Keybuk> it could drag in a lot if not
<Keybuk> I think I'm using gcj, I cargo-culted most of it though
<Keybuk> rsvg at least is in universe
<Kamion> Keybuk: you're only using java-gcj-compat, which is in main
<Keybuk> also do you provide any script for users to run to turn a bootchart.tgz into a png file?
<Mithrandir> Keybuk: no.
<Keybuk> you should probably do that
<Kamion> librsvg2-bin is in universe, but librsvg2 is in main, so that's a no-brainer to promote
<Keybuk> ok
<Keybuk> not to worry then
<Kamion> it's probably an error that it isn't in main already, in fact
<infinity> Kamion : Still don't have fancy "follow a library to find its debug, doc, and bin stuff" support?
<Keybuk> Kamion: pcmciautils change for you ... dep on (module-init-tools >= 3.2.1-0ubuntu1) and always call "modprobe -ba modules..."
<Keybuk> that way if people put yenta_socket, etc. in the blacklist, it won't get loaded
<fabbione> Kamion: ok, i am done with partman-auto for today. ubuntu2 is up
* infinity gets out and pushes rsync.
<Mithrandir> ok, inclusion report written, now I just need to wait until the new bootchart appears in the archive, so I can merge my changes to it.
<Mithrandir> Keybuk: do you have your ubuntu3 somewhere?  I'm bored of waiting.
<infinity> It'll be on archive.u.c in about 3 minutes.
<infinity> It's on jackass, the trigger just needs to run.
<infinity> I think it was just a three character change, though.  s/ -t// in the postinst.
<infinity> There, mirrored: http://archive.ubuntu.com/ubuntu/pool/universe/b/bootchart/
<Kamion> infinity: not yet
<Mithrandir> thanks
<Kamion> Keybuk: is that liable to hit Debian? (so that I know whether I need to create an Ubuntu branch)
<Kamion> actually, I should probably have an Ubuntu branch anyway
<Mithrandir> though,
<Mithrandir> make: *** No rule to make target `patch-stamp', needed by `build'.  Stop.
<infinity> Kamion : Feel like doing pre-emptive overrides for lrm-2.6.15?
<Kamion> Keybuk: do I need -a to make -b work? I don't actually want wildcarding here
<Kamion> infinity: is elmo not around? I hate munging overrides when I don't have to :)
* infinity pings elmo.
<fabbione> Kamion: so we only miss the last bit.. that's going to be the most annoying one..
<Kamion> infinity: -nvidia-legacy gone away?
<fabbione> Kamion: pvremove -ffy on the right device :)
<Kamion> fabbione: shared.sh is a pretty sucky name, since I'm guessing you have that in /lib/partman/
<Kamion> please rename that to auto-shared.sh or something less namespace-polluting :)
<fabbione> Kamion: yes... /lib/partman/
<fabbione> ahhh crap
<fabbione> i forgot to add the note.. name was clearly up for discussion :/
<fabbione> it's really missing from the changelog :)
<fabbione> sure
<fabbione> will do
<infinity> Kamion : Yup.
<infinity> Kamion : As well as the i386 SMP variants (obviously)
<Kamion> ok, well if elmo doesn't ping back soon, let me know
<infinity> Kamion : And elmo seems decidedly out.
<Kamion> hm, ok
<infinity> 13.5 hours idle with an away message is never a good sign.
<Kamion> infinity: err ... well somebody's at home because lrm just got NEWed
<Kamion> although only the source
<fabbione> Kamion: done :)
<Kamion> fabbione: ta
<fabbione> no problem
<infinity> Kamion : Oo.
<infinity> Kamion : He's being stealthy, then.
<Kamion>   * Stop using crazy *_minor versioning scheme, and just have the oddball
<Kamion>     packages use a scheme of UpstreamVer+SourceVer (ie: 1.0.7676+2.6.15-1)
<Kamion> woo GO INFINITY
<infinity> Keybuk : Congratulations on uploading a (supposedly) 3 character change and making your package FTBFS. :)
<Kamion> ok, I think I'll just do the binaries anyway
<Mithrandir> infinity: it should have FTBFS-ed before too.
<Mithrandir> infinity: I'll handle it.
<Mithrandir> Keybuk: ^^
<infinity> Ahh, it wasn't a change in the current upload, then?
<Mithrandir> nope
<infinity> I'll stop poking fun, then. :)
<Mithrandir> I think he broke it in 0ubuntu1 or something, though.
<Kamion> infinity: ok, binaries should sail through the queue now with any luck
<infinity> \o/
<infinity> I'm really hoping that, modulo one or two very quick bugs, LRM manages to maintain itself for the rest of the release cycle.
<infinity> It's in better shape now, at any rate.
<infinity> And it's a single-edit operation to do ABI bumps.
<infinity> I wonder if it'll build on the arches I didn't test...
* infinity is suddenly paranoid that he didn't bother testing on the PPC machine here.
<fabbione> infinity: YTL anyway
<infinity> Kamion : Do you know if elmo managed to NEW it before cron.daily triggered?
<infinity> Oh, wanna-build is running right now, guess I'll find out in 2 minutes.
<infinity> Yup, it made it.
<Mithrandir> bootchart uploaded, \o/
<Mithrandir> actually, can we have the bootchart package in the live seed?
<Mithrandir> it'll stop bootchart and generate the graph at the end of booting.
<Kamion> sure, if it's (a) done conditionally by a boot arg and (b) not too big
<Mithrandir> it's a noop if bootchart isn't running.
<Mithrandir> the .deb is 97k
<Kamion> ok
<infinity> Damnit, it doesn't build on powerpc.  I jinxed myself.
<Kamion> oh, bigness including dependencies
<Kamion> make sure we already have all the java crap in there ... if not then it's more difficult
<Mithrandir> Kamion: ok, will check
<Mithrandir> bah, unstable != dapper
<Mithrandir> dput should refuse to upload unstable packages to ubuntu
<infinity> Alright, build failure on powerpc is the kernel's fault.
<infinity> New linux-meta is blocking on linux-image -6.8 now.
<infinity> Keybuk : As before, I'll upload udev and linux-meta at the same time, once this is all sorted.
<Mithrandir> Kamion: current live still seems busted from my rootskel breakage?
<Mithrandir> uhm
<Mithrandir> and it thinks Norwegian should default to Macedonian keyboard layout.
<infinity> That seems sensible.
<Mithrandir> localechooser is on crack
<Mithrandir> based on my selection of keys, it thinks de-latin1-nodeadkeys is a sensible choice.
<Mithrandir> heh
<Mithrandir> there's an off-by-one-error somewhere
<Mithrandir> when I select Norwegian from the list, it displays macedonian
<Mithrandir> but it actually is norwegian, since I can type 
<Mithrandir> Kamion: any idea what's up with that?
<Kamion> not offhand, try DEBCONF_DEBUG=20
<Kamion> current live is busted, but I think not from your rootskel breakage? it's waiting on new udev to work properly
<Mithrandir> that too
<Kamion> you can bring it up if you start up udev by hand
<Kamion> (I'm running it over --> there right now)
<Mithrandir> I get raw debconf stuff at my terminal if I don't pass MENU to isolinux
<Mithrandir> looks like localechooser breakage.
<Mithrandir> since it substs in the wrong value.
<Mithrandir> keymap_ask: trans: no-latin1 [...]  SET kbd-chooser/method Makedonsk - mk
<Mithrandir> I guess it's an off-by-one error
<Kamion> that would be kbd-chooser not localechooser surely
<Kamion> probably a missing comma in some debconf template translation
<Kamion> what locale?
<Kamion> sorry, additional comma I mean
<Mithrandir> nb
<Kamion> msgstr "Tsjekkisk, cz-lat2"
<Kamion> ideally that comma would be escaped ...
<Kamion> (in console-data)
<Kamion> hmm, it is escaped
<Mithrandir> also T comes after M
<Mithrandir> and N
<Kamion> the list is sorted according to the msgid, not the msgstr; Czech < Macedonian
<Mithrandir> ah
<Kamion> I think that's it, but I want to know why the comma-escaping isn't working, since there are *lots* of strings like that for various languages in console-data; rather than trying to patch all 133 of them I'd prefer a real solution :)
<Mithrandir> it is escaped in the input to cdebconf.
<Mithrandir> kbd-chooser.c doesn't seem to handle escaping of , at all
<Mithrandir> it just uses strchr
<Mithrandir> are you sure it's supported? :-)
<Kamion> but it doesn't search for , ...
<Mithrandir>                 lim1 = strchr (p1, ',');
<Mithrandir>                 lim2 = strchr (p2, ',');
<Mithrandir> before line 571
<Kamion> SMURFIX
<Kamion> that's an Ubuntu patch
<Mithrandir> heh
<Kamion> fix away if you've got a handle on it; probably wants to walk along the string skipping \<whatever> and *then* checking for ,
<Mithrandir> why isn't that put in upstream?
<Kamion> it's all munged up with the keymapper stuff I think
<Mithrandir> gnrrr
<Mithrandir> I need to go to a shop and fetch some tickets for London, but I'll look at it when I get home.
<Kamion> it's part of kbd-chooser/method which is an Ubuntu patch
<Mithrandir> I know where the bug is, at least.
<Mithrandir> the delta towards debian in the installer on those kinds of things suck. :-(
<Kamion> uh-huh, tell me about it
<fabbione> let's revert * to the original d-i :)
<Mithrandir> speaking of which, had any time to look at the custom widgets stuff?
<fabbione> let's keep only choose-mirror adn we are done
<Kamion> Mithrandir: no :-/
<Mithrandir> I might have time before going to London, I don't know yet.
<Mithrandir> I promised to do an ia32-libs update for bdale tonight, so.
<BenC> Kamion: ping
<Kamion> BenC: pong
<BenC> what is it that needs to be updated for the firmware path changes, hotplug or udev?
<Kamion> hotplug is dead, so udev
<Kamion> but udev already has been AFAIK ...
<Kamion> or at least will be in Scott's new udev
<infinity> No, it hasn't been uploaded.
<infinity> So, firmware is broken until that happens.
<infinity> But we can't upload udev nutil linux-meta is ready to change.
<BenC> it needs to be within 24 hours, so I can complete the linux-meta update
<infinity> Or the world will go tits up.
<BenC> can we upload them at the same time?
<infinity> BenC : I'm doing linux-meta at the same time as I do udev (which is right after LRM builds everywhere)
<BenC> I don't want linux-meta updated until udev is, and vice versa, so this needs to be synced
<BenC> ah, I already had a linux-meta done, since it has changes for {686,k7}-smp targets
<infinity> So, get me a working -6.8 by the time I get up tomorrow, and you'll have it all working when you wake up. :)
<BenC> just pending upload
<infinity> Yeah, I made those same changes here.
<infinity> Oh well. :)
<BenC> ok, then it'll be in your hands
<BenC> what about udev though...we need that for linux-meta
<infinity> <infinity> BenC : I'm doing linux-meta at the same time as I do udev ...
* Kamion watches the conversation going round in pretty little circles
<BenC> doh
<fabbione> lol
* BenC wipes his lcd
* infinity goes to bed to dream of fixed kernel headers. :)
<BenC> infinity: so what about this udev thing? :)
<BenC> ok, so you'll upload lrm, linux-meta and udev in the morning
<BenC> I'll have -6.8 done in a few hours (ahead of time actually)
<Kamion> "it appears to be a white hole"
<BenC> just wanted to be clear on things before I sent the email to u-d-a
<BenC> figure we should warn people before totally destroying their systems
<jbailey> Fixed kernel headers?
<jbailey> Is lkh broken?
<jbailey> Or real kernel headers?
<Keybuk> meh, lost my IRC window
<Keybuk> silly "hide all windows" button
<Keybuk> Kamion: I've sent the modprobe change to Rusty directly, so it may hit Debian via upstream -- Marco also may pick it up.  it's definitely required in our packages though, we actively use the blacklist and encourage people to use it -- and have open bugs already about things like pcmcia ignoring it
<Keybuk> Kamion: the -ba thing is just if you expand a list of modules, -a means "more than one module on the command-line" ... if you just put one argument to modprobe that may be an alias, don't use -a
<Keybuk> infinity: why did bootchart FTBFS?
<Keybuk> infinity: uh, don't upload the udev I gave you on Monday, is verrry broken :)
<Kamion> Keybuk: ok, change made locally, will upload in a bit
<Keybuk> typical usage is something like:
<Keybuk> SUBSYSTEM=="input", PROGRAM="/sbin/grepmap --udev", RUN+="/sbin/modprobe -ba $result"
<Keybuk> where $result is a space-seperated list of the modules grepmap output
<Keybuk> also things like:
<Keybuk> SUBSYSTEM=="scsi_device", SYSFS{type}=="1", RUN+="/sbin/modprobe -b st"
<Keybuk> which loads the st module on tape devices, but lets the user blacklist st if it panics their kernel or something
<Kamion> in this case we only ever load one PCMCIA bridge at a time, so just -b is fine
<Keybuk> yup
<Mithrandir> Keybuk: you hadn't removed the dependency on patch-stamp from the build target
<Keybuk> heh, how did 0ubuntu1 build then? :)
<Mithrandir> nfi
<Mithrandir> 0ubuntu2 never built for me.
<Keybuk> I bet I included patch-stamp in the diff.gz or something silly ;)
<Mithrandir> Is patch willing to create empty files?
<Keybuk> yes
<Keybuk> at least I think so
<Mithrandir> I thought it wasn't.
<Mithrandir> : tfheen@xoog /tmp > mkdir a b
<Mithrandir> : tfheen@xoog /tmp > touch a/file
<Mithrandir> : tfheen@xoog /tmp > diff -Nru a b
<Mithrandir> : tfheen@xoog /tmp >
<Mithrandir> doesn't look like it.
<Keybuk> Kamion: ping
<Kamion> Keybuk: pong
<Keybuk> Kamion: could you drop hotplug from ubuntu-meta and upload nowish
<Kamion> uh, ok, give me ~10 minutes
<Keybuk> ok
<Kamion> (have to merge everywhere etc.)
<Keybuk> yah
<Keybuk> I doubt udev will hit this cron.daily
<Kamion> er ... we don't have new linux-meta yet?
<Kamion> will this break the world?
<Keybuk> correct
<Keybuk> some bits of it
<Keybuk> mdz exercised his "DOIT" option
<Kamion> ok
<Keybuk> (I'm updating linux-meta now)
<Keybuk> it'll break lrm users, and adam will need to clean the coffee from his monitor and keyboard in the morning <g> but otherwise should be ok
<Kamion> breaking lrm will break the installer too of course
<Kamion> but the installer will probably be broken anyway for a bit
<Kamion> Keybuk: ubuntu-meta uploaded
<Kamion> I'm keeping grepmap-udeb, right?
<Keybuk> right
<Keybuk> of course, I could always PUT THE MODPROBE RULES INTO THE UDEB
<Keybuk> la la la
<Kamion> that would be nice ;-)
<Kamion> d-i ready-ish to upload
<Kamion> so should the installer be using udevplug -W after installing new modules on the system?
<Kamion> (i.e. is -W the right option to use?)
<Keybuk> it can do, certainly
<Keybuk> where "installing new modules" == "modprobe calls"
<Kamion> no, as in udpkg -i foo-modules.udeb
<Keybuk> right
<Kamion> well, and then modprobe calls, yeah
<Keybuk> you could do: udevplug -f
<Kamion> not documented
<Keybuk> if the original modprobes failed
<Kamion> -F?
<Keybuk> sorry
<Keybuk> -F
<Kamion> it's not really to catch failure, it's to wait for things to settle
<Keybuk> but the original modprobes may not have failed if the alias did cause some generic device to be loaded
<Keybuk> just adding modules to the filesystem won't do anything
<Keybuk> you could do a "udevplug" to replay all the events and see if any of them benefit from the new modules
<Kamion> right, yeah
<Kamion> hmm, yeah, that might make sense actually
<Keybuk> udevplug    - replay everything (new rules, new modules, etc.)
<Keybuk> udevplug -F - replay everything that's explicitly failed
<Keybuk> udevplug -W - wait for udev to settle (useful after manual modprobes)
<Kamion> this is going to hit upstream, right?
<Kamion> so I can safely check stuff into d-i upstream?
* Kamion does an enormous grep
<Keybuk> it might do
<Kamion> er, ok, maybe I'll make it Ubuntu-local for now then
<Keybuk> we're testing it for upstream
<Keybuk> the udevd side of it is already upstream
<Keybuk> (ie /dev/.udev/queue and /dev/.udev/failed are in upstream already)
* Keybuk spots a comic error in the udevplug manpage
* HiddenWolf notices that quite a few people who went for a test-reboot haven't reported in yet.
<Nafallo> I did
<Nafallo> can
<Nafallo> can't mount root since /dev/hda2 in non-existant :-)
<HiddenWolf> hah
<HiddenWolf> now that's a bit of an inconvenience.
<Nafallo> I need Keybug ;-)
<Nafallo> ehm, Keybuk even
<HiddenWolf> freudian.
<Keybuk> oh, why doesn't it exist?
<Nafallo> ide-disk seems to make it exist :-)
<Nafallo> but then udevplug can
<Nafallo> 't run since grepmap isn't in the initramfs
<Keybuk> grepmap isn't used for that
<Keybuk> it's not a mouse
<Keybuk> and I assume you're not running on an s/390
<Nafallo> oh? it screamed at me when I runned udevplug manually :-)
<Keybuk> *shrug* I didn't cut down the errors yet
<Keybuk> modprobe ide-disk does the right thing?
<Nafallo> yes
<Nafallo> makes hda1, hda2 and disk come to life :-)
<Nafallo> in /dev
<Keybuk> right
<Keybuk> what does echo "" > /sys/block/hda/uevent do?
<Keybuk> does that also create hda1, hda2, etc.?
<Nafallo> without modprobeing ide-disk you mean?
<Keybuk> right
<Nafallo> /bin/sh: cannot create /sys/block/hda/uevent: Directory nonexistent
<Keybuk> does "udevplug -Bpci -Iclass=0x010[01] *" cause /sys/block/hda to appear?
<Nafallo> nope
#ubuntu-boot 2005-12-06
<Keybuk> interesting
<Keybuk> do you have a /proc/ide ?
<Nafallo> yes, with "drivers ide0 hda ide1 hdc" in it
<Keybuk> *blink*
<Nafallo> agreed :-P
<Keybuk> so you have /proc/ide/hda but not /sys/block/hda ?
<Keybuk> how about /sys/block/hdc ?
<Nafallo> /sys/block has only ram[0-15] 
<Keybuk> right
<Keybuk> cd /sys/devices/*/*/ide0
<Keybuk> pwd
<Keybuk> what does that say?
<Nafallo> cd: 10: can't cd to /sys/devices/*/*/ide0
<Keybuk> sweet
<Keybuk> uh
<Keybuk> find /sys -name ide0
<Keybuk> I guess you don't have find though
<Nafallo> indeed :-)
<Keybuk> look for /sys/devices/*/ide0 */*/ide0 */*/*/ide0 etc.
<Nafallo> (don't have it)
<Nafallo> /sys/devices/ide0
<Keybuk> top-level like that?!
<Nafallo> yepp :-)
<Keybuk> cd into that
<Keybuk> and do an ls for me
<Nafallo> uevent power 0.0
<Keybuk> ok ls -l 0.0/bus
<Nafallo> lrwxrwxrwx  1 0  0  0 0.0/bus -> ../../../bus/ide
<Keybuk> ls 0.0
<Nafallo> uevent power bus
<Keybuk> ok, try echo "" > /sys/devices/ide0/uevent
<Kamion> (why do you always echo "" rather than plain echo anyway? :-))
<Keybuk> (or udevplug /sys/devices/ide0/uevent)
<Keybuk> Kamion: dunno
<Keybuk> udevplug /sys/devices/ide0 I mean
<Keybuk> but anyway
<Keybuk> WRITE TO THAT FILE
<Keybuk> <g>
<Nafallo> I think /dev/ttya[0-2]  came out of that.
<Keybuk> ksdgjs9gu8281
<Nafallo> or rather, they are the last ones ;-)
<Keybuk> heh
<Keybuk> you still don't have /sys/block/hda ?
<Nafallo> nope
<Nafallo> :-P
<Keybuk> try udevplug /sys/bus/ide/0.0
<Nafallo> no change
<Keybuk> meh
<Keybuk> well, you haven't got an IDE controller
<Keybuk> apparently
<Nafallo> I can prove I have it by modprobe ide-disk ;-)
<Nafallo> and so can ogra on his beauty ;-)
<Keybuk> what kind of machine do you and ogra have in common?
<Nafallo> ogra: amd64, no?
<Nafallo> amd64 laptop here
<Keybuk> SATA ?
<Nafallo> http://www.magicalforest.se/darkelf
<Nafallo> nope, PATA-100
<Keybuk> ok
<Keybuk> try udevplug -Bpci
<Keybuk> see if that makes /sys/block/hda
<Nafallo> nope
<Keybuk> udevplug
<Keybuk> (without any arguments) ?
<Nafallo> udevd-event[17175] : run_program: exec of program `/sbin/grepmap` failed
<Nafallo> hence why I said that was missing :-P
<Keybuk> yeah, that's just an annoying bitch I'm going to get rid of at some point
<Nafallo> :-)
<Keybuk> any /sys/block/hda though?
<Nafallo> nope :-P
<Keybuk> ok
<Keybuk> well that means you have nothing on your system that claims to be an IDE controller
<Keybuk> iz kernel bug
<Keybuk> is ide-generic loaded?
<Nafallo> where can I check? :-)
<Nafallo> lsmod not found :-P
<Keybuk> grep generic /proc/modules
<Nafallo> ide-generic and ide-core is loaded, yes :-)
<Nafallo> fwiw: ACPI registers the ide-bus in init-premount.
<Nafallo> ide-disk then finds hda
<Keybuk> ACPI?
<Nafallo> yes
<Keybuk> why is that "registering" the disk?
<Keybuk> that just loads fan and thermal
<Nafallo> ...]  ACPI: bus type ide registered
<Keybuk> you have nothing that says you need to load ide-disk
<Keybuk> ie. the kernel hasn't found any ide devices
<Keybuk> but it claims to have, as there's things in /proc/ide
<Keybuk> which driver is it?
<Keybuk> (it'll be one of the things hanging on to ide-core)
<Nafallo> via82cxxx is memory provides
<Keybuk> is that loaded?
<Nafallo> nope
<Keybuk> ah, interesting
<Keybuk> modprobe -r ide-generic
<Keybuk> then modprobe via82cxxx
<Keybuk> then modprobe ide-generic again
<Nafallo> yes? :-)
<Keybuk> did that do anything?
<Nafallo> said averything IDE was brought up (the usual kernelmessages)
<Keybuk> did you get a /dev/hda ?
<Nafallo> but no /dev/hda* or anything :-P
<Keybuk> /sys/block/hda ?
<Nafallo> nope
<Keybuk> hmm
<Keybuk> it could be buggered up by loading ide-generic first
<Keybuk> that does evil things to the kernel
<Keybuk> but you got a lot of the IDE things by loading the via82cxxx module?
<Nafallo> not lots, that ACPI registered the bus..
<Nafallo> if I load ide-generic I get lots
<Keybuk> right
<Keybuk> ok
<Keybuk> grep 1106 /sys/bus/pci/devices/*/vendor
<Nafallo> 12 lines :-)
<Keybuk> right
<Keybuk> look at the /device files for each of them
<Keybuk> they'll each have 4-digit numbers/letters
<Keybuk> could you type them each here
<Nafallo> shouldn't I be able to find out which one it is by grepping? :-)
<Keybuk> no, clearly you have one that isn't registered
<Keybuk> so I want the ids so I can google for them <g>
<Nafallo> hehe
<Nafallo> 3177
<Nafallo> 0571
<Nafallo> 3059
<Nafallo> 3068
<Nafallo> any hit yet? :-)
<Keybuk> carry on
<Nafallo> 3065
<Nafallo> 3044
<Nafallo> b188
<Nafallo> 3188
<Nafallo> 3038
<Nafallo> same on all 00:10.*, so USB I guess
<Keybuk> ok
<Keybuk> could you note down the sysfs path to the one that's 0571
<Keybuk> then once done, reboot and put break=top onto the kernel command-line
<Keybuk> so you're given a shell in the initramfs, rather than it failing
<Nafallo> /sys/bus/pci/devices/0000:00:11.1/device
<Keybuk> k
<Keybuk> so reboot, with break=top, so we're in a fresh shell with no modules loaded
<Nafallo> ey! you are reading my notes-to-self :-P
<Keybuk> hmm?
<Nafallo> oki, I'm there.
<Keybuk> right
<Nafallo> you told me to take a note ;-)
<Keybuk> if you're on a laptop ... modprobe fan and modprobe thermal now <g>
<Nafallo> hehe, done
<Keybuk> run UDEV_LOG=info /sbin/udevd --daemon
<Nafallo> done
<Keybuk> ok, now can you verify a few things for me, if not true, can you say what you see
<Keybuk> /sys/bus/ide/devices is either empty or non-existant
<Keybuk> grep via82cxxx /proc/modules shows nothing
<Keybuk> /sys/bus/pci/devices/0000:00:11.1/vendor is 1106
<Keybuk> /sys/bus/pci/devices/0000:00:11.1/device is 0571
<Nafallo> all true
<Keybuk> /sys/bus/pci/devices/0000:00:11.1/class is 0x010000
<Nafallo> not true
<Keybuk> what is it?
<Nafallo> 01018a
<Keybuk> with or without an 0x on the front?
<Nafallo> 0x01018a :-)
<Keybuk> right, that's quite important :p
<Nafallo> hehe, oki :-). all of them has that if not said otherwise ,-)
<Keybuk> /sys/bus/pci/devices/0000:00:11.1/modalias should begin pci:v00001106d00000571sd... yes?
<Keybuk> yeah, that's ok, just checking on that one in particular
<Keybuk> also does it end bc01sc01i8a ?
<Nafallo> not sd, sv
<Keybuk> right, sorry, typo
<Nafallo> sd00002032bc01sc01i8a
<Keybuk> cool
<Keybuk> now, /sys/block/hda should not exist
<Keybuk> also /sys/devices/ide0 should not exist
<Keybuk> and /proc/ide should not exist
<Keybuk> are all those true?
<Nafallo> yes indeed
<Keybuk> right
<Keybuk> udevplug -Bpci -Iclass=0x010[01] *
<Keybuk> that should do a bunch of stuff on your screen, any of it interesting?
<Nafallo> it didn't :-P
<Keybuk> did nothing?
<Nafallo> did nothing...
<Keybuk> not even a grepmap bitch?
<Nafallo> not even the bitch :-)
<Keybuk> grep via82cxxx /proc/modules still shows nothing ?
<Nafallo> cat /proc/modules: unix thermal processor fan
<Keybuk> right
<Keybuk> udevd is running?  (ps ax)
<Nafallo> yepp
<Keybuk> udevplug /bus/pci/devices/0000:00:11.1
<Keybuk> does that do anything?
<Nafallo> you forgot /sys, right?
<Keybuk> doesn't matter, is optional
<Nafallo> did nothing
<Keybuk> how about just
<Keybuk> echo > /sys/bus/pci/devices/0000:00:11.1/uevent
<Nafallo> udevd-event output :-)
<Keybuk> any of it interesting?
<infinity> Keybuk ; Dude.  You updated linux-meta while powerpc was still fucked?
<Keybuk> infinity: yes, mdz said to :)
<Nafallo> lol
<Nafallo> /sbin/modprobe -Q pci:v....
<Keybuk> Nafallo: see, now that is interesting
<Keybuk> do you now have any of /sys/block/hda, /sys/devices/ide0, /proc/ide/hda/media, /dev/hda ?
<Nafallo> /sbin/modprobe (stderr) and the usage note :-P
<Keybuk> huh why usage note?
<Nafallo> is the line after that one...
<Nafallo> so status 1 on modprobe...
<Keybuk> uh
<Keybuk> /sbin/modprobe -Q fan
<Keybuk> ^ what does that do?
<infinity> Keybuk : Ahh, yeah, just read backscroll.
<Nafallo> usage message..
<Nafallo> -q maybe?
<Keybuk> no, definitely -Q
<Keybuk> so, could you do something for me
<Keybuk> modprobe ide-disk
<Keybuk> mount /dev/hda1 (or whatever your root/var is) /root
<Nafallo> ls /dev still shows console and null only
<Keybuk> *giggle*
<Keybuk> OH I SEE THE PROBLEM
<Keybuk> module-init-tools FTBFS
<Nafallo> eeh? :-P
<Keybuk> bloody patch systems
* Nafallo breathes in
<Nafallo> ...and out
<Keybuk> ok
<Keybuk> soooo, here's how to boot your machine
<Keybuk> boot with break=premount
<Keybuk> . conf/initramfs.conf
<Keybuk> . scripts/functions
<Keybuk> scripts/init-premount/acpid
<Keybuk> udevd --daemon
<Keybuk> udevplug /class/mem /class/misc /class/tty /class/vc /block
<Keybuk> modprobe via82cxxx
<Keybuk> modprobe ide-disk
<Keybuk> modprobe ide-generic
<Keybuk> (this should get you /dev/hda*)
<Keybuk> udevplug -W
<Keybuk> mountroot
<Keybuk> run_scripts scripts/init-bottom
<Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
<Keybuk> --
<Nafallo> mountroot not found :-P
<Keybuk> did you do the ". scripts/functions" bit?
<infinity> Keybuk : Shall I fix module-init-tools while you're helping Nafallo get unfucked?
<Keybuk> oh
<Keybuk> sorry
<Keybuk> . scripts/$BOOT
<Keybuk> mountroot
<Keybuk> infinity: already uploaded
<infinity> Ahh, cool.
<Nafallo> :-)
<Nafallo> thanx :-)
<Keybuk> booted?
<Nafallo> yepp
<Nafallo> and had more fun than ever on the way :-)
<Keybuk> right
<Keybuk> NOW BEFORE YOU GO
<Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1-0ubuntu3_i386.deb
<Keybuk> actually
<Keybuk> that's the wrong arch for you isn't it <g>
<Keybuk> uh
<Nafallo> hehe, it is :-)
<Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1-0ubuntu3.diff.gz
<Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1-0ubuntu3.dsc
<Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1.orig.tar.gz
<Keybuk> grab those three down, dpkg-source -x, dpkg-buildpackage -rfakeroot -b -uc -us, install module-init-tools
<Keybuk> then check that "/sbin/modprobe -Q fan" does NOT give you a usage error :p
<Nafallo> hmm, where is my network? ;-)
<Keybuk> ifup
<Keybuk> that's a known problem
<Keybuk> it's in the release notes
<Nafallo> I thought network-manager would take care of that ;-)
<Keybuk> maybe
<Keybuk> either way, it's on my list todo, just a few items down
<Nafallo> just shout if you need testing :-)
<Keybuk> let's first get you booting without error :p
<Keybuk> got that built yet?
<Nafallo> just wgeted and gave it to pbuilder :-)
<Nafallo> oki, rebooting :-)
<Nafallo> hmm, same error...
<Nafallo> I don't have to run update-initramfs manually or something?
<Keybuk> I actually just meant that you should run /sbin/modprobe before rebooting <g>
<Keybuk> but yes, you would need to run update-initramfs
<Nafallo> I thought packages would do that these days ;-)
<Nafallo> anyway, booted via the long command method again ;-)
<Nafallo> no usage error :-)
<Nafallo> sudo update-initramfs -u and then reboot again :-)
<Nafallo> wow! "Mounting root file system     ok"
<Nafallo> :-)
<Nafallo> thanx Keybuk! I'll post fresh bootcharts shortly :-)
<Nafallo> even network works now ;-)
<Nafallo> yay! my battery works :-)
<Nafallo> http://www.magicalforest.se/~nafallo/bootchart/dapper-20051201-3.png
<fabbione> guys can we have a FEW WORDS?
<fabbione> infinity: this upgrade is the disaster
<fabbione> RAID and network are gone
<fabbione> infinity: nvidia is broken on amd64
<fabbione> + we load some fb modules that conflicts heavily with nvidia
<fabbione> removing the fb modules makes no good
<fabbione> nvidia either crashes or it manages to start X but it kills console
<fabbione> i think bootchart it's taking ages to release to console
<fabbione> but that's not a big deal
<fabbione> grepmap seems to be broken too
<infinity> fabbione : Hrm.  nvidia works for me on amd64 (both legacy and current), but I tested it before the new udev and stuff when in.
<fabbione> yes, the problem seems to be either usplash or initramfs that are loading too many fb modules
<infinity> fabbione : I'll have to test again after I upgrade evrything, but more concrete stuff than "it doesn't work" would be helpful, I think.
<infinity> (And I'm using usplash with vga16fb on that machine, ie: a default setup)
<fabbione> for what i can see other than the fb modules problems, nvidia kills switching to console
<fabbione> and it kills the machine if loading it directly without the fb modules
<fabbione> it's kind of a mess that will need more debugging
<infinity> Fun.  What kind of card do you have?
<infinity> I've only been able to test on my 6800GT.
<fabbione> 0000:00:0e.0 VGA compatible controller: nVidia Corporation NV17GL [Quadro4 200/400 NVS]  (rev a3)
<fabbione> 0000:01:00.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti 4600]  (rev a3)
<fabbione> it has 2 cards
<infinity> So, if you boot with "nosplash", everything's okay?...
<infinity> Or it dies in different ways?
<infinity> (And have you tried with -legacy?... While your cards don't technically need it, they are older, so are more likely to run afoul of bugs in the new drivers, which are being aimed at 6/7 series stuff)
<fabbione> if i boot with nosplash the machine freezes
<fabbione> no, i didn't try -legacy yet
<infinity> Er,, not sure if it's "nosplash", or just removing "splash" from the command line.  Probably the latter, actually.
<fabbione> yeah i did try the recovery mode
<fabbione> and usplash was not loaded
<fabbione> it might as well be a problem with the sequence in which modules are loaded
<fabbione> because unloading fb stuff and loading nvidia works
<fabbione> so it's kind of weird
<infinity> Very fun.  I'll test again later tonight after a full upgrade.
<fabbione> ok
<infinity> I fear it may be specific to your setup, though.  So if I can't reproduce it at all, I'll whine at you to help.
<fabbione> yeah of course
<fabbione> i would like at least to get RAID/network back first
<fabbione> because they are truely annoying to start manually at each boot
<infinity> You did upgrade everything, right?
<fabbione> yeps
<infinity> Well, damn. :)
<infinity> Blame keybuk.
<fabbione> heheh
<fabbione> infinity: do you plan a php5 upload soon?
<fabbione> there is the libsnmp5 -> 9 transition
<fabbione> it's the only pkg in main left
<fabbione> i just did hplip
<infinity> Yeah, it's happening soon for other reasons.
<fabbione> ok
<infinity> ARGH.
<infinity> fabbione : <poke>
<fabbione> ?
<infinity> fabbione : Are you getting some nvidia-specific framebuffer module loaded?
<infinity> fabbione : After upgrading everything and rebooting, I've noticed that something is now loading radeonfb magically for me, which is very clearly a bug.
<infinity> If that's happening for you (but with the nv equivalent), that's the real problem.  And I'm pretty sure it's the new udev's fault.
<fabbione> yes it is happening for me to
<fabbione> it loads radeon and nvidia fb
<infinity> Both?
<infinity> You have an ATI in there too?
<infinity> Or is it doing something even more wrong than wrong?
<fabbione> nope
<fabbione> no ati on this box
<fabbione> sorry i meant riva
<infinity> Oh, phew.
<infinity> Kay.
<infinity> Still very wrong, but at least that one makes sense. :)
<fabbione> [  235.360791]  NVRM: The NVIDIA probe routine was not called for 2 device(s).
<fabbione> [  235.360796]  NVRM: This can occur when a driver such as rivafb or rivatv was
<fabbione> [  235.360798]  NVRM: loaded and obtained ownership of the NVIDIA device(s).
<fabbione> [  235.360802]  NVRM: Try unloading the rivafb (and/or the rivatv) kernel module
<fabbione> [  235.360804]  NVRM: (or reconfigure your kernel without rivafb support), then
<fabbione> [  235.360805]  NVRM: try loading the NVIDIA kernel module again.
<fabbione> [  235.362873]  NVRM: No NVIDIA graphics adapter probed!
<fabbione> this one repeated several times
<infinity> Yeahp.
<fabbione> it clearly goes away as soon as i rmmod riva
<infinity> I'm getting the same here with conflicts between radeonfb and fglrx.  Which, of course, shouldn't be happening, because radeonfb and rivafb shouldn't be autoloaded.
<infinity> I'll be sure to yell at keybuk when he returns.
<fabbione> ehehehe
<infinity> For now, you could blacklist rivafb, but having framebuffers hot/coldplugged at all is just sick and wrong, given that most of them are biuggy as hell.
<fabbione> i argee
<fabbione> agree
<fabbione> and i can wait for Keybuck to fix
<fabbione> i am not going to reboot this machine anytime soon anyway
<Mithrandir> Kamion: I'm going to waste a little time today trying to get our custom widget stuff upstream as well as our kbd-chooser changes.  Ok?
<fabbione> hmmm
<fabbione> Kamion: the pvremove -ffy solution doesn't solve all the problem :/
<fabbione> i need to do a clean lvm removal
<fabbione> actually
<fabbione> no
<fabbione> i can be WAYYYY more evil :)
<Kamion> Mithrandir: cool, thanks
<Kamion> fabbione: ok ...
<Kamion> fabbione: I'm going to do a partman-auto-lvm upload to Debian in a moment; you'll need to merge that or your world will stop working
<Kamion> fabbione: oh, uh, you've been doing lots of stuff too, hmm
<Kamion> I guess it's not safe to upload at the moment
<Kamion> fabbione: if you want udev stuff to keep working with the new installer world order, merge r32609 from d-i svn; if you don't care, feel free to wait :)
<fabbione> Kamion: all the changes are the same we have in ubuntu
<fabbione> and all tested
<fabbione> if you want to upload pal you need to upload partman-auto too
<fabbione> Kamion: if you are talking about the udev bits, it's no problem... i can merge them easily
<fabbione> it's just 2 lines
<fabbione> my head is exploding
* fabbione takes a break
<pitti> Hi Keybuk
<Keybuk> happy mailman day
<pitti> Keybuk: I have some juicy udev bugs to talk about, when you have a minute?
<Keybuk> sure, give me a few minutes to get my eyes open
<pitti> and some coffee? :)
<Keybuk> yes that too
<Kamion> fabbione: right, it's just to call update-dev
<Kamion> the old udevstart/udevsynthesize calls in p-a-l and elsewhere (apart from update-dev itself) will go away soon
<Kamion> is anyone doing new linux-meta for the new ABI?
<makx> udevsynthesize is nice for < 2.6.15
<Kamion> makx: yes that's why they'll stay in update-dev
<Kamion> please, I know what I'm doing :-)
<Kamion> well, sometimes
<makx> np was just a remark, not looked in an updeate-dev yet-
<fabbione> Kamion: no, because we need new LRM for the new ABI
<fabbione> oh it's in..
<Kamion> binaries aren't in yt
<Kamion> ah, new
<Kamion> ok, I'll process the new binaries
<Kamion> oh, god, no I won't, newing l-r-m gives me a vicious headache, I'll wait for elmo
<Kamion> whoa, rebooting just after installing new udev is indeed ultra-messy
<Keybuk> d-i reboot, or ordinary reboot?
<Kamion> ordinary reboot
<Kamion> the bazillion udevsend errors scrolling down the console
<fabbione> Keybuk: check today's log for this chan
<fabbione> i also have several issues
<Kamion> hmm, no /dev/sda1 here ...
<Keybuk> udevsend errors?
<Keybuk> there's no such thing as udevsend
<Keybuk> (it's not used)
<fabbione> raid/network and other stuff are clearly no go
<Kamion> my machine begs to differ
<Kamion> I probably have udevsend in /proc/sys/kernel/hotplug
<Kamion> s/have/had/
<Kamion> hunger mentioned the same thing on #ubuntu-devel
<Keybuk> that should get cleared in initramfs
<Keybuk> unless something else is putting it back, of course
<Kamion> it's *before* reboot
<Kamion> as in, just upgraded from breezy-ish udev to current, then went to reboot
<makx> did that update your initramfs?
<Kamion> makx: yes, and it's totally irrelevant because the errors were BEFORE REBOOT so the new initramfs hadn't been started yet
<Keybuk> oh
<Keybuk> yeah
<Keybuk> that'd go boom
<Kamion> ok, anyone fancy walking me through figuring out why I'm not getting /dev/sda1 in the new initramfs? SATA
<Keybuk> could be that no modules are being loaded
<Kamion> udevplug puts it in
<Keybuk> the easiest way to do it is to boot with break=mount
<Keybuk> see if you have /dev/sda1
<Keybuk> if not, try udevplug -Bpci
<Keybuk> then see if you have /dev/sda1
<makx> btw nice "break=foo" patch Keybuk. :)
<Kamion> Keybuk: I don't even get a shell - I get "Spawning shell within the initramfs" and then a blinking cursor
<Keybuk> huh?  weird
<Keybuk> maybe you have to wait for usplash to die or something
<Kamion> oh, the shell is in tty8
<Kamion> that's helpful, not
<Kamion> no /dev/sda1 to start with, but udevplug -Bpci creates it
<Keybuk> ok, excellent
<Keybuk> is there a /sys/block/sda1/device symlink?
<Keybuk> it might be /sys/block/sda/sda1/device
<Keybuk> or /sys/block/sda/device
<Kamion> /sys/block/sda/device is there
<Keybuk> ok
<Keybuk> readlink/ls -l that and it should point to a pci device
<Keybuk> cd into that (you can just cd /sys/block/sda/device) and pwd to make sure it's the right device
<Keybuk> then cat vendor device class
<Keybuk> and give me those three numbers :)
<Kamion> /sys/devices/pci0000:00/0000:00:0f.0/host0/target0:0:0/0:0:0:0
<Kamion> vendor says ATA, device and class are missing
<Keybuk> oh, interesting
<Keybuk> try in ../../..
<Kamion> 0x1106
<Kamion> 0x3149
<Kamion> 0x010400
<Keybuk> aha!
<Keybuk> PCI_CLASS_STORAGE_RAID :)
<Kamion> le huh?
<Kamion> nobody told me it was RAID :)
<Keybuk> not PCI_CLASS_STORAGE_SCSI
<Keybuk> rightio
<Keybuk> can you file a bug saying something like "load all storage controllers in initramfs, not just IDE/SCSI ones"
<Kamion> ok
<Keybuk> you can boot that machine now with:
<Keybuk> . conf/initramfs.conf
<Keybuk> . scripts/functions
<Keybuk> . scripts/$BOOT
<Keybuk> mountroot
<Keybuk> run_scripts scripts/init-bottom
<Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
<Kamion> #20339
<Kamion> boots fine now, thanks
<pitti> l
<fabbione> Kamion: new p-a-l uploaded
<fabbione> with the udev crack changed
<Kamion> ta
<infinity> Keybuk : Hey, has anyone yelled at you about framebuffers, yet?
* fabbione joins infinity on the crusade against fbs
<infinity> Keybuk : I can only assume this is the new udev at fault, but it appears to be hot/cold-plugging framebuffers, based on installed hardware, so all ATI users get radeonfb loaded, nv users get rivafb, etc.  THis is pretty horribly broken.
<infinity> Keybuk : Since most of these framebuffers are buggy, break suspend/resume, and break their X driver counterparts.
<Keybuk> it's in the release notes :)
<Keybuk> (which I've yet to send, but still)
<Keybuk> yes, I know framebuffer devices are loaded
<Keybuk> I also have a bug assigned to me saying we should load framebuffer devices
<Keybuk> I'm also aware that we might not want to
<Keybuk> basically they need blacklisting
<fabbione> Keybuk: you are perfectly convinced you don't want to load them
<Keybuk> and I'm not sure the elegant way to do that
<fabbione> it breaks MY workstation
<fabbione> badly
* fabbione modprobes godfather.ko
<fabbione> Keybuk: or i will have to make you an offer you can't refuse
* fabbione rmmods godfather
<infinity> Keybuk : Was the bug filed by anyone with clue, or just someone who wants whizbang features?
<infinity> Keybuk : Bottom line is that most framebuffers break just about everything else we do.
<Keybuk> *nods*
<Keybuk> soo... how do we blacklist them?
<makx> fabbione: hch needs a test for sbus sysfs debian -> #341522
<Keybuk> do we maintain a byhand list of framebuffer drivers?
<infinity> Keybuk : why were they not being loaded before, but are now?  That might be a good place to start.
<Keybuk> there was a skip in the old hotplug shell code
<infinity> And can we not replicate that behaviour on the new world order?
<Keybuk> I'd like to do it with a blacklist file now
<fabbione> makx: i don't run debian on my sparc.
<fabbione> can't test
<infinity> But we blacklist based on module name, not subsystem.  Much more of a pain in the ass to maintain.
<makx> fabbione: he'll send you a kernel patch
<infinity> Or can we blacklist in more clever ways?
<infinity> Kamion : I realise you don't want to touch lrm NEW cause LRM is icky and makes your head hurt, but can you NEW the ia64 kernel binaries, so LRM can build there? :)
<fabbione> makx: still.. can't test.. my sparc is buildd.. not a test machine
<Keybuk> rumout has it that we can do something like:
<fabbione> makx: plus he perfectly knows how to find me :)
<makx> fabbione: ok hehe trave11er will do
<Keybuk> install pci:v*d*sv*sd*bc03*sc*i* /bin/true
<Kamion> infinity: (it's specifically icky because lisa can't handle l-r-m directly due to the d-i bits.)
<Keybuk> that's pretty ugly though
<Keybuk> we could also do that with SUBSYSTEM=="pci", SYSFS{class}=="0x03*", GOTO="modprobe_end"
<infinity> Keybuk : I'd prefer to avoid line nois ein config files.
<infinity> Keybuk : Though, something that ugly is unlikely to be touched by users, which may be a win..
<Kamion> infinity: doing now
<Keybuk> another option is to generate /etc/modprobe.d/display_class automatically in kernel postinst
<fabbione> UH UH
<fabbione> go udev!
* fabbione sighs
<fabbione> no actually.. that would be initramfs too
<infinity> Keybuk : Is there any reason to not just patch things to skip that particular class, other than the off chance that some user, somewhere, might really want to coldplug his framebuffers without using /etc/modules?
<Keybuk> infinity: patch what? :)
<infinity> Whatever enumerates incoming *plug events and decides to call modprobe?
<infinity> I'm not the one who packaged this, I don't pretend to know the code. :)
<Keybuk> well, the kernel generates uevents
<Keybuk> we could patch the kernel to not generate events for display devices
<infinity> Right, then?
<infinity> What catches the events?... udev?
<Keybuk> but it's slightly less intrusive to just not build the framebuffer devices in the first place
<infinity> And then udev calls modprobe if it thinks it should?
<Keybuk> yes, udev catches the events, looks them up in sysfs and processes it
<Keybuk> we could add a udev rule to skip modprobe for display devices
<infinity> Right, so udev should be the one skipping the events, if it knows the device class.
<Keybuk> udev calls modprobe
<Keybuk> with a device alias
<Keybuk> modprobe can blacklist devices from matching a particular alias
<Keybuk> (like we do for things like eepro100 and stuff)
<Kamion> infinity: Accepted 1 package set, 146 MB.
<infinity> Yeah, but that percludes someone calling modprobe manually.
<Keybuk> no, it doesn't
<infinity> We just don't want udev automagically doing it, we don't want to stop users from doing it.
<Keybuk> modprobe only applies it's blacklists to alias expansion
<Keybuk> modprobe eepro100  still works
<Kamion> (unless you use -b, right?)
<Keybuk> modprobe pci:blahblahforaneepro100 is what gets blacklisted
<Keybuk> right
<Keybuk> modprobe -b eepro100 is "load eepro100 only if it's not blacklisted"
<Keybuk> ...
<Kamion> incidentally, please document -b in the man page, kthxbye :)
<infinity> Well, I leave it in your hand to implement where/how you think works best.
<Keybuk> I'd rather we did this at the modprobe level, because it's the least surprising way
<Keybuk> and it's consistent with other things where we've decided not to load modules
<infinity> I just want it to work, and I don't want anything that requires maintaining manual lists.
<Keybuk> right
<infinity> (Or something so user-obvious "Oh, look this blacklists framebuffers, I don't want that!" that users will delete it, not know how to get it back, and file tons of bugs cause X broke)
<Keybuk> do you have anything against a list updated in a postinst?
<infinity> Yes, I'm evil.
<Keybuk> infinity: if users shoot themselves in the foot, they will shoot themselves
<Keybuk> either way this will be in a conffile
<infinity> I don't think hotplugging framebuffers is ever "right", so I'd really just not allow it.
<infinity> Kamion : Thanks, BTW.
<Kamion> np
<Keybuk> of course, it's impossible to accurately identify framebuffer drivers *shrug*
<infinity> Then how did hotplug manage?
<infinity> Rough guessing that was mostly true?
<Keybuk> hotplug did it by device
<infinity> All video devices?
<infinity> That would work for us, since the only other things that vaguely relate to video devices are slave drivers to X drivers, which load (or are supposed to) when X loads.
<Keybuk> right, that was always the drawback
<Keybuk> there were various hotplug bugs where it didn't load some other driver
<Keybuk> like capture cards, etc.
<Keybuk> all-in-one cards didn't work at all without manual driver loading
<Kamion> Keybuk: udev-udeb being hard to type> I feel your pain
<Kamion> I can only type "udev" accurately one time in three
<Keybuk> the udeb was missing lots of files because they were in debian/udeb-udev and debian/udev-udev and friends
<Kamion> heh
<ogra> hi
<Keybuk> ok
<Keybuk> so let's first get your system to a useful point to play
<Keybuk> your problem is that "your root filesystem is on a network device, and no network driver is loaded", is that correct?
<ogra> i tried to replace the line that was there, as well as just ading your line
<ogra> yup
<Keybuk> ok, good
<Keybuk> put that script back how it was, just the -Bpci -Iclass=0x01* line
<Keybuk> update-initramfs
<ogra> it loads the same set of modules in both cases
<Keybuk> then reboot, and add break=mount to the kernel command-line (remove splash for sanity)
<jbailey> Keybuk: Is this no-nic-at-startup troubleshooting, or a specific LTSP case?
<Kamion> ok, well, the installer boots with 2.6.15-6, sort of
<jbailey> I have to ifup at startup, but I think you said that's expected.
<Keybuk> jbailey: we forgot about initramfs probing network modulesentirely when we wrote udev-roadmap
<Kamion> something's wrong with framebuffer bringup though
<ogra> jbailey, it is ltsp... but might also affect others
<Keybuk> Kamion: "wrong with" ?  ...  you mean that framebuffer drivers are brought up?
<Keybuk> ogra: are we at a "Spawning shell in the initramfs" prompt yet?
<Kamion> Keybuk: er no, the installer relies on a framebuffer ...
<jbailey> Keybuk: Mmm, yeah.  Althouhg it seems solvable in that the nfs initramfs class can have the nic probing and the klibc dhcp client call can be a udev rule at that point.
<Keybuk> Kamion: oh, now that makes things more interesting wrt blacklists
<jbailey> Keybuk: So I don't think it's unsolvable.
<ogra> Keybuk, wait, takes a second ...
<Kamion> Keybuk: nope, the installer already modprobes them itself
<Keybuk> oh ok
<Kamion> Keybuk: just leave it to do its job and it will be fine :)
<Kamion> (well, ish)
<jbailey> Keybuk: Then we just do the same event wait for the root filesystem to appear.
<infinity> Kamion : Are you sure you're not getting fb conflicts?
<ogra> Keybuk, ok, there
<Keybuk> ogra: good
<Keybuk> now what network driver are you looking for?
<ogra> note that i have to regenrate the tftpboot stuff afterwards
<Kamion> infinity: pretty sure, yes. symptoms are funny squares in localechooser rather than UTF-8 characters; I'm investigating
<infinity> Kamion : I get vga16fb/vesafb (whichever one usplash decides I wanted) loaded, then udev goes and loads a second later.
<ogra> 8139too
<Kamion> infinity: no usplash in the installer
<Keybuk> ok, grep 8139 /proc/modules and check it's not in there
<ogra> but in fact all pci drivers
<infinity> Kamion : Right, but similar idea, since the installer loads an FB, then you fire off udev... Right?
<infinity> Kamion : (Or perhaps vice versa, but either way, you may end up with two loaded)
<Kamion> infinity: well there's only one entry in /proc/fb afterwards, so I don't think it's that
<ogra> nope, not there
<Keybuk> ogra: good
<Keybuk> ogra: udevplug -Bpci -Iclass=0x02*
<infinity> Kamion : Right, then I'll shut up.
<Keybuk> ogra: then look to see whether the module was loaded
<Kamion> udev *might* not be helping here, but I can't say for sure yet
<ogra> yup, loads
<Keybuk> "yup, loads" ?  loads of what?
<ogra> the netcard module... 8139too
<Keybuk> right
<ogra> s/loads/it loads/
<ogra> :)
<Keybuk> . conf/initramfs.conf
<Keybuk> . scripts/modules
<Keybuk> . scripts/$BOOT
<Keybuk> mountroot
<Keybuk> run_scripts scripts/init-bottom
<Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
<Keybuk> --
<ogra> oh
<ogra> cant open scripts/modules
<Keybuk> uh
<Keybuk> sorry
<Keybuk> scripts/functions
<ogra> ah
<Keybuk> also, just for my sanity, could you cat /sys/class/net/eth0/device/class
<ogra> yup, booting
<ogra> oh, err ... in busybox ?
<Keybuk> nah, when the system is up is fine
<ogra> 0x020000
<Keybuk> okies
<Keybuk> thank you for your bug report.
<ogra> so the udevplug needs to run in a later script, right ?
<Keybuk> just needs udevplug running over network controllers somewhere
<Keybuk> it was missed out
<ogra> ah, fine
<Keybuk> because neither jbailey or I remembered it when we wrote udev-roadmap
<ogra> heh
<ogra> ok
<ogra> thanks for the prompt help :)
<Kamion> Keybuk: the installer-startup script is basically horribly broken - working on it now
<Keybuk> Kamion: ok.  I cargo-culted it from the main startup script, but wasn't sure how much of the "deal with initramfs" crap would be needed
<pitti> Keybuk: can you please tell me when you have some minutes to discuss about my morning's udev failure?
<Kamion> can we just use cp -af or something rather than the find | cpio thing?
<Kamion> we don't have cpio in busybox-udeb at the moment
<Keybuk> Kamion: heh, I tend to use cpio because I trust it ... I always assume that things like busybox don't have cp -a
<Keybuk> but yes, if the result is the same, we can
<Kamion> seems to be
<Keybuk> pitti: yup, give me three minutes, and you're up next
<Keybuk> pitti: right, tell me about your problems
<pitti> Keybuk: ok, so this morning I wanted to update an udev rule for testing
<pitti> so, naive as I am, I tried sudo /etc/init.d/udev restart
<pitti> which didn't seem to reload the conffiles
<pitti> force-reload didn't either
<pitti> then I did the more brutal way of calling stop, then start
<pitti> after which I found my /dev empty, my conffiles in /etc/udev purged, and /etc/udev filled with devices
<pitti> and /etc/udev did not seem to be a mount point (that was still /tmp)
<Keybuk> ok
<pitti> I suspect that "mount -n -o bind /dev /etc/udev
<pitti> " in the init script (and the following commands) caused that
<Keybuk> a) udevd keeps an inotify watch on /etc/udev/rules, so you don't need to reload it
<pitti> I removed /etc/udev/* and purged/reinstalled the packages to get my conffiles back
<Keybuk> 2) reload/force-reload should send it a HUP
<Keybuk> 3) ooooooops :p
<pitti> well, all I can say it that I changed /etc/udev/hal.rules, and it was not reloaded
<Keybuk> yes
<Keybuk> well
<Keybuk> see also
<Keybuk> DON'T PUT SYMLINKS IN /etc/udev/rules.d
<Keybuk> I've been telling people this for a week now
<Keybuk> including yourself about a dozen times
<pitti> bbbut... that's the official Debian way
<Keybuk> yes, that might be what Debian do
<Keybuk> but it's wrong
<Keybuk> we don't share any common code with the Debian udev packaging
<Keybuk> put the file itself in /etc/udev/rules.d please
<Keybuk> seriously
<pitti> these symlinks come from various other packages: hal, alsa-utils, etc.
<Keybuk> udevd cannot spot them changing
<Keybuk> and won't reload them
<Keybuk> yes
<Keybuk> we will fix them all
<pitti> ok
<Keybuk> alsa-utils is on my list
<pitti> TBH, I didn't notice/remember the no symlinks policy
<pitti> I'll fix hal
<Keybuk> yeah
<pitti> Keybuk: do you know the cause of the lost conffiles? or do you need more info?
<Keybuk> the symlinks stuff in the first place is Marco being very odd
<pitti> bind-mount /dev to /etc/udev seems odd to me
<Keybuk> we will just put the files themselves in /etc/udev/rules.d
<jbailey> Keybuk: Post that to u-d-a perhaps so that it's recorded?
<Keybuk> jbailey: yeah, I should do
<Keybuk> it applies to Kamion's pcmciautils packages too
<Keybuk> ok
<Keybuk> so #1 is understood (you didn't put the file in the right directory)
<pitti> yep
<Keybuk> #2 is also understood (it uses lstat, and the symlink itself didn't change)
<pitti> that means force-reload/restart is not necessary
<Keybuk> right, reload/force-reload just sends a HUP ... it should have zero effect
<Keybuk> I just put them in because I was being complete
<Keybuk> restart does a refresh of /lib/udev/devices and udevplug
<Keybuk> useful for a "I changed something/installed new modules/etc." hit
<Keybuk> stop does actually stop udevd and umount /dev
<pitti> that even seemed to have worked
<pitti> since then mountpoint -q /dev failed
<Keybuk> right
<pitti> and I got my old /dev mounted to /etc/udev
<Keybuk> it's the start on a running system without a /dev that failed
<Keybuk> right?
<pitti> yes
<Keybuk> thanks for testing that code-path :)  I hadn't yet
<Keybuk> (there's a /dev in the ordinary start, as initramfs makes it)
<pitti> I was a little surprised that /etc/udev was no tmpfs mount
<pitti> it seemed to be real files
<pitti> or the kernel hides bind / -o move mounts really well
<Keybuk> it uses it as a temporary place to put the static /de
<Keybuk> the theory goes:
<Keybuk> 1) move static /dev to /etc/udev
<Keybuk> 2) mount tmpfs on /dev
<Keybuk> 3) make /dev/.static/dev
<Keybuk> 4) move /etc/udev mount back to /dev/.static/dev
<pitti> yes, I see the code
<pitti> I don't see any obvious flaws
<pitti> oh, wait
<pitti> I had to kill the start init script
<pitti> because it ran indefinitely
<Keybuk> aha!
<Keybuk> there's a missing -p
<Keybuk> mkdir -m 0700 /dev/.static/dev will fail
<pitti> aah
<pitti> so that means it probably hanged at the last mount -o move command
<Keybuk> and the second move fails for some reason
<pitti> but shouldn't it just fail?
<Keybuk> no, it meant it failed at the mkdir -- it's a -e script
<pitti> hmmm
<pitti> it hanged, it didn't fail
<Keybuk> ok, could you try it again with sh -x and see where it hangs?
<pitti> Keybuk: maybe, just to be sure, you can temporarily mount it to /etc/udev/newdev/ or so?
<pitti> sure, I'll try
<pitti> stopped
<pitti> whoops
<Keybuk> that'd involve a mkdir on a read-only filesystem <g>
<pitti> $ ls /dev
<pitti> alsa-utils.rules  hal.rules  initctl  pcmcia.rules  rules.d  udev.conf
<pitti> *ahem*
<Keybuk> lol
<Keybuk> you may wish to reboot to get to a sane system
<Keybuk> follow-the-lady with your filesystem
<pitti> Keybuk: /dev was perfectly sane before /etc/init.d/udev stop
<pitti> (I already rebooted after the previous mess and restaurationof my conffiles)
<pitti> so WTH did stopping udev scribble /etc/udev* over my /dev directory? (it's not mounted any more, btw)
<Keybuk> dunno
<Keybuk> fixing that -p, and changing -o move to --move fixes it for me
<Keybuk> I can stop/start happily
<pitti> ok, I did that, will try after reboot
<pitti> last thing: pcspkr is not loaded automatically any more
<Keybuk> oh, now that's kinda interesting
<pitti> will that get fixed kernel-wise, or should we put it into /etc/modules?
<pitti> I did not get any IRC beeps any more :)
<Keybuk> modinfo pcspkr
<pitti> vermagic:       2.6.15-5-amd64-generic gcc-4.0
<pitti> , if you need that
<Keybuk> any alias lines?
<pitti> no
<Keybuk> grep pcspkr /lib/modules/$(uname -r)/*
<pitti> /lib/modules/2.6.15-5-amd64-generic/modules.dep:/lib/modules/2.6.15-5-amd64-generic/kernel/drivers/input/misc/pcspkr.ko:
<Keybuk> ok
<Keybuk> check that you have a "alias pnp:dPNP0800 pcspkr" line in /etc/modprobe.d/isapnp
<pitti> I have
<Keybuk> grep PNP0800 /sys/bus/pnp/devices/*/id
<pitti>  /sys/bus/pnp/devices/00:05/id:PNP0800
<pitti> (I loaded it manually, btw)
<Keybuk> /lib/udev/pnp_modules /bus/pnp/devices/00:05
<pitti> it will probably look different without the module loaded
<pitti> pnp:dPNP0800*
<Keybuk> *giggle*
<Kamion> RAH
<Keybuk> what's that "*" doing there?
<Keybuk> thankyou for your bug report :)
<pitti> my pleasure :)
<Keybuk> any more?
<Kamion> #20342 is everything we need, plus a few rootskel changes
<Kamion> (for the installer)
<pitti> Keybuk: just a question
<pitti> Keybuk: hunger got thousands of /usr/lib/hal/hal.hotplug not found errors during boot
<pitti> Keybuk: because /usr was not mounted, so the udev rule failed
<pitti> Keybuk: is it legitime to add a test -x check to the rule?
<Keybuk> pitti: yeah, we need to fix the hal stuff ... I think hal listens on a socket that can be passed uevents, is that right?
<pitti> I think so, yes
<Keybuk> yeah, so we'll change that to do RUN+="socket:/org/freedesktop/hal/uevent" or whatever it calls the socket
<pitti> unix  2      [ ]          DGRAM                    13585    6047/hald           @/var/run/hal/hotplug_socket2
<Keybuk> test -x won't help you ... udev isn't a shell, so doesn't have a test buildin :p
<pitti> that one maybe?
<Keybuk> pitti: no, that's a filesystem socket, you want the unix namespace socket
<pitti> Keybuk: oh, but with PROGRAM= / RESULT== it will ceratinly work?
<Keybuk> it'll look like @/org/... I think
<Keybuk> pitti: how do you mean?
<Keybuk> Kamion: installer may have been bitten by same bug as pitti
<pitti> Keybuk: the PROGRAM/RESULT check if /usr/lib/hal/hal.hotplug is available, and RUN is only called with RESULT==0
<Keybuk> what would you put in PROGRAM?
<pitti> bah, why is test in /usr/bin?
<pitti> ok, let's forget that
<Keybuk> pitti: :D
<Keybuk> test is also not in the initramfs at all
<pitti> well, we could abuse /bin/bash .. :)
<pitti> hrm
<Keybuk> /bin/bash is not in the initramfs at all
<Keybuk> anyway
<pitti> this is more complicated than I thought...
<Keybuk> the socket is the right way
<pitti> ok, I'll read about this
<Kamion> Keybuk: hmm?
<pitti> ok, let's restore my static /dev first
<Keybuk> Kamion: you don't want /dev/.static/dev in the installer?
<Kamion> pitti: in any case you'd need to fail if hal.hotplug isn't there, so that the event can be replayed later
<Kamion> Keybuk: nope
<Keybuk> Kamion: does nothing call MAKEDEV (package postinst?)
<Kamion> Keybuk: nope
<Keybuk> ok
<Keybuk> easy then
<Kamion> Keybuk: package postinst => chroot /target
<Kamion> ~ # type MAKEDEV
<Kamion> MAKEDEV: not found
<Keybuk> pitti: the real bug is probably that udevd does an OMG THE SKY IS FALLING! when it can't find a binary
<Keybuk> it should be a muted warning rather than an error
<pitti> yes, you'll get thousands of error messages
<Keybuk> cf. grepmap in the initramfs
<Keybuk> Kamion: will /dev ever be a mountpoint when the udev startup script is run?  ie. can I just assume it's not, and make it?
<pitti> Keybuk: hm, is "sudo netstat -avpx|grep hal" really the right command to watch out for the unix socket?
<pitti> Keybuk: there is just one listening socket
<pitti> unix  2      [ ACC ]      STREAM     HRT         13584    6047/hald           @/tmp/hald-local/dbus-7awadoPF2s
<pitti> HRT == LISTENING
<Keybuk> hmm, it might be a floating patch
<pitti> and that DGRAM one
<Kamion> Keybuk: please leave that out, I've made init-udev-devices do it
<Kamion> assume that it's already a correct mountpoint
<Kamion> we need to create some minimal stuff in /dev in order to bring busybox init up *anyway*, so this is correct
<Keybuk> right
<Kamion> Keybuk: the exact directions I gave in the bug work :-)
<Keybuk> so what should I do?  just copy over /lib/udev/devices and start udev/udeplug ?
<Kamion> replace lines 15-24 with 'cp -af /lib/udev/devices/* /dev/'
<Kamion> yep
<Kamion> that's all the startup script needs to do
<Kamion> I've fixed the few lines of d-i that needed to be tweaked; uploads are either in or on their way
<Keybuk> oh, I remember why I used cpio
<Keybuk> cp bitches when special files already exist
<Keybuk> not a problem in the installer
<Kamion> cp -af doesn't
<Kamion> I ran into that, because /dev/console was already there
<Kamion> but if it doesn't work, force it :)
<Keybuk> cp -af does too here
<Kamion> must be a busybox thing
<Kamion> 'cos it really didn't :)
<pitti> Keybuk: confirmed, with the two init script fixes (-p and --move) it works fine
<Keybuk> whoah
<Keybuk> isn't it great when you read code and find undocumented features that will rock
<Keybuk> udev appears to have ifrename built in
<Keybuk> AND correctly switches the name over for future events
<infinity> \o/
<infinity> MAKE IT WORK NOW.
<Keybuk> SUBSYSTEM=="net", SYSFS{address}=="....", NAME="eth1"
<Keybuk> SUBSYSTEM=="net", RUN+="ifup %k"
<Keybuk> the %k in the second call will be eth1, not eth<whatever it was before>
<Kamion> Keybuk: #20340> heh, oops, I thought I had upgraded already
<Mithrandir> Kamion: how insane am I if I want to run the installer in valgrind and fix the bugz?
* ..[topic/#ubuntu-boot:Keybuk] : known: fb drivers loaded, oss drivers loaded, no network plugging, pcmcia/hal/alsa rules not reloaded, mtab not updated, /dev/pts not mounted  || pending: nfs root fails, sata root fails, pnp devices not loaded, init stop/start
* ..[topic/#ubuntu-boot:Keybuk] : known: fb drivers loaded, oss drivers loaded, no network plugging, pcmcia/hal/alsa rules not reloaded, mtab not updated, /dev/pts not mounted  || pending: nfs root fails, sata root fails, pnp devices not loaded, init stop/start || fixed: notify-reboot, vio_type segfault, no modules loaded
<pitti> Keybuk: ok, hal binds to the NETLINK_KOBJECT_UEVENT netlink socket
<Keybuk> what socket is that?
<pitti> Keybuk: but I don't have the slightest idea how they work
<Keybuk> that sounds rather like hal is listening to uevents itself
<Keybuk> if you give me a few minutes to get this release out of the door, I'll look with you
<pitti> oh, sure
<pitti> sorry to bother you with it
<Keybuk> lol, bother away
* ..[topic/#ubuntu-boot:Keybuk] : known: fb drivers loaded, oss drivers loaded, no network plugging, pcmcia/hal/alsa rules not reloaded, mtab not updated, /dev/pts not mounted  || pending: nfs root fails, sata root fails, pnp devices not loaded, init stop/start, grepmap bitching || fixed: notify-reboot, vio_type segfault, no modules loaded
<pitti> lol, bug tracking in /topic
<Keybuk> yup
<Keybuk> easier than my head/whiteboard
<pitti> Keybuk: ok, I still know the old-fashioned way of hal: hotplug calls /usr/lib/hal/hal.hotplug, which grabs the environment, and forms a mesage out of it and sends it to a unix socket
<pitti> Keybuk: so what you want to do is to send the udev messages directly to that socket, right?
<Kamion> fixing the pcmciautils issue now
<Keybuk> pitti: right, there's in theory no reason udev itself can't send that socket
<Keybuk> except possibly for the hal magic thing
<Keybuk> the udev release notes talk about this though:
<Keybuk>   RUN+="socket:/org/freedesktop/hal/udev_event"
<Keybuk> that *might* be still in a patch that's not applied upstream
<Keybuk> or in CVS HEAD or something
<pitti> Keybuk: I just wonder why it listens to the KOBJECT socket itself
<pitti> I think it didn't work without the rule, but I'll try again
<pitti> ok, no, it doesn't work
<pitti> Keybuk: ok, that socket: thing doesn't work, that would just be too easy :)
<Keybuk> http://lists.freedesktop.org/archives/hal/2005-November/003943.html
<pitti> Keybuk: ok, what hal.hotplug does, is: it opens the AF_LOCAL SOCK_DGRAM socket /var/run/hal/hotplug_socket2
<Keybuk> ^ you'll be wanting that patch
<pitti> ah, great
* ..[topic/#ubuntu-boot:Kamion] : known: fb drivers loaded, oss drivers loaded, no network plugging, hal/alsa rules not reloaded, mtab not updated, /dev/pts not mounted  || pending: nfs root fails, sata root fails, pnp devices not loaded, init stop/start, grepmap bitching || fixed: notify-reboot, vio_type segfault, no modules loaded, pcmcia rules not reloaded
<Kamion> (diff: pcmciautils fixed)
<pitti> Keybuk: ok, I'll pull it from the upstream cvs
<pitti> Keybuk: I'll also fix the rules.d thing; is 85-hal ok, priority-wise?
<Keybuk> what does the rule contain?  just that?
<pitti> Keybuk: that, and the automatic unmounting
<pitti> of ripped out devices
<pitti> (which should be in the kernel, but oh well..)
<Keybuk> 85-hal.rules
<pitti> ok, great
<Keybuk> 005-11-15  Kay Sievers  <kay.sievers@vrfy.org>
<Keybuk> 	* hald/linux2/osspec.c: (hald_udev_data), (hald_helper_data),
<Keybuk> 	(osspec_init): Listen to socket: /org/freedesktop/hal/udev_event
<Keybuk> 	Udev will pass all data over this socket to HAL, if the following
<Keybuk> 	rule is given:
<Keybuk> 	  RUN+="socket:/org/freedesktop/hal/udev_event"
<Keybuk> 	The HAL hotplug helper /usr/sbin/hal.hotplug is no longer needed
<Keybuk> 	and should be replaced by the direct udev connection which will
<Keybuk> 	no longer fork a process for every event.
<Keybuk> 	This is the preparation to reuse the persistent data udev collects
<Keybuk> 	from the hardware, instead of querying it a second time with HAL.
<Keybuk> 	If we reach this, drive_id/* and the hotplug helper will be removed
<Keybuk> 	from HAL.
<Keybuk> (from hal CVS changelog)
<Kamion> any objection to me turning on command editing, history, and tab completion in the initramfs busybox shell?
<Kamion> it would make life so much less painful
<jbailey> Kamion: What the size cost?
<Kamion> I can find out
<Keybuk> Kamion: does newer pcmciautils add -Qb to its "modprobe pcmcia" call?
<Keybuk> (in the udev rules)
<Kamion> no; should it?
<Keybuk> yeah
<Keybuk> otherwise "users can't blacklist pcmcia"
<Keybuk> and you want the -Q to suppress automated bitching
<pitti> Keybuk: oh, right, that was another thing I wanted to ask you - is /etc/hotplug/blacklist.d still supported?
<Kamion> Keybuk: how about pcmcia_core?
<Kamion> that's currently -q
<Keybuk> Kamion: change to -Qb ... I included all the behaviour of -q in -Q
<Keybuk> pitti: nothing in Ubuntu should place a file in there, therefore it's currently disabled, however before beta we will enable it for anything the users might have in there
<Kamion> alright, I'll -Q the bridge module loads as well
<Kamion> fixed in my tree
<pitti> Kamion: two or three packages drop stuff in it; most important is alsa
<Keybuk> pitti: libsane should provide an /etc/modprobe.d/libsane-blacklist which has "blacklist hpusbscsi" and "blacklist scanner" in it
<Keybuk> alsa is on my todo list
<Kamion> pitti: s/Kamion/Keybuk/ :)
<pitti> ah, great
<Kamion> I can change my nick to Keybun if it would make things easier
<pitti> Kamion: oops, sorry :)
<Keybuk> Kamibuk
<Kamion> -rwxr-xr-x  1 cjwatson cjwatson 910672 2005-12-01 14:29 old/busybox
<Kamion> -rwxr-xr-x  1 cjwatson cjwatson 918352 2005-12-01 14:33 new/busybox
<pitti> we get completion for 8 kB?
<Kamion> jbailey: ^-- size cost (unstripped) of turning on editing/history/tab-completion
<pitti> sweet
<jbailey> Kamion: No brainer. =)
<Kamion> oh, no, I think that is stripped
<Kamion> ok, I'll enable it
<Keybuk> infinity: linux-doc-2.6.15 conflict/overwrites linux-doc-2.6.12
<pitti> sweeet - conffiles were transitioned, hal responds to the socket events
<pitti> thanks Keybuk
<pitti> Keybuk: I'll fix the rules.d symlink story for libgphoto2, too
<Keybuk> right, while the buildds are building new udev and m-u-t, I'm gonna grab lunch
<makx> inifinity: do you have latest ubuntu initramfs-tools in bzr archive?
<makx> jbailey's latest pushed is 0.31.
<jbailey> makx: I think he's asleep atm.
<makx> aah ok, will reask tomorrow, thanks jbailey. :)
<pitti> Keybuk: libgphoto2 conffiles fixed
* ..[topic/#ubuntu-boot:pitti] : known: fb drivers loaded, oss drivers loaded, no network plugging, alsa rules not reloaded, mtab not updated, /dev/pts not mounted  || pending: nfs root fails, sata root fails, Kepnp devices not loaded, init stop/start, grepmap bitching || fixed: notify-reboot, vio_type segfault, no modules loaded, hal/pcmcia rules not reloaded
<pitti> (diff: hal rules are reloaded now)
* ..[topic/#ubuntu-boot:Keybuk] : known: fb drivers loaded, oss drivers loaded, no network plugging, alsa rules not reloaded, mtab not updated, /dev/pts not mounted || fixed: notify-reboot, vio_type segfault, no modules loaded, hal/pcmcia rules not reloaded, nfs root fails, sata root fails, pnp devices not loaded, init stop/start, grepmap bitching
<Keybuk> (diff: pending -> fixed)
<HiddenWolf> All of it?
<HiddenWolf> Nice!
<Keybuk> yeah, all the pending stuff went into 0ubuntu5
<makx> Keybuk: in 0.40ubuntu1 you mention Copy across modprobe blacklist, as well aliases, is this the same file?
<Keybuk> /etc/modprobe.d/aliases
<Keybuk> /etc/modprobe.d/blacklist
<Keybuk> different files
<makx> ohh overseen, yes thanks!
<makx> debian but #337318 wanted to have all /etc/modprobe.d
<makx> s/but/bug/
<makx> i've asked him for clarification.
<Keybuk> it makes some amount of sense to copy the entire directory
<ogra> Keybuk, just to report back, my thin clients boot fine again
<ogra> thanks for the quick fix :)
<ogra> Keybuk, if you have an uploade of initramfs-tools pending, could you pretty please finally remove the sleep 3 from /usr/share/initramfs-tools/scripts/nfs ?
<Keybuk> I don't have an upload pending, it's infinity's job now :p
<ogra> ok, i'll poke him....
<ogra> thin clients stilltake over a minute for booting :(
<Keybuk> yeah, lots of changes yet to come
<jbailey> ogra: Still takes is fine.
<ogra> oh, i thought this was it already
<jbailey> ogra: TAkes a minute longer would suck. =)
<ogra> i target 45 seconds .... but i am at 1:03~1:09
<jbailey> ogra: Just upload it with the NFS fix.  There's no reason to wait on a BML.
<Keybuk> what were you before?
<ogra> at least i just could boot without usplash timing out
<ogra> with all bootscripts it was ~1:45
<ogra> with eliminating the bootscripts ~1:20
<Keybuk> so it's taking 40s less?
<Keybuk> ok, still 10-15s less then
<ogra> so i won about 15sec
<Keybuk> good
<Keybuk> that's about my expected win
<Keybuk> next we move several bits to udev rules
<Keybuk> sort out networking
<Keybuk> and reorder rcS to eliminate the bugs
<Keybuk> that might give us up to 10-15s more
<ogra> that'd be enough for me :)
<Keybuk> then fix readahead, hopefully another 10-15s there
<ogra> i just had the impression you were already done
<Keybuk> hmm, no?  this was the FIRST upload :p
<ogra> forget about readahead ... i cant use it
<ogra> (wont gain much with 32-64 MB)
<Keybuk> likewise
<Keybuk> UDEV_LOG=info /sbin/udevd --daemon
<Keybuk> :p
<crimsun> ok, got that
<Keybuk> right, did it output things?
<crimsun> indeed, 3 lines (I'll have to by-hand)
<Keybuk> ok
<Keybuk> just that it output things
<Keybuk> now following stuff will output various gubbins, you'll need to read the screens (use shift-pgup/dn) and look for anything suspicious
<Keybuk> has_driver returning 1 isn't suspicious, that just means there's no driver loaded yet
<Keybuk> modprobe returning 1 is suspicious
<Keybuk> etc.
<crimsun> k
<Keybuk> now, first let's just sanity check that you don't have a /dev/sda* , /sys/class/block/sda* and /sys/bus/scsi* ?
<crimsun> none of those
<Keybuk> good, it's nice to make sure we're not in la-la land
<Keybuk> now we'll run a few udevplug commands, these will dump a lot of udevd debugging information to the screen -- read it all and summarise for me anything suspicious
<crimsun> k
<Keybuk> we'll also write some output to a file, cat that file and say what you see (feel free to just replace long number strings with *)
<Keybuk> udevplug -Bide -Bscsi -Bi2o -Busb -Bieee1394 > 1.txt
<Keybuk> uh
<Keybuk> stick -v in there too :p
<Keybuk> udevplug -v -Bide -Bscsi -Bi2o -Busb -Bieee1394 > 1.txt
<crimsun> no output (1.txt is a 0-byte)
<Keybuk> exxxxcellent
<Keybuk> ok, this is an easy one, don't worry about this, it just makes a bunch of stuff you'll need
<Keybuk> (ie ignore the output)
<Keybuk> udevplug -Cmem -Cmisc -Ctty -Cvc
<Keybuk> then you may as well press enter lots so you can find your place
<Keybuk> this one we care about
<Keybuk> udevplug -v -b > 2.txt
<Keybuk> in 2.txt you should only have /sys/block/ram* ... and nothing suspicious in the udevd dump
<crimsun> doesn't appear to be anything suspicious, lots of /block/ram* and /dev/ram* with their associated has_driver returning 1, presumably innocuous according to above
<Keybuk> yeah
<Keybuk> has_driver is just a "can we skip modprobe" thing
<Keybuk> right
<Keybuk> so we still have no /dev/sda*, /sys/block/sd*, /sys/bus/scsi* ?
<crimsun> correct
<Keybuk> right
<Keybuk> so now, in theory, we're in a sane state to probe for scsi controllers
<Keybuk> now, I'm assuming it's a real scsi controller that we're looking for, yes?
<crimsun> SATA (IBM TP X41-2527)
<Keybuk> right, SATA controller
<Keybuk> ok, that makes things more fun
<Keybuk> so let's try this:
<Keybuk> udevplug -v -Bpci -Iclass=0x0[12] * > 3.txt
<Keybuk> you'll get a lot of output from that, read it all carefully
<Keybuk> I'm interested in anything modprobe does (you'll see module/* events)
<Keybuk> and also the 3.txt contents
<crimsun> ok, as far back as the buffer permits, SCSI device sda is attached, a lots of scsi_id output (ID_VENDOR, ID_MODEL, etc.), lots of use of kernel name because node name not being set, edd_id spits out "main: no kernel EDD support" (returns 2), has_driver /block/sda returns 1, /dev/sda is created, lots of symlinks set up, lots of vol_id output, /dev/sda4 created, more vol_id output, /dev/sda3 created, more vol_id output, /dev/sda1 created
<Keybuk> right
<Keybuk> ls $ROOT finds something?
<crimsun> 3.txt has /sys/devices/pci0000:00/0000:00:1[cef] *
<crimsun> yep, ''ls $ROOT'' returns "/dev/sda3"
<Keybuk> ok...
<Keybuk> can you do
<Keybuk> grep udevplug scripts/init-premount/udev
<Keybuk> check that the calls are exactly as you've done above
<crimsun> the output contains three lines: "/sbin/udevplug -Bide -Bscsi"[...] , "/sbin/udevplug -Bpci -Iclass=0x0[12] *", and "/sbin/udevplug -W"
<Keybuk> ok
<Keybuk> so what I think you have, is the "SCSI takes longer than udev" bug
<Keybuk> it's not a udev version issue, it's just how fast your machine feels like
<Keybuk> basically if it fails, it means your machine reached the "mount root filesystem" bit faster then your SCSI/SATA controller got around to finding the devices on its bus
<Kamion> time: 0.50
<Kamion> nice
<crimsun> ah, so the change in 5 to probe the additional devices is probably the issue
<Kamion> not sure what it was before though
<Keybuk> Kamion: 1:20ish
<Kamion> on *my* system, not yours
<Keybuk> Kamion: they're surprisingly similar for broadly similar hardware
<Keybuk> all those sleep statements <g>
<crimsun> we pretty much walked through /etc/udev/rules.d/00*init (and maybe 20*names* ?), correct?
<Keybuk> crimsun: actually, if anything, that makes it more likely to succeed
<Kamion> http://people.ubuntu.com/~cjwatson/bootchart/dapper-20051201-2.png, anyway
<Keybuk> crimsun: it was probably the fact that udevplug is faster in ubuntu5
<Keybuk> we're taking heavily about adding a generic "spin until -e $ROOT" to initramfs
<crimsun> Keybuk: ah. In any case, thanks for taking time.
<Keybuk> are you on i386?
<crimsun> yeah (2.6.15-6-686)
<Keybuk> ok
<Keybuk> to boot
<Keybuk> ,pimtrppt
<Keybuk> uh
<Keybuk> mountroot
<Keybuk> run_scripts scripts/init-bottom
<Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
<Keybuk> --
<Keybuk> that should get you booted
<crimsun> Keybuk: indeed, thanks again. It's kinda scary how much of the syntax is becoming familiar (spent a few hours this morning poring over /etc/udev/rules.d/ and the udev man page to get the firmware loading correctly again)
<Keybuk> ok... one moment, I have a package for you
<crimsun> k
<Keybuk> http://people.ubuntu.com/~scott/initramfs-tools_0.40ubuntu5_all.deb
<Keybuk> ^ download and install that
<Keybuk> then update-initramfs -u
<Keybuk> then reboot
<Keybuk> see if that cures you
<Keybuk> Kamion: neat ... should be able to take another 10s off you by the weekend too
<crimsun> Keybuk: yep, boots fine
<Keybuk> could yo do a few reboots, just to make sure
<Keybuk> one or two warm
<Keybuk> and one or two cold
<crimsun> yup
<Keybuk> (ie three-finger, reset button and power off/wait/power on)
<Keybuk> crimsun: yeah, it's kinda kooky when you realise you can boot the system from kernel entirely from memory
<crimsun> hmm, now it hangs after "Done.\nBegin: Mounting root file system ...\nBegin: Running /scripts/local-top ...\nDone."
<crimsun> after ~25 seconds I'm dropped to a busybox shell
<crimsun> reproducible on both warm and cold boots
<Keybuk> crimsun: hmm, we'll have to continue this in the morning
<Keybuk> is getting too late here, will be back in ~8 hours
#ubuntu-boot 2005-12-07
<fabbione> interesting :)
<fabbione> today's installer does install the kernel and for some reasons removes it immediatly after
<fabbione> leaving yaboot in an interesting state ;)
<Kamion> fabbione: today's installer is not worth looking at
<Kamion> ignore it
<Kamion> it is an ex-installer, it has ceased to be, it's pushing up the daisies, it's gone to join the choir invisible
<fabbione> Kamion: yes i noticed :)
<fabbione> specially when i saw: Removing linux-image...
<Kamion> please try to find out what conflicts with old linux-image
<fabbione> i did try
<fabbione> but when i did chroot in target
<fabbione> and done apt-get install linux-powerpc
<fabbione> it just went in smoothly
<fabbione> no info of any kind
<fabbione> it didn't report any conflicts whatsoever
<Kamion> you didn't need to try that, you could just have looked in /var/log/messages and/or /var/log/syslog to see what caused the removal
<Kamion> i.e. what it was doing when it removed the package
<fabbione> sure
<fabbione> i can check that too
* fabbione fires up the beast again
<fabbione> ah
<fabbione> it tries to install hotplug
<Kamion> that'll be fixed soon
<fabbione> and kicks out a bunch of stuff
<fabbione> ok
<fabbione> i had no doubts :)
<Kamion> no as in I think it's already fixed in our archive, just needs an initrd rebuild
<Kamion> yeah, it is
<fabbione> ok
<fabbione> it sounds strange tho
<fabbione> because that's the output from what happens after debootstrap
<fabbione> it install the kernels
<fabbione> than it attemps to install another bunch of stuff
<fabbione> and it's there that kills the kernel
<fabbione> but well i am sure you know better than me
<fabbione> :)
<ogra> Kamion, there were several people having problems with pcmcia stuff on non-pcmcia machines last night, where the booting locked up on pcmciautils... known ?
<Kamion> ogra: see my comment to Diablo-D3 on #ubuntu-devel
<Kamion> 09:38 < Kamion> Diablo-D3: if you haven't already, could you please install the 2.6.15-6 kernel, reinstall pcmciautils, and confirm/deny that the lockup is gone?
<Kamion> 09:39 < Kamion> Diablo-D3: if it isn't gone, please *report a bug* rather than using several hundred lines of my #ubuntu-devel scrollback on it, kthxbye :-)
<Kamion> 09:40 < Kamion> Diablo-D3: because pcmciautils is going to stay in minimal - the packaging/upgrade issues are too difficult to deal with otherwise - so we need to make sure any lockups such as this are fixed
<Kamion> Diablo-D3 said he was using 2.6.15-5, where soft lockups were a known problem
<ogra> ah, ok
<ogra> i didnt talk to him anymore, he cant behave ... but LaseJock seemed to have similar issues ... he used 2.6.15-5 too ...
<ogra> *LaserJock
<ogra> just wanted to make sure it didnt slip through
<Kamion> right, nobody that I saw reported it with -6
<Kamion> but that isn't conclusive evidence that it's gone
<ogra> i havent seen such problems here ...
<Kamion> so I want to make sure everyone retests, rather than just removing pcmciautils
<Kamion> no, it will depend on your hardware. there were pcmcia crashes in the old world order as well, it's just that we didn't install pcmcia-cs on machines without pcmcia then
<Kamion> (because of this)
<ogra> yup, old debian behavior :)
<Kamion> was sane
<Kamion> you didn't want cardmgr running on desktops
<ogra> yes, i just remembered the installer question ...
<Kamion> damnit, d-i's going to fail to build
<fabbione> whops
<fabbione> :)
<Kamion> OTOH once I promote the relevant thing, sparc might build this time round
<fabbione> Kamion: no rush.. as usual
<Mithrandir> woohoo, I think I've fixed kbd-chooser now.
<fabbione> for sparc we are way to early in the release process to worry :)
<Kamion> I care about sparc because its lack of building d-i is causing noise in anastacia output that we have to ignore
<fabbione> Kamion: btw. i am going to look at that devmapper/lvm2 selinux thing on ppc
<fabbione> ah ok
<Mithrandir> and now it actually works.
<fabbione> let see how my laptop will explode with the new kernel/udev and stuff
<fabbione> WOO WOOOOO
<fabbione> go X!
<fabbione> at least it boots fine
#ubuntu-boot 2005-12-08
<lifeless> hola
<lifeless> udev does not seem to create nodes for my compact flash card
<lifeless> whats the best practice for debugging this ?
<Kamion> lifeless: at the moment, "wait until Keybuk shows up or send him mail" is part of the best practice. :-)
<lifeless> Kamion: thanks
#ubuntu-boot 2005-12-09
<skoo> Hi, everybody
<skoo> oh~~
#ubuntu-boot 2005-12-10
<infinity> Who understands udev/rules.d?
<fabbione> Keybuk :)
<infinity> Right, but he's not around.  Anyone else? :)
<fabbione> guys who remember how to disable archive copier?
<fabbione> from install cd/dvd boot prompt?
<Kamion> archive-copier/copy=false
<fabbione> Kamion: thanks
<makx> hmm latest initramfs-tools remved the code surounding ${resume}
<makx> config file setting this param will noop.
<Keybuk> Mithrandir: do you still have a T42?
<infinity> Keybuk : Oh, I was looking for you earlier.
<Keybuk> I'm here now, what's your pleasure?
<infinity> http://cerberus.0c3.net/~adconrad/ltmodem.rules
<infinity> a) Do I even need that in the new world order?
<Keybuk> almost certainly
<infinity> b) Do I need anything OTHER than that (ie: something to make hotplugging work?)
<Keybuk> it'll need rewriting though
<Keybuk> if the ltmodem drivers correctly advertise what things they hook for, you don't need anything for hotplug
<infinity> c) If I only need the above, is there any way to get it into udev itself, so I don't have to worry about sticking it in lrm-common, or some other odd place.
<Keybuk> sure, I can stick those in udev
<infinity> How does it advertise?
<infinity> MODULE_DEVICE_TABLE(pci, ltmodem_pci_ids);
<infinity> ?
<infinity> (ltmodem_pci_ids is a big struct with a mess of PCI IDs)
<Keybuk> yup
<Keybuk> sounds reasonable
<Keybuk> does "modinfo ltmodem" list a bunch of alias lines?
<Keybuk> (ltserial seems to)
<infinity> Yeah, it's ltserial that has the table..
<infinity> I assume ltmodem gets loaded from ltserial or something.
<infinity> Not having the hardware makes it difficult to actually test these theories. :)
<Keybuk> yeah, ltmodem depends: ltserial
<Kamion> infinity: wow, does that even work? KERNEL== not KERNEL= surely ...
<infinity> Kamion : It works for the driver maintainer on Debian.
<infinity> (As of sometime this summer)
<Keybuk> heh
<Kamion> maybe he has no udev rules after it ;)
<infinity> So... "maybe"?
<Keybuk> KERNEL="ttyLTM[0-9] " will return true <g>
<Keybuk> (and change the kernel-assigned make for any following udev rule :p)
<Keybuk> that should be
<Keybuk> KERNEL=="ttyLTM[0-9] *", SYMLINK+="modem"  (in 40-permissions.rules)
<Keybuk> KERNEL=="ttyLTM[0-9] *", MODE="0660", GROUP="dialout"  (in 60-symlinks.rules)
<Keybuk> uh, reverse the filenames and get me more coffee <g>
<infinity> Cool.  If you can put it in udev proper, I'll be a happy camper.
<Keybuk> yup
<infinity> Out of curiosity, though, how should I do it (and at what order in rules.d) if I had to do it myself?
<Keybuk> those two rules
<Keybuk> 00-19 is anything really critically important to go first (ie. WAIT_FOR_SYSFS type things)
<Keybuk> 20-39 assigns names
<Keybuk> 40-59 assigns permissions
<Keybuk> 60-79 adds symlinks
<Keybuk> 80-99 runs programs
<infinity> Cool.
<Keybuk> usually pick low+5 (ie. 25, 45, 65, 85, 95 [for modprobe calls] ) for custom rules
<Keybuk> the idea is that it makes /etc/udev/rules.d/50-*.rules the perfect place for user rules
<Keybuk> they can't override names we assign, but can assign their own
<Keybuk> they can override permissions, symlinks, programs, and can do things like options="last_rule" and stuff
<Kamion> Keybuk: oh yeah, thanks for the pcmciautils change, I'd been meaning to do that
<Kamion> Keybuk: do you have a bzr branch for that?
<Keybuk> no :p  I don't have bzr on my laptop at the moment
<Kamion> ok, I'll just merge it then
<Keybuk> \o/
<Keybuk> I fixed the /dev permissions bugs
<Keybuk> it was debhelper being "helpful"
<jbailey> Yeah, it does that. =)
<Keybuk> I want them all to be 0600 by default, so people can't toy with them <g>
<Keybuk> debhelper thought they should be 0644
<Kamion> hmm, weird, now udev on the live CD doesn't want to create /dev/hd*
<Kamion> or sd*
<Kamion> ah, there's /dev/sd* now after udevplug -Bpci
<Kamion> double-ah, iz hw-detect's fault
#ubuntu-boot 2005-12-11
<Kamion> infinity: l-r-m was breaking d-i, so I've uploaded what I think should be a fix for that
<Kamion> hard to test without building new images though
<Keybuk> heh
<Kamion> Keybuk: line 7 of 10-devfs.rules looks suspicious; missing %?
<Keybuk> yup
<Kamion> Keybuk: could you replace awk '{print $2}' with sed 's/^[^ ] * //; s/ .*//' in /lib/udev/scsi-devfs please? we don't have awk in d-i
* Kamion -> bed
<Keybuk> can you mail that one to me?
* fabbione tests root=/dev/disk/by-uuid/*
<fabbione> cat /proc/cmdline
<fabbione> root=/dev/disk/by-uuid/4d216a51-2317-47a4-872f-125a6d035d08 ro quiet splash
<fabbione> it seems to work
<fabbione> but there is another side effect we didn't think when writing the specs
<fabbione> root is not enough
<fabbione> we need to possibly detect other partitions and swap
<fabbione> otherwise even if we get root, we might miss the rest of the system
<fabbione> that defeats the purpose of the spec
<fabbione> bah Keybuck isn't here
<infinity> But other partitions should be in /etc/fstab...
<infinity> (by uuid, perhaps, but they should be there anyway)
<fabbione> the problem is that swap doesn't have a uuid
<Kamion> fstab supports the UUID= and LABEL= syntaxes
<Kamion> you can use LABEL= for swap
<fabbione> and the thing is that yes, the other partitions needs to have uuid too
<fabbione> fail to do so, we are in trouble
<infinity> But multiple swap partitions can have the same label.
<Kamion> mm
<fabbione> like a / on ext3 = ok, /home on xfs = nok
<infinity> I thought uuid-on-swap was something we were fixing?
* infinity thought he heard something about this during the breezy cycle.
<fabbione> uuid is a property of the fs
<infinity> Yes, and?
<fabbione> swap isn't exactly a fs
<infinity> mkswap could do uuid magic.
<infinity> swap isn't an FS, but it still has magic.
<infinity> Not much, but some.
<infinity> And losing another few bytes for a UUID isn't the end of the world.
<fabbione> no, but you would introduce tons of other problems
<fabbione> think of the resume from hibernate that clear the swap or so
<fabbione> your approach would assume that swap isn't used by anyone else
<fabbione> what if the user dual boot breezy/dapper
<fabbione> both clean the swaps in 2 different ways
<fabbione> bang
<infinity> Yeah, ew.
<infinity> Hrmph.
<infinity> Of course, if this sort of breakage isn't done some day, it can never be done.  Catch-22.
<fabbione> yes i agree
<infinity> I'd love SOME way to uniquely identify swa ppartitions.
<fabbione> there is :)
<fabbione> partition IDs
<infinity> Har.
<fabbione> but still
<fabbione> you don't know if that swap is the one you are allowed to use
<fabbione> so it still the suck
<fabbione> a possible solution would be to generate a uuid
<fabbione> and assign it to the swap as LABEL
<fabbione> that might do
<infinity> Oh wel, for all the noise people make about the dangers of shared swap, using the wrong swap, etc, etc, it seems to be a reasonably uncommonly-tripped bug.
<infinity> People THINK about it far more than they actually get bitten by it.
<fabbione> i would rather avoid to be the one crossburned for that
<infinity> And yes, we could generate a uuid-like label.  Would be ugly in fdisk output, but that's not the end of the world.
<fabbione> i think actually.. that going for LABEL=uuid is a much better approach
<fabbione> because it might allow us to do it for all kind of FS
<fabbione> since LABEL is at partition level
<fabbione> and not FS
<infinity> Do we ge LABELs on all partition tables, or just MSDOS?
<infinity> I get them on PowerPC.  Yay.
<fabbione> no idea
<infinity> Well, MacPPC anyway.
<fabbione> but i guess we do
<fabbione> what fs?
<infinity>  /dev/hda7         Apple_UNIX_SVR2 Debian             55398400 @ 2098368  ( 26.4G)  Linux native
<infinity>  /dev/hda8         Apple_UNIX_SVR2 swap                1136576 @ 57496768 (555.0M)  Linux swap
<infinity> Uhh, ext3, not that that matters.
<fabbione> no, it shouldn't
<fabbione> that's why i was cross checking ;)
<infinity> Not sure if all partition tables have label-like metadata that gets translated, but at least the three release arches would be okay.
<infinity> I don't recall if BSD disklabels and slices do it.
<fabbione> no idea
<infinity> (That was one motivation for UUID, though, is that since it's not at the partition table level, we're not subject to weird architectures and their weird partitioning schemes)
<fabbione> that's why we can use uuid over label protocols
<fabbione> all of this assuming we can stick such a long label
<infinity> Look for uuid, fall back to label, if we have neither, cry?
<infinity> No, we can't have labels that long they'd need to be a bit less unique.
<infinity> DOS labels are... 12 chars?... 16?... I don't recall..  But short.
<fabbione> crap
<fabbione> i suggest we postpone the spec for dapper+1
<fabbione> this is getting already too hairy
<fabbione> hey Keybuk
<fabbione> Keybuk: in about 10 minutes you want to check the irc log for this chan (last 30 minutes discussion)
<fabbione> about probe for root fs
<Keybuk> ok
<Kamion> infinity: DOS labels are 11 characters, according to 'head debian-installer/installer/build/config/x86.cfg'
<Keybuk> *giggle*
<Keybuk> for those following the "Dude?  Where's My DMA?" bug
<Keybuk> it cleared itself up for mdz all by itsself
<Keybuk> with BenC saying the only change to piix was a tweak to the modular IDE driver patch that couldn't POSSIBLY have caused it
<Keybuk> upstream IDE subsystem maintainer has identified the patch causes problems for us
<Keybuk> it's the (you guessed it) modular IDE driver patch!
<Kamion> Keybuk: let me know whenabouts you're uploading udev with the changes I mentioned on IRC last night; I'll need to rebuild d-i with those to get the live CD working
<Keybuk> yup
<Keybuk> will be this morning
<Keybuk> just ploughing through the things everyone sent me overnight for my attention this morning <g>
<Kamion> ta
<fabbione> i wonder if we have dpkg-query in d-i somewhere...
* fabbione adds another item in the things to check
<Kamion> no
<Kamion> no plans to add it either
<Kamion> you can look through /var/lib/dpkg/status in d-i, but obviously that will only list udebs
<Kamion> if you want to inspect /target, chroot to it
<Keybuk> infinity: what's the general stance on useful-things-for-debugging in initramfs
<Keybuk> like lsmod, udevmonitor, etc.
<fabbione> Kamion: yeah the issue is that we can't trust what's in /target ;)
<fabbione> Kamion: that's why i am looking at several different options
<Kamion> fabbione: then you can't trust /target/var/lib/dpkg/status either ...
<fabbione> Kamion: i know. that's why there will be 2 checks available. one that uses status and one that will gather pkgs info from the files installed on the system
<fabbione> but the latter is way slower than the former and prone to more false positives
<fabbione> as it stands now i am implementing all small shell functions do to almost atomic operations that requires less tools as possible
<fabbione> discarding one in favour of another it's easy
<Keybuk> fabbione: you asked me to check the irc log, I assume about the /dev/disk stuff?
<fabbione> Keybuk: yes
<Keybuk> I'm not sure I understand the problem ... the root filesystem knows where the other partitions are
<infinity> Keybuk : I wouldn't be against a DEBUG=yes flag in initramfs.conf that optionally copied in some debug stuff, and could be seen by other hooks (like udevs) to copy debug stuff for them...
<fabbione> Keybuk: no it doesn't... it does if the disk doesn't change name..
<infinity> Keybuk : Not sure we want debug bloat in all initramfs images, hence the flag springs to mind as sane.
<Keybuk> fabbione: the disk is named
<Keybuk> it has a serial number
<fabbione> Keybuk: but we are using uuid exactly because we want to be able to move it around
<Keybuk> you could use /dev/disk/by-id/usb-<MODEL NO>_<SERIAL NO>-part2
<Keybuk> (inside the root filesystem)
<Keybuk> then use root=/dev/disk/by-uuid or whatever to find the root filesystem itself
<fabbione> that won't work either..
<Keybuk> why not?
<fabbione> 0 lrwxrwxrwx 1 root root   9 2005-12-02 09:41 scsi-0ATA_WDC_WD1200JB-00CLinux_ATA-SCSI_simulator -> ../../sda
<fabbione>  <-
<fabbione> this is an IDE disk in a USB external box
<Keybuk> right?
<fabbione> i could remove it from there
<fabbione> stick it in my desktop
<fabbione> that would change to ATA
<fabbione> sorry
<fabbione> ata-*
<Keybuk> use partition labels then
<Keybuk> and /dev/disk/by-label
<fabbione> Keybuk: label can only be 11 chars
<fabbione> there is a high possibility of clashing
<fabbione> the reason why we did chose uuid was exactly because of its meaning
<Keybuk> pretty low probabibility
<Kamion> what's wrong with using /dev/disk/by-uuid/ for the other filesystems too (apart from swap)?
<fabbione> Kamion: not all FS support uuid
<Kamion> Keybuk: quite high if you have two parallel installations done with the same installer
<Keybuk> most the FS we care about support uuid
<Keybuk> for those that don't generate a random label
<fabbione> root on ext3 and home on fancy fs
<fabbione> you are doomed
<Keybuk> that gives you a 1 in 269561249468963094528 chance of clash
<Keybuk> we don't support home on "fancy fs"
<fabbione> Keybuk: yes we do. we still provide the option for manual partitioning
<fabbione> and iirc not all the selectable FS have uuid
<Keybuk> so?  just tell them "uh, no, go back and fix this"
<Keybuk> or for those FS that don't support uuid, generate a randomly unique LABEL and force it upon them
<fabbione> so you would end up with a fstab that will look like: /dev/disk/by-uuid/$longnumber / etc...
<fabbione> and other lines with LABEL=
<fabbione> that will be quite inconsistent
<Keybuk> just use /dev/disk/by-uuid/$uuid and /dev/disk/by-label/$label
<Keybuk> that's not inconsistent
<fabbione> Keybuk: what happens if 2 lables are clashing?
<fabbione> labels even
<fabbione> at udev level.. does it go foobar? or it continues like if nothing happen
<Keybuk> just makes a link for one of them
<Keybuk> and the changes of two labels clashing is incredibly remote
<Keybuk> when we have 250 billion billion installations, we can worry
<fabbione> with 11 chars is a bit less than that
<Keybuk> and that's just assuming we only stick to alphanumerics
<Keybuk> no, that's 11 alpanumeric chars
<fabbione> right
<Keybuk> DOS is 11 8-bit chars, so it's a number so high my computer can't calculate it
<Kamion> in reality people do kinda want labels to be human-readable ;)
<Kamion> or at least PRINTABLE
<Keybuk> indeed
<fabbione> i sort of agree with Kamion
<Keybuk> that's why I stuck to alphanumerics
<Keybuk> hell, if you just limit yourself to upper case and numbers, you're still over a billion billion possible labels
<fabbione> i was wondering if the first 11 digit of md5sum something would do
<fabbione> like md5sum the output of the / uuid with the date in nanosecond
<fabbione> that would probably be almost unique
<Keybuk> why not just pack the / uuid with the partition number or date?
<Keybuk> the / uuid is 37 hex characters
<Keybuk> actually, 33 and 4 -s
<fabbione> yeah
<Keybuk> you could certainly use much of that
<Keybuk> and there are shorter uuid standards too
<infinity> Can we convert base16 to base36? :)
<fabbione> the md5 was to scramble numbers completely
<Keybuk> anyway, this isn't a SKY FALLING problem
<fabbione> no
<Keybuk> there's plenty of ways to identify the partition we want to put the swap on
<fabbione> Keybuk: other than LABEL no...
<Keybuk> there are :p
<Keybuk> we could even go as far as tricks
<Keybuk> we could improve /dev/disk/by-path to create a tree of directories, and then figure out which one the root filesystem is on, then use ../part2 if we REEEEALLLY wanted
<Keybuk> but that's a bit silly
<Keybuk> actually, we probably wouldn't need to improve it at all
<Keybuk> just figure out which /dev/disk/by-path is the root fs
<fabbione> the problem isn't root
<Keybuk> that assumes you want swap on the same disk, of course
<fabbione> we can't assume :(
<fabbione> we would be able to do so only in one condition
<fabbione> getting Kamion to kill manual partitioning
<fabbione> till users are able to do partitions as they like
<fabbione> we are kind of doomed
<fabbione> OR
<fabbione> the possibility is to add all this chunk of code only if they use our recipe's
<fabbione> via guided partitioning
* fabbione eyes the clock and ponders food
<Keybuk> or just make the manual partitioning generate the random label for every new partition
<Keybuk> then if the user changes it to something more readable, which might clash (like "SWAP") that's their problem
<Keybuk> and the bug can be closed with something like
<Keybuk> "This appears to be your foot that you shot, with your gun"
<fabbione> LOL
<fabbione> no really.. we can do it only if they use our Guided stuff
<Keybuk> no, really, we can do it in manual
<fabbione> we can't ensure that the user doesn't have 2 disks
<fabbione> and stick half system on one
<fabbione> and swap on the other
<Keybuk> we don't need to
<fabbione> ok let me eat and think about it
<Keybuk> just use by-uuid for everything that has it, and by-label for things that don't
<fabbione> otherwise i will soon be grumpy ;)
<Kamion> Keybuk: could you put the /dev/discs/ support back into scsi-devfs, please? d-i needs it
<Kamion> and the Debian 076 package has it
<Keybuk> "back into" ?
<Keybuk> is it not there?
<Keybuk> I just used the scsi-devfs script from upstream
<fabbione> Kamion: the hooks i need for that md5sum stuff are in the rescue-udeb right?
<Kamion> Keybuk: it's not there, no
<Kamion> fabbione: rescue-mode
<fabbione> Kamion: thanks
<Kamion> fabbione: see yaboot-installer for (at present) the only example of another udeb using it
<Keybuk> meh, I'll have to see what Debian patches they have for that
<Keybuk> *mutters and grumbles about the installer using obsolete, unsupported and broken scripts* :p
* ..[topic/#ubuntu-boot:Kamion] : known: fb drivers loaded, oss drivers loaded, no network plugging, alsa rules not reloaded, mtab not updated, /dev/pts not mounted, scsi-devfs || fixed: notify-reboot, vio_type segfault, no modules loaded, hal/pcmcia rules not reloaded, nfs root fails, sata root fails, pnp devices not loaded, init stop/start, grepmap bitching
<Kamion> it's gradually getting fixed, but the live CD doesn't have parted_devices so disk-detect falls over
* ..[topic/#ubuntu-boot:Keybuk] : known: oss drivers loaded, no network plugging, alsa rules not reloaded, mtab not updated, /dev/pts not mounted, scsi-devfs || fixed: notify-reboot, vio_type segfault, no modules loaded, hal/pcmcia rules not reloaded, nfs root fails, sata root fails, pnp devices not loaded, init stop/start, grepmap bitching, fb drivers loaded
<Kamion> I've got a patch heading into parted upstream (I hope) to avoid some more of the problems
<Keybuk> *nods*
<Keybuk> getting the installer to eventually search /sys for drives and cds would be much sweeter
<Kamion> it'll just use parted to walk drives
<Kamion> hmm, scsi-devfs.sh seems to be in extra/ and in the .diff.gz; does it come from upstream anyway?
<fabbione> Kamion: it looks pretty simple the README looks clueful
<fabbione> "and" the README..
<Keybuk> it comes from upstream, I guess Marco's copied it and modified it for his own nefarious purposes
<Kamion> oh, meh, it's completely different
<Kamion> it's been in Debian since 0.019-3; I imagine it predates upstream's
<Kamion> fabbione: thanks, I wrote the README ;)
<fabbione> Kamion: that might be why i was able to understand it :)
<Kamion> I'll just use a non-SATA/SCSI system for testing for now
<Keybuk> *giggle* at kay
<Keybuk> after spending most of yesterday evening arguing that there was no reason to run udevd in initramfs, but just place as /sbin/hotplug
<Keybuk> he's now decided we were right after all
<jbailey> Keybuk: ^5!
<Keybuk> hmm
<Keybuk> it seems the ide subsystem could be going away :)
<Kamion> huh?
<HiddenWolf> Huh?
<Keybuk> libata has got parallel ide support now
<Keybuk> and that seems to be strongly favoured to replace much of the ide subsystem
<Keybuk> pretty much how sata is handled
<HiddenWolf> s/away/replaced
<jbailey> Keybuk: I asked about that the other day, and I thought ben said ide-generic would still be needed for a while.
<Keybuk> you didn't dig enough <g>
<Keybuk> right, I think that's all the pile-o-udev bugs solved
<Keybuk> Kamion: what installer issues do you have (currently) ?
<Kamion> Keybuk: scsi-devfs lack of /dev/discs, live filesystem isn't building, casper needs to be updated to do something initramfs-ish instead of pivot_root
<Kamion> I've been concentrating on the live CD rather than on the install CD so it's entirely possible that there are install CD bugs I don't know about yet
<Kamion> I'm rolling new install CDs now and will test them shortly
<Keybuk> I'm looking into the devfs thing now, I think I may just drop that stuff in wholesale from Debian
<makx>  Keybuk: could you take a look at debian #342057, BusLogic not loaded because !sysfs (seems needed for vmware testing of initramfs-tools).
<jbailey> makx: I think we fixed that in the Ubuntu kernel.
<makx> jbailey: you added sysfs hooks? :)
<jbailey> Ben or Fabio did, I think.
<jbailey> I try to stay on this side of userspace. =)
<makx> why's that not upstream :-P
<jbailey>     - [scsi/BusLogic]  Add MODULE_DEVICE_TABLE
<Keybuk> it probably is upstream by now
<jbailey>  -- Ben Collins <bcollins@ubuntu.com>  Sat, 12 Nov 2005 23:34:38 -0500
<jbailey> From the 12th to now, it's hard to guess.
<jbailey> I know there's alot queued to go upstream.
<makx> a quick grep in git-commits-head shows it's not yet landed for linus.
<makx> jbailey: anyway thanks for the hint, good news. :)
<jbailey> makx: Or perhaps check with BenC in #ubuntu-kernel
<makx> jbailey: for now i'll include it in d-kernel, but yes.
<Keybuk> Kamion: wow, I see what you mean about these scsi-devfs scripts being totally different
<Keybuk> they aren't even related
<Kamion> right, I don't think they share ancestry
<Keybuk> the upstream one looks far more complete
<Kamion> it does a lot of stuff I don't care about ;-)
<Keybuk> what do you actually care about/
<Keybuk> do you need all the /dev/bus/*, /dev/scsi/*, etc.
<Keybuk> or do you just want /dev/cdroms and /dev/discs ?
<Kamion> /dev/scsi/ is good, I don't especially care about /dev/bus/ personally
<Kamion> I don't think I actually NEED /dev/scsi/ though
<Keybuk> I'm trying to work out how to make this work
<Keybuk> we plug all the disks at once, so get_next_number returns 0 for every single disk
<Keybuk> what I'm wondering is ...
<Keybuk> if I throw all of this away
<Keybuk> and instead replace it with a small "enumerate disc-like objects" helper that just makes /dev/discs and /dev/cdroms
<Keybuk> would that be sufficient for the installer?
<Keybuk> or does it really need /dev/ide and /dev/scsi ?
<Kamion> no, it doesn't need those
<Kamion> I use them occasionally but I can easily adjust
<Keybuk> so it really just relies on /dev/discs and /dev/cdroms ?
<Kamion> yep
<Keybuk> how about /dev/floppies?
<Kamion> /dev/floppy
<Kamion> floppy-retriever looks for /dev/floppy/0
<Keybuk> does it matter if there are gaps in the numbering, btw?
<Kamion> /dev/floppy/0 has to be thus, for the rest probably not
<Keybuk> how about for cdroms and discs?
<Kamion> "for the rest probably not"
<Keybuk> ah, sorry
<dilinger> Kamion: any chance of seeing my parted /sys/block patches making it into parted
<dilinger> ?
<dilinger> for ubuntu's installer
<Kamion> dilinger: have they gone upstream / to Debian?
<Kamion> I've got parted back into sync now, would be kind of a shame to branch again
<Kamion> I can if need be though, file me a bug
<dilinger> Kamion: they have gone upstream; I have no idea debian's status w/ them
<Kamion> Debian's tracking upstream pretty closely
<dilinger> upstream seems to want me to assign copyright to the FSF, but doesn't seem to be able to put me in contact w/ whomever i need to talk to about that
<dilinger> *shrug*
<Kamion> file a bug and I can keep an eye on it
<Kamion> I've done FSF copyright assignment; you can probably just mail their clerk
<dilinger> Kamion: file a bug in which bts?
<Kamion> Ubuntu
<dilinger> bugzilla?  malone?
<Kamion> bugzilla
<Kamion> http://www.fsf.org/licensing/assigning.html - the maintainer is supposed to send you the questionnaire though
<dilinger> well, it's svenl who's expressed interest in the patch, but i guess he wanted otavio to mail me or something
* dilinger shrugs
<dilinger> ok, submitted
<Kamion> thanks
<Keybuk> Kamion: http://people.ubuntu.com/~scott/storage_enum.sh
<Kamion> I'll take your word for it on the implementation, but the intent looks plausible
<Keybuk> that should actually fix our current problems too, as it should reliably never use the same number twice
<Kamion>    * Update installer startup script to use "cp -au" like the init script,
<Kamion>      instead of "cp -af".
<Kamion> Keybuk: please revert that - busybox cp doesn't have -u
<Keybuk> d'oh
<Keybuk> tsk
<Keybuk> busybox sucks
<Keybuk> it has a -f that doesn't behave like the real one
<Keybuk> and then doesn't have -u
<Kamion> and in any case I'm sure it was the "cannot be opened" trap I hit
<Keybuk> reverted that bit
#ubuntu-boot 2008-12-05
<Tomay>  I downloaded UBUNTU 8.10 DVD & burned it & when booting from the dvd an error message: as below
<Tomay>  [xxx.xxxxxx] Buffer I/0 error on device sr0, logical block xxxxxx
<Tomay>  Help me PLEASE :(
#ubuntu-boot 2010-12-10
<seriousguy> does the server cd support text installs? I am trying to get a install going over a sun x4100 ilom
