=== superm1|away is now known as superm1
=== persia_ is now known as persia
[08:39] <persia> I'm running ubiquity from a custom image, and get a "Fatal IO error 11" from X.  The only reference I can find to this from Google is that it may be related to threading and locking.  Would anyone happen to have any ideas why it might be encountered during an install?
[09:47] <famicom> oi
[09:47] <famicom> where in the hell can i find the info i need for installing a base system from a full desktop iso
[10:11] <famicom> anyone
[10:25] <cjwatson> famicom: the desktop CD is really only designed for installing the whole thing, but you can install the debootstrap package and use that
[10:25] <famicom> cjwatson ah
[10:25] <famicom> you are the author right
[10:26] <famicom> ok, well, for fucks sake which goddamn files does it use and in which GODDAMN MOTHERFUCKING ORDER
[10:26] <famicom> AHADFKJHASDKLJH
[10:26] <famicom> aargh
[10:26] <famicom> my sincere aplogies for that
[10:27] <cjwatson> famicom: if you want me to answer, please be civil
[10:27] <cjwatson> also, be specific :-) I'm not going to give you a full list of all the files ubiquity uses, since there are rather a lot
[10:28] <cjwatson> famicom: if you want to do any kind of customised install of only certain packages or whatever, the alternate install CD is really much better set up for that kind of thing
[10:28] <famicom> yeah, i know, thats what i would usually do
[10:29] <famicom> but right now i'm dealing with some weird messed up system
[10:29] <cjwatson> the only way ubiquity knows how to install a system is to copy the live filesystem across, and possibly remove some packages from it
[10:30] <famicom> ah yeah
[10:30] <cjwatson> so your choices are to strip down the live filesystem, or to convince it to remove lots more packages (which would be very slow of course)
[10:30] <famicom> i read that
[10:32] <famicom> quick offtopic question
[10:32] <famicom> why the name casper
[10:35] <famicom> and what are the files in /cdrom/preseed for
[10:38] <cjwatson> casper the friendly ghost: it does magic to make the live filesystem boot
[10:38] <famicom> :)
[10:38] <famicom> ok, well some things are messing with me
[10:38] <famicom> http://bazaar.launchpad.net/~ubuntu-core-dev/ubiquity/trunk/annotate/2680?file_id=README-20051205083553-550dab3cb68ad622
[10:39] <famicom>  Ubiquity will remove any packages present in filesystem.manifest but not present in filesystem.manifest-desktop
[10:41] <cjwatson> the preseed files aren't really a lot of use on the desktop CD, at least not for Ubuntu; I think there are some corner cases for flavours other than Ubuntu where it's helpful to have them there
[10:41] <cjwatson> right
[10:41] <famicom> ah
[10:41] <famicom> hold on
[10:41] <famicom> now i get it
[10:43] <famicom> if i were to edit filesystem.manifest-desktop that would mean that a bunch of packages i dont want would be removeed?
[10:44] <cjwatson> right
[10:44] <cjwatson> we use it mainly to arrange that things like ubiquity itself don't end up on the installed system
[10:45] <famicom> ah
[10:45] <famicom> you should tell that to some of the fucktards that vomit out their own "custom editions"
[10:46] <cjwatson> it's not the neatest system in the world, but it's tough to reconcile configurability with the fact that ubiquity simply doesn't have .deb files in its hands to install in most cases
[10:46] <famicom> yeah
[10:46] <cjwatson> I generally wash my hands of custom editions, though if they come to us for help we're happy to provide it
[10:47] <famicom> yup
[10:47] <famicom> but, thanks for the info
[10:47] <famicom> now i can just run apt-rdepend ubuntu-minimal
[10:48] <famicom> and diff its output against  against filesystem.manifest-desktop
[10:49] <cjwatson> you might want ubuntu-standard too, depending on what you're doing
[10:50] <cjwatson> you probably also want to leave the kernel in there
[10:50] <cjwatson> and it will be incredibly slow and require lots of disk space temporarily
[10:51] <cjwatson> I'm curious why debootstrap wouldn't be easier; are you intending to present this to your users or something?
[10:51] <famicom> not really
[10:52] <famicom> but i've had times where i were stuck with nothing but a usbstick containing the livesystem
[10:58] <famicom> ah well
[10:58] <famicom> I've figured it out
[10:58] <famicom> thanks for your input
[11:00] <cjwatson> ok, good
[11:01] <famicom> one question though
[11:01] <famicom> why not jus switch to the debian-installer
[11:01] <famicom> and fiddle about with debconf
[11:02] <persia> famicom: There isn't really space for both a live system and a sufficient repository to support d-i on one CD.  There are alternate CDs provided for Ubuntu.
[11:02] <persia> The alternate CDs use d-i.
[11:03] <famicom> just do it the debian way
[11:03] <famicom> base system on cd, rest downloaded
[11:04] <cjwatson> very much slower, and we didn't want to require a network connection
[11:05] <cjwatson> while this way isn't as configurable, configurability was secondary to how well it worked for most users
[11:05] <cjwatson> we do use bits of d-i under the hood. I'm a d-i developer and spent a *long* *time* trying to get other approaches to work well before settling on this one
[11:06] <cjwatson> persia: where's "Fatal IO error" even coming from? I don't see it in xorg-server
[11:06] <cjwatson> persia: I wonder if it means signal 11 (i.e. segfault) though? is there anything interesting in other logs?
[11:22] <persia> cjwatson: I didn't find much, but I can repeat it reliably.  I'll reproduce now, and let you know if I find anything in the resulting system state.
[11:23] <persia> From what I can find online, it seems to be a resource contention issue.
[11:24] <cjwatson> errno 11 is EAGAIN
[11:25] <persia> Hrm.  Maybe.  This is "Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0"
[11:26] <persia> Might be something about my image though: I'm running off a USB stick, rather than a CD.
[11:38] <persia> cjwatson: I get two lines in /var/log/installer/debug: the ubiquity version, and the Fatal IO error.  That error then gets passed to xterm, and to sapwood server, and to X, and I end up in a VT.
[11:39]  * persia tries again, enabling -d in the hopes of more logs
[11:44] <persia> Well, no.  It seems I need to reimage my USB stick.  Are there any logs that would be interesting to check prior to refreshing the stick and rerunning with -d?
[11:44] <cjwatson> if you got -d working-ish, /var/log/installer/debug *might* have something; but it sounds like X itself is the thing falling over here
[11:45] <persia> Well, X failing is only a side effect of trying to run it under hildon-desktop.  I can clearly trace the crash through the stack.
[11:46] <persia> That said, it may well be some interaction that ubiquity isn't suspecting.  I'll try -d both within and external to the environment, and see if I find any useful differences.
[11:47] <cjwatson> do other pygtk/glade applications work?
[11:48] <persia> Generally yes, but I haven't tested with this specific image (and just started to re-dd my key).  I'll check update-manager to make sure when I next boot.
[13:07] <CIA-45> libdebian-installer: cjwatson * r182 ubuntu/ (debian/changelog src/exec.c src/parser_rfc822.c):
[13:07] <CIA-45> libdebian-installer: * Backport from trunk:
[13:07] <CIA-45> libdebian-installer:  - Appease the combination of _FORTIFY_SOURCE=2 (used by default on
[13:07] <CIA-45> libdebian-installer:  Ubuntu) and -Werror. Why exactly glibc demands that fwrite be checked
[13:07] <CIA-45> libdebian-installer:  but not fputs is beyond me.
[13:07] <CIA-45> libdebian-installer: cjwatson * r183 ubuntu/debian/ (changelog control): Ubuntu Maintainer address
[13:14] <CIA-45> libdebian-installer: cjwatson * r184 ubuntu/debian/changelog: releasing version 0.59ubuntu1
[13:33] <persia> cjwatson: update-manager seems to run OK.  Indeed, as you describe, X itself is falling apart, rather than ubiquity.  It seems to happen during the debconf questioning, although not always in the same place.
[13:33] <persia> I'll go chase X, but if you've any ideas why ubiquity might do this when some other applications don't, I'd be interested to try to figure it out.
[13:33] <cjwatson> don't suppose you can get an strace?
[13:33] <cjwatson> it might be file descriptors being attached a bit wrongly
[13:34] <cjwatson> are you using ubiquity-dm, or are you starting ubiquity from a terminal inside X?
[13:34] <cjwatson> err, obviously, don't try to strace X from inside X ;-)
[13:34] <cjwatson> (I tried that once in a moment of inattention and the whole session locked up in about a microsecond)
[13:35] <persia> heh.
[13:35] <persia> I can get an strace, and can strace X.
[13:36] <persia> The two different tests were running ubiquity from a terminal within X under hildon-desktop (this actually runs it as part of the hildon-desktop process), and running it externally from a VT after setting DISPLAY appropriately.
[13:39] <persia> Or maybe not.  Apparently my image was corrupted again.  I'll recopy, and get an strace.
[13:39] <cjwatson> you seem to have some reliability problems :(
[13:40] <persia> Indeed. :(  This key has worked fine for lots of things, but my experiences with the current set of images are much less than might be desired.
[13:42] <persia> On the other hand, I suspect I'm having something be overwritten when I'm crashing X, perhaps especially in the middle of an install, rather than suspecting my hardware.  I can still use older images with some success.
[14:12] <persia> I've collected the straces, reading through them now.  Is there anything specific of interest for which I ought be looking?
[14:16] <cjwatson> I think I'd be inclined to search down for the error string you're seeing and then look upwards from that for the actual syscall that fails
[14:19] <persia> Near the end of the ubiquity strace, I have about 500 EAGAINs, and above that a timeout on a select, an illegal seek on _llseek, mmap2, fstatt53, fcntl64, somewhat repititionsly, and then a clone above that.  I'm guessing the clone is the call out to debconf, but that's just a guess.
[14:19] <cjwatson> oh, yes, if you're stracing ubiquity it definitely needs to be with -f
[14:20] <persia> Oh.  I'll try that then :)
[14:22] <persia> I didn't see the reported error in the X stacktrace: it seemed to normally start, and normally exit, although I don't really understand why it exited.
=== superm1 is now known as superm1|away
=== superm1|away is now known as superm1
[17:10] <persia> cjwatson: I can repeatedly not run ubiquity at all under strace -f, whereas it runs under strace.  Any other suggestions on how to get to the interesting bit?
[17:11] <persia> Well, it runs, but it generates no X events, and doesn't update the logs.
[20:07] <CIA-45> ubiquity: evand * r2783 ubiquity/ (configure configure.ac): bump to 1.9.11
[20:19] <CIA-45> ubiquity: evand * r2784 ubiquity/ (d-i/manifest debian/changelog):
[20:19] <CIA-45> ubiquity: Automatic update of included source packages: console-setup
[20:19] <CIA-45> ubiquity: 1.25ubuntu3, partman-auto 78ubuntu2, partman-base 121ubuntu5,
[20:19] <CIA-45> ubiquity: partman-basicfilesystems 60ubuntu2.
[20:28] <CIA-45> ubiquity: evand * r2785 ubiquity/debian/changelog: releasing version 1.9.11
[22:39] <superm1> evand, ping.  i just wanted to remind you regarding that bug to add nvidia drivers to the dvd seed and reroll dvds.  with alpha5 coming up really soon, we'd really like to make sure that part of our install works right