[00:29] <CIA-50> ubiquity: cjwatson * r2866 method-filesystem-split/ (4 files in 3 dirs):
[00:29] <CIA-50> ubiquity: Automatically set the method when the mount point is set or unset
[00:29] <CIA-50> ubiquity: (LP: #274297).
[01:01] <CIA-50> partman-base: cjwatson * r107 ubuntu/ (3 files in 3 dirs): Exit straight away if a called script is killed by a signal.
[01:02] <CIA-50> partman-auto: cjwatson * r271 ubuntu/ (choose_partition/auto/do_option debian/changelog): Exit straight away if a called script is killed by a signal.
[01:03] <CIA-50> partman-partitioning: cjwatson * r686 ubuntu/ (debian/changelog free_space/new/do_option): Exit straight away if a called script is killed by a signal.
[01:18] <CIA-50> ubiquity: cjwatson * r2867 method-filesystem-split/ubiquity/ (components/partman.py frontend/gtk_ui.py frontend/kde_ui.py): fix filesystem editing
[01:24] <CIA-50> ubiquity: cjwatson * r2868 method-filesystem-split/ubiquity/frontend/gtk_ui.py: pass filesystem name when creating partitions, not description
[01:37] <CIA-50> ubiquity: cjwatson * r2863 ubiquity/ (3 files in 2 dirs):
[01:37] <CIA-50> ubiquity: When creating a new partition, default to logical if a primary partition
[01:37] <CIA-50> ubiquity: already exists, since there are stricter constraints on primary
[01:37] <CIA-50> ubiquity: partitions and the only real reasons for them are Microsoft operating
[01:37] <CIA-50> ubiquity: systems or boot partitions (LP: #218938).
=== superm1|away is now known as superm1
[08:11] <yannickm1> hi.... Can someone give me hand to solve a problem with installer CD customization?
[08:13] <yannickm1> *knock knock* anyone ?
[08:14] <superm1> yannickm1, it's a little bit early in the morning for the european work day.  if you hang out for a bit, someone should pop in that can help you out a little bit
[08:15] <yannickm1> oic :)
[08:16] <yannickm1> i'll try later on then... I'm in australia lol
[08:16] <superm1> yannickm1, your best bet is to leave yourself idle in here and pose the question you're having
[08:16] <superm1> check back later on then
[08:16] <yannickm1> yeah i'll try in the evening from home
[08:16] <yannickm1> thanks :)
[09:05] <yannickm1> Hi... I'm having some major pains customizing a ubuntu CD (spend many hours tracking down the reason, and down to having located the problem happens when i replace the ubuntu-keychain with my own which includes my key to sign the repositories. However the package i've created seems fine and i can't find any reason what is wrong). The problem it's causing is that in the networking bit, it's trying to use PPPOE when it shouldn
[09:14] <yannickm1> persia ?
[09:14] <persia> Yes?
[09:14] <yannickm1> I was wondering if you could help with a bizzare problem i'm having with a ubuntu cd customization
[09:15] <yannickm1> spend many hours tracking down the reason, and down to having located the problem happens when i replace the ubuntu-keychain with my own which includes my key to sign the repositories. However the package i've created seems fine and i can't find any reason what is wrong). The problem it's causing is that in the networking bit, it's trying to use PPPOE when it shouldn't (failing of course)
[09:15] <yannickm1> any idea why changing the keychain causes ppoe to occur ? :(
[09:17] <persia> No idea at all how a change in the keyrings could do that.  Are you sure it's not that changing the keyrings changed the trust in some other package, which causes the change?
[09:18] <yannickm1> possibly
[09:18] <yannickm1> but the old keys are in the keyring, so it shouldn't be problem
[09:18] <yannickm1> i have a script that takes an iso (been trying with server), and rebuilds a new one
[09:20] <yannickm1> i've just kinda ran out of ideas.. and i don't know how to track down the problem further... that script is the minimum i could in terms of modifications
[09:21] <yannickm1> that's why i came to this channel in hope of finding someone with some time and expertise in the installer to identify the issue :)
[09:27] <persia> Hrm.  I may not be entirely the right person then :)  I have been learning about the various quirks of ubiquity and d-i to support live images for some flavours, but all my work has been based on the assumption of a working liveCD, and it sounds like your issue happens earlier in the process.
[09:27] <yannickm1> ok thanks... i'll wait for more ppl get be online then :)
=== cjwatson_ is now known as cjwatson
[10:58] <cjwatson> yannickm1: I think you're best off making customised CDs unsigned
[10:59] <cjwatson> yannickm1: PPPOE getting pulled in sounds like you accidentally fed the installer udebs from universe or something
[11:10] <persia> I've another preseeding question.  With the fix to 182004, I've gone back to working with --automatic, but it appears that setting a blank password isn't working.  Do I need to use a construction like "", or should just "d-i passwd/user-passwd password" and "d-i passwd/user-password-again password" be sufficient?
[11:12] <cjwatson> the latter ought to be sufficient
[11:12] <cjwatson> after you've fixed the typo in the first bit
[11:12] <cjwatson> oh, but user-setup won't accept a blank password, probably
[11:13] <cjwatson> you'd have to add a preseedable thing to permit forcing that
[11:13] <persia> The typo exists only in IRC.  I'll look at user-setup.  Thanks.
[11:46] <CIA-50> ubiquity: cjwatson * r2864 ubiquity/ (5 files in 3 dirs): Initialise auto-login checkbox from debconf database (LP: #276247).
[12:20] <davmor2> strange one for you.  Ubuntu, Xubuntu, Kubuntu all get a usplash for the installed system from netboot however edubuntu doesn't :-/
[12:23] <davmor2> I just checked edubuntu artwork and usplash 0.1.0-55ubuntu1 are both installed so I'm guessing it should be displayed?
[12:30] <cjwatson> dpkg -l usplash-theme-ubuntu edubuntu-artwork-usplash, please
[12:31] <cjwatson> and check whether splash is in /boot/grub/menu.lst
[12:31] <davmor2> splash is in yes
[12:32] <davmor2> usplash-theme-ubuntu = 0.19
[12:33] <davmor2> edubuntu-artwork-usplash = 0.1.0-55ubuntu1
[12:34] <cjwatson> all sounds as expected. you'll need to talk to Edubuntu folks
[12:35] <cjwatson> i.e. the installer is behaving as intended
[12:35] <davmor2> cjwatson: okay thanks :)
=== davmor2 is now known as davmor2-lunch
[13:05] <tckb> can anybody tell me whos the creater of ubiguity
[13:09] <tckb> fuck u
[13:09] <tckb> all
[13:09] <tckb> here
[13:11] <TheMuso> Lovely.
[13:36] <persia> Grrr.  I completely forgot to fix debian/rules when adding grub support to lpia for ubiquity.  Any chance of an upload for beta, or did I miss.
=== nasrat_ is now known as nasrat
[13:43] <persia> Actually, never mind.  There's something else wrong too.  It's not worth delaying anyone else for my mistake.
=== davmor2-lunch is now known as davmor2
[14:19] <lool> Heya
[15:10] <yannickm1> Hi... Can anyone help me with an installer problem... I've been trying to customize a ubuntu cd. but after i customize it, in the network setup fase, it tries to bring up PPPOE when it shouldn't (failing of course). I spent many hours tracking down the reason, and got down to having located the problem happening when i replace the ubuntu-keychain with my own which includes my key to sign the repositories, plus repackaging/re
[15:22] <davmor2> xivulon: just running the wubi tests now :)  Umenu update has fixed the invalid disc message :)
[15:24] <yannickm1> anyone can provide some help with tracing the issue ?
[15:30] <cjwatson> yannickm1: I already answered you earlier today
[15:31] <cjwatson> 10:58 <cjwatson> yannickm1: I think you're best off making customised CDs unsigned
[15:31] <cjwatson> 10:59 <cjwatson> yannickm1: PPPOE getting pulled in sounds like you accidentally fed the installer udebs from universe or something
[15:31] <cjwatson> yannickm1: for anything beyond that, I'd need to see the installer syslog
[15:31] <yannickm1> oic
[15:32] <yannickm1> i can just make it unsigned, it doesn't verify or anything ?
[15:32] <yannickm1> i did a comparison of the Packages files, and they contain exactly the same
[15:32] <yannickm1> packages
[15:33] <cjwatson> it does verify it if the signature is there, but it *should* work if you just delete Release.gpg as well
[15:33] <cjwatson> let me know if it doesn't
[15:33] <yannickm1> what could cause it to pull in others ?
[15:33] <cjwatson> anyway, there is no reason that makes sense to me why that should affect pppoe
[15:33] <cjwatson> please put the installer syslog somewhere I can see it
[15:33] <yannickm1> can i send you that by email ?
[15:33] <cjwatson> I'd prefer you found some other way
[15:33] <cjwatson> paste.ubuntu.com or something
[15:34] <yannickm1> interesting didn't know about that one lol
[15:34] <yannickm1> k i'm guessing you probably are around here frequently so i'll pop by
[15:34] <cjwatson> I am, yes
[15:35] <yannickm1> so by the way tell me if i understand correctly how the installer works
[15:35] <cjwatson> it's the sort of thing that *could* happen due to some kind of signature problem, but it would be an indirect effect at most
[15:35] <yannickm1> the debs used by the installers are the ones in the installer 'Packages' file right ?
[15:35] <cjwatson> ok, there are two Packages files on the CD
[15:36] <cjwatson> well, actually, more, but two types
[15:36] <yannickm1> yup
[15:36] <cjwatson> /dists/hardy/*/binary-*/Packages refers to .debs; those include what gets installed on the target system
[15:36] <cjwatson> /dists/hardy/*/debian-installer/binary-*/Packages refers to .udebs; those are components of the installer itself
[15:37] <yannickm1> yup that was my assumption
[15:37] <yannickm1> so for PPPOE to get activated, it has to have the correct udeb in the packages, which by default isn't the case... is that correct ?
[15:39] <cjwatson> right, I think it's in ppp-udeb or else pppoe-something
[15:39] <cjwatson> I don't believe we ship that by default
[15:40] <cjwatson> it would really be a lot easier if I could see the log, though. :)
[15:40] <yannickm1> hmm... i see... i was doing the customization of a server CD btw ... Yup i'm trying to setup one in a VM... i have the logs but on my laptop at the office
[15:41] <yannickm1> so in terms of signatures, is there any checks done during installation ?
[15:43] <cjwatson> yes, if Release.gpg is present
[15:43] <cjwatson> the installer is supposed to be set up to allow unauthenticated repositories on the CD as well, though
[15:43] <yannickm1> hmm... i see
[15:44] <yannickm1> ok well then i'll give it a try unauthenticated... thanks for the help !!!
[15:47] <davmor2> xivulon: You around?
[16:03] <CIA-50> ubiquity: cjwatson * r2869 method-filesystem-split/ (4 files in 3 dirs): merge from trunk
[16:06] <CIA-50> ubiquity: cjwatson * r2865 ubiquity/debian/ (ubiquity.install-lpia changelog rules): Add some more grub pieces on lpia.
[16:06] <cjwatson> persia: ^- should fix your problems I think
[16:06] <davmor2> xivulon: when you get this jockey is a bit temperamental in the wubi install.
[16:12] <persia> cjwatson: Does that include the addition of the ntfsprogs dependency that was also in my local testing branch but not yet committed?
[16:13] <cjwatson> no, I wasn't sure if you wanted that
[16:13] <cjwatson> if you do, I'll add it
[16:13] <cjwatson> I think that needs a partman-partitioning change though
[16:13] <persia> I do.  I've been preparing a branch adding the grub and ntfsprogs dependencies in debian/rules, and adding ubiquity.install-lpia.
[16:14] <persia> I'll go look there then.  I got a new laptop last week, that was lpia, and came with Vista installed, so I suspect it's probably best to support ntfs.
[16:14] <cjwatson> I'll just do it now
[16:15] <persia> OK.  Thank you.
[16:15]  * persia goes back to the interrupted investigation of user-setup to force preseeding of blank passwords
[16:15] <CIA-50> partman-partitioning: cjwatson * r687 ubuntu/debian/ (changelog rules): Add NTFS dependencies on lpia.
[16:16] <CIA-50> ubiquity: cjwatson * r2866 ubiquity/debian/ (changelog rules): Add ntfsprogs dependency on lpia.
[16:43] <lool> cjwatson: Is there a chance ubiquity be reuploaded before beta?
[16:43] <cjwatson> I hadn't been planning on it. Is it a showstopper?
[16:43] <cjwatson> (and if so this discussion should be on #-release)
[16:44] <lool> cjwatson: I think this bug prevents successful installation, but I don't think it should delay beta for the other images as our installation was always borken
[16:44] <lool> And we use dailies for testing anyway
[16:47] <persia> lool: Our preseed is broken anyway, so just pushing ubiquity doesn't solve everything.
=== superm1 is now known as superm1|away
[16:47] <lool> persia: What's the issue with the preseed?  is this related to the changes to the seen flags?
[16:48] <persia> lool: It's related to user-setup wanting passwords not to be zero characters in length.
[16:49] <lool> persia: But can't StevenK easily fix our preseed?
[16:50] <persia> lool: Yes, but then we have different behaviour than desired, because the user has a password.
[16:51] <lool> Sorry, you're saying our preseed is broken; can't StevenK fix it in whatever way is needed?
[16:52] <persia> No, I'm saying that d-i doesn't support the preseed as written.
[16:52] <persia> The preseed is correct, it's just not supported.
[16:54] <cjwatson> right
[16:54] <cjwatson> user-setup refuses this, which is correct for interactive use
[16:55] <cjwatson> but it should be made possible to preseed something else
[16:56] <persia> RIght, so I'm fiddling with user-setup to have a new passwd/user-no-password boolean which defaults to false to allow this.
[16:57] <cjwatson> could you call it passwd/allow-empty-password please to match the error template better?
[16:57] <lool> Ok, I understand the issue better
[16:58] <persia> Sure.  No problem.
[16:58] <lool> Thanks
[16:58] <persia> Thanks for the suggestion.
=== superm1|away is now known as superm1
[17:27] <kirkland> cjwatson: hey, strange happening with raid installs, perhaps you have an idea...
[17:28] <kirkland> cjwatson: when doing the partitioning in the installer, it seems imperative that the underlying RAID partitions are *not* marked "bootable"
[17:28] <kirkland> cjwatson: as long as that's the case, the grub-install against /dev/md0 works fine, and the installed system behaves as expected
[17:28] <cjwatson> imperative at what stage?
[17:29] <kirkland> cjwatson: however, if the underlying RAID partition is marked "bootable", the installation succeeds, but the system is not bootable
[17:29] <kirkland> cjwatson: yielding a segfault in kvm
[17:29] <kirkland> cjwatson: i have not yet tried real hardware
[17:29] <cjwatson> oh, right
[17:29] <cjwatson> that ought to be relatively simple to account for
[17:30] <kirkland> cjwatson: this sounds familiar to you?
[17:30] <kirkland> cjwatson: or, at least, you can put me on the trail?
[17:30] <cjwatson> well, the bootable thing may be what the BIOS chains to
[17:30] <cjwatson> or at least tries to chain to
[17:30] <kirkland> cjwatson: you reckon i should look to solve this in kvm, or in the installer?
[17:30] <cjwatson> both :-)
[17:30] <kirkland> :-)
[17:31] <cjwatson> a kvm segfault is clearly a kvm bug
[17:31] <kirkland> cjwatson: yeah
[17:31] <cjwatson> but we perhaps shouldn't mark RAID partitions as bootable either
[17:31] <cjwatson> I don't know, was /boot in the RAID partition?
[17:31] <kirkland> cjwatson: right, i was thinking about just manually overriding that in the installer bits
[17:31] <cjwatson> also, did you mark any of the partitions as bootable at the partitioner stage?
[17:31] <kirkland> cjwatson: yeah, everything on one big raid partition
[17:31] <cjwatson> or did you just leave all of them unbootable?
[17:32] <cjwatson> you see, there's an awkward conflict here ...
[17:32] <cjwatson> there are some BIOSes that will refuse to boot, period, if there's no bootable partition at all
[17:32] <kirkland> cjwatson: if i mark nothing "bootable", everything works fine
[17:32] <cjwatson> on your BIOS
[17:32] <kirkland> ah, erg
[17:32] <cjwatson> seb128 ran into this in the 5.04 cycle
[17:32] <cjwatson> so I know it happens in practice :)
[17:33] <kirkland> k
[17:34] <cjwatson> so if you only had one big RAID partition, then I think that needs to be fixed in kvm
[17:44] <kirkland> cjwatson: okay, so work items are ...
[17:44] <kirkland> cjwatson: 1) teach KVM to deal with raid partitions marked "bootable"
[17:44] <xivulon> davmor2: hi
[17:45] <kirkland> cjwatson: actually, i think if I could solve (1), that might take care of the problem
[17:45] <davmor2> xivulon: hello
[17:45] <davmor2> xivulon: wubi is missing the progress bar on uninstall in vista it lags on xp but is there
[17:46] <xivulon> sorry could you rephrase?
[17:47] <davmor2> xivulon: in vista when you remove the wubi install the progress bar doesn't move.  In Xp it lags behind the text but is there
[17:48] <xivulon> is the progressbar at zero or at an intermediate level?
[17:48] <davmor2> zero
[17:48] <davmor2> never shows at all the text is correct at the bottom of the uninstaller window but no bar
[17:49] <xivulon> I think I know the reason, could you open a bug report if you haven't done so already?
[17:49] <xivulon> in any case the uninstaller should be very quick
[17:49] <davmor2> donehttps://bugs.edge.launchpad.net/wubi/+bug/276389
[17:49] <davmor2> xivulon: it is but it is noticeable too
[17:49] <cjwatson> kirkland: yes, I think that's it
[17:50] <kirkland> cjwatson: okay, i'll see what i can do with that
[17:51] <xivulon> I have assigned it to me
[17:51] <xivulon> davmor2 what was the other issue about jockey?
[17:51] <xivulon> I must admit I haven't used jockey so far
[17:53] <davmor2> xivulon: Jockey wouldn't download the nvidia drivers.  However after shutting jockey down and trying again it worked fine and it's happen a couple of times
[17:54] <xivulon> is jockey launched by ubiquity or is it run post-install?
[17:54] <cjwatson> jockey is not launched by ubiquity
[17:54] <davmor2> post-install
[17:54] <xivulon> could that be a race condition in networking?
[17:55] <xivulon> not sure why wubi would interfere in such case though
[17:56] <davmor2> could be on both times it's happened I've run other tests and and come back to it and it's been fine
[17:57] <xivulon> then it is probably a jockey issue
[17:57] <davmor2> I don't think it's anything major
[17:57] <xivulon> by the way cjwatson and evand, we did some preliminary testing with mythbuntu in wubi together with superm1 and seems ok
[17:57] <davmor2> xivulon: ah but it doesn't happen when I use it on a normal install
[17:57] <evand> fantastic
[17:57] <cjwatson> good to hear
[17:57] <davmor2> nice one
[17:58] <xivulon> there is no need though to change the wubi build that ships on the other ubuntu ISOs
[17:58] <evand> xivulon: how is wubi in 8.10?  Any critical issues?
[17:58] <evand> ah, great
[17:58] <xivulon> evand, not that I am aware of.
[17:58] <superm1> xivulon, i've got another daily that will at least have that .disk/info file fixed.  I'll be experimenting with the preseed tonight to see if I trigger any unexpected behavior
[17:59] <xivulon> so the plan for mythbuntu might be to ship a new version of wubi only in mythbuntu ISO and in the stand-alone on ubuntu.com
[17:59] <xivulon> thus minimizing delta
[17:59] <xivulon> in any case the version on CD will only allow the CD distro, so it makes no difference
[18:00] <xivulon> evand, it wouldn't hurt though if you also tested wubi/umenu :)
[18:00] <evand> xivulon: can you elaborate on what you mean by "CD distro"?
[18:00] <evand> xivulon: as soon as I get a working VMWare on 2.6.27 :)
[18:00] <xivulon> in return I will test usb installer (have to buy a new usb card though)
[18:01] <xivulon> evand I mean each CD is specific for a particular distro, if you run Wubi off the Xubuntu CD you can only select "Xubuntu" in the desktop environment selector of wubi
[18:01] <evand> Yeah, I should pick up another one and test two at a time (unless someone knows how to create fake devices for HAL)
[18:01] <xivulon> hence there is no need to add mythbuntu in there
[18:02] <evand> well, there is in the sense that we want to keep all the code centralized, but I see the point you're making.
[18:02] <xivulon> On my side is a small change, mostly implies a different isolist.ini and one or two preseed templates
[18:03] <evand> indeed
[18:03] <xivulon> we'll decide though once we have more testing
[18:04] <xivulon> the bugs I have open are: 204133 where I committed the change in wubi but I am waiting for cking to have an opinion
[18:04] <xivulon> basically last time myself and davmor2 tested syncio support for ntfs the performance hit was considerable
[18:04] <xivulon> so I am not sure it is a good idea to turn it on
[18:05] <evand> ah, indeed
[18:05] <xivulon> see the last few comments on the bug
[18:05] <xivulon> Also there is 243105, because of it, we are still extracting the full ISO now, even though that sometimes fails
[18:06] <xivulon> ah one thing I wanted to ask, cjwatson, if you remembered in 8.04 we moved keyboard/locale settings from preseed to boot arguments
[18:07] <xivulon> I assume there is no need to change it back
[18:08] <cjwatson> not to my knowledge ...
[18:09] <xivulon> I will leave it like that then unless someone complains
[18:12] <xivulon> davmor2: on jockey can you try to get some logs?
[18:13] <CIA-50> partman-partitioning: cjwatson * r688 ubuntu/debian/changelog: releasing version 59ubuntu7
[18:16] <CIA-50> ubiquity: cjwatson * r2867 ubiquity/ (d-i/manifest debian/changelog):
[18:16] <CIA-50> ubiquity: Automatic update of included source packages: partman-partitioning
[18:16] <CIA-50> ubiquity: 59ubuntu7.
=== jg_ is now known as jg
[18:42] <jg> ping superm1
[18:45] <superm1> hi jg
[18:45] <jg> hi.
[18:45] <superm1> i believe you are the same jg that I just saw an email from?
[18:45] <jg> yup.
[18:46] <jg> playing with one of your fine products this afternoon.
[18:46] <jg> currently in the middle of an install of a current intrepid build.
[18:47] <CIA-50> ubiquity: cjwatson * r2862 intrepid-beta/ (8 files in 4 dirs): merge r2864-2867 from trunk
[18:47] <jg> superm1: should I expect any surprises here in a few minutes as it completes?
[18:47] <superm1> jg, well depends on if your XT has AMD graphics
[18:48] <jg> yup.
[18:48] <jg> it does.
[18:48] <superm1> jg, then just dont try to do fglrx with it.  the open driver should be pretty functional, but i saw some quirky crashy behavior a few times
[18:48] <jg> x1250, IIRC.
[18:49] <jg> ok; wasn't intending to; I'll be building my X bits from source when I get the machine stabilized anway.
[18:49] <jg> what do I do to get the wireless running?
[18:50] <jg> superm1: I tried on Fedora F10, and was defeated....
[18:51] <superm1> jg, did you get one with broadcom or with intel?
[18:51] <superm1> i'd guess broadcom based on that response
[18:52] <jg> yup.
[18:52] <jg> superm1: broadcom.
[18:52] <superm1> jg, should work out of the box with 'wl' on intrepid then
[18:52] <jg> wasn't obvious from the web site which was which....
[18:52] <jg> cool.
[18:52] <jg> I saw you did some patches around ID'ing the N-Trig.
[18:52] <jg> What's the state there?
[18:53] <jg> superm1: I note it seems to be able to imitate a wacom...
[18:54] <superm1> jg, yeah that top level usb device is id'ed, but the hid stuff is still not going to come up any nicer
[18:54] <superm1> jg, if you look at the FDI file for it imiating wacom, you'll see it as HID XXXX:YYYY or something similar
[18:54] <jg> superm1: I'm negotiating with N-Trig's president to try to get docs; keep fingers crossed....
[18:55] <superm1> jg, perhaps we should move this to a pm though or another channel this isn't exactly "installer" related
[18:55] <jg> ok.
[18:55] <jg> sorry.
[18:57] <CIA-50> ubiquity: cjwatson * r2863 intrepid-beta/debian/changelog: releasing version 1.10.2
[19:02] <CIA-50> ubiquity: cjwatson * r2868 ubiquity/debian/changelog: merge from intrepid-beta branch
=== robbiew is now known as robbiew-away
[19:18] <cr3> in busybox, is there a way to list the network interfaces considering ifconfig is not there?
[19:19] <cr3> nevermind, I think I'm supposed to use the ip command
[19:26] <persia> cjwatson: After looking at bzr history, thank you *very* much for that particular dance.  While none of it seemed critical, it's all extremely helpful.
[19:30] <cjwatson> cr3: correct
[19:30] <cjwatson> persia: no problem, hope the history was educational
[19:33] <persia> cjwatson: The ubiquity changes were byte-for-byte the same as my local copy (started from post auto-login addition).  partman-partitioning looks straightforward.  The revision pulls back and forth were rather interesting, and demonstrate power of VCS source management.
[19:42] <cjwatson> persia: byte-for-byte> heh
[19:44] <persia> cjwatson: Aside from me forgetting it, I think there's only one way to do it: add the string ":lpia" in two places, and copy one of the other ubiquity.install-${arch} packages that used grub :)
[19:45] <persia> I just need to add more steps in my fix-things process: because of the way that the installer packages get included, etc. it seems easiest to just fix live, recover patches, and apply them, but this isn't sufficient.  If we ever decide to have a special geode arch, I'm now well prepared.
=== robbiew-away is now known as robbiew
[20:58] <cr3> during the installation sequence, should the network interfaces be detected before ethdetect is called in /var/lib/dpkg/info/ethdetect.postinst?
[20:59] <persia> cr3: live session or alternate?
[21:00] <cr3> persia: alternate
[21:00] <cr3> persia: network install even, but I don't think it will matter much at that point
[21:01] <persia> cr3: Well, yes and no and maybe.  that postinst runs in the chroot, so the chroot is probably not natively network aware until that point.  The host either has network or not compeltely independently of what happens in the chroot.
[21:02] <cr3> persia: does it really run in the chroot? that /var script is in the initrd.gz cpioball
[21:02] <persia> Ah, then we're talking about two different /var/lib/dpkg/info/ethdetect.postinsts :)
[21:03] <cr3> persia: good point, there is probably another ethdetect udeb installed afterwards. out of curiosity, I'll have a quick gander
[21:04] <cr3> I just checked and e1000 gets loaded before ethdetect is called, weird
[21:05] <persia> cr3: No, the udeb install postinst is probably the right place for network discovery during the boot into the minimal system (but I'm guessing, rather than knowing that).
[21:05] <persia> I was talking about /target/var/lib/... which is compeltely different.
[21:05] <persia> In the unexpected case where networking isn't enabled in the host, it's conceivably possible that enabling it on the target may also enable it on the host.
[21:07] <cr3> persia: right, but maybe there's some other hw-detect script being called beforehand which also happens to catch maybe some network controllers such as the e1000
[21:09] <persia> cr3: Quite possibly.  Unfortunately, I don't know much about that environment: most of my experience is either with debootstrap off some cobbled-together boot (maybe an old scrap disk, or whatever), or using the LiveCD (or analogues thereto).
[21:10] <persia> (there is a gap of several years between the two when I nursed a potato -> hardy instance, and only upgraded by component, rather than replacing the system)
[21:26] <cjwatson> cr3: in practice, drivers often get loaded by udev out-of-sync with d-i
[21:27] <cjwatson> nowadays, ethdetect is basically there to finish up just in case
[21:27] <cjwatson> and cope with things that don't get loaded by udev for whatever reason
[21:28] <cjwatson> persia: no such thing as ethdetect in the target
[21:31] <cr3> cjwatson: thanks so much, so I will be temporarily modify ethdetect to workaround the e1000 problem. this is not ideal but I can't find a better solution
[21:31] <cjwatson> what workaround exactly?
[21:31] <cr3> cjwatson: brace yourself....
[21:32] <cr3> modprobe e1000; lspci -d "8086:1096" -nm | cut -d' ' -f 3,4,6,7 | tr -d '"' | head -n 1 > /sys/bus/pci/drivers/e1000/new_id
[21:32] <cjwatson> oh, right, ok
[21:32] <cjwatson> I thought you meant something to suppress e1000, in which case ethdetect wouldn't have been sufficient
[21:33] <cr3> the installation seems to be running smoothly now but I'll probably have to supplement something else for after reboot, not a problem
[23:26] <xivulon> hmm evand been testing wubi, last version shows page "who are you"
[23:26] <xivulon> is there anything new that needs preseeding?
[23:30] <cjwatson> xivulon: yeah, user-setup/encrypted-private-passphrase
[23:30] <cjwatson> probably just preseed that to false
[23:30] <cjwatson> err, sorry, I meant user-setup/encrypted-private
[23:31] <cjwatson> though actually I'm not sure why that would cause ubiquity --automatic to stop
[23:31] <cjwatson> a debug log would help
[23:31] <xivulon> there is also an autologin box I can see in the ui, is that relevant
[23:31] <xivulon> am running now without debugging mode
[23:31] <cjwatson> no, I don't think so - the underlying d-i code doesn't ask that
[23:31] <cjwatson> so it shouldn't cause the installer to halt
[23:31] <xivulon> ok re-running the installer
[23:32] <xivulon> will take 5-10 mins
=== superm1 is now known as superm1|away
[23:39] <CIA-50> cdrom-detect: cjwatson * r427 ubuntu/debian/ (4 files): merge from lp:~tormodvolden/cdrom-detect/usb-drive-install
[23:40] <CIA-50> cdrom-detect: cjwatson * r428 ubuntu/debian/changelog: fix changelog typo
[23:47] <kirkland> cjwatson: interestingly, if i set the bootable flag on the 0xfd raid partitions post installation in a running system, i do not reproduce the kvm segfault
[23:49] <xivulon> bizarre, I rerun the installer and wasn't asked anything, I wonder what could I have typed into username/password to trigger that
[23:49] <xivulon> anyway time to sleep, have a good night