[00:03] <superm1> cjwatson, something about that still doesn't click though to me.  If the installer favors setting up an extended partition with logical partitions, how do you boot to them?  If you let the DOS MBR stick, it, can't have an active extended partition..?
[00:04] <cjwatson> that only applies if the user deliberately asks for the boot loader to be put on a logical partition
[00:04] <cjwatson> by default, we put it in the MBR
[00:05] <cjwatson> and the BIOS (only some BIOSes, at that) only cares that there exists a bootable primary partition - it doesn't have to be the one you end up chaining to
[00:05] <superm1> ah well then we are going to need to wander down the path of a partition recipe instead
[00:06] <superm1> support was added in for such recipes to ubiquity this cycle, correct?
[00:06] <cjwatson> has been there since automation in general was added in gutsy
[00:06] <cjwatson> does the DOS MBR really refuse to boot from a logical partition?
[00:07] <cjwatson> can it boot from an extended partition instead? you can install GRUB there
[00:07] <superm1> yeah.  I putzed around with it for a bit this afternoon until michael_e_brown indicated that to me and it made sense
[00:07] <michael_e_brown> hey
[00:07] <cjwatson> err, I think
[00:07] <cjwatson> maybe not
[00:07]  * michael_e_brown catches up
[00:07] <cjwatson> but, yeah, if you're using a boot loader that can't deal with it, it's totally reasonable to force the partition to be primary in your recipe
[00:08] <michael_e_brown> cjwatson, we have DOS MBR, which cannot chain to a partition PBR in an extended partition
[00:08] <superm1> and with the way the factory process handles things, it will *have* to be a dos mbr.
[00:08] <michael_e_brown> cjwatson, previously, partman put / on primary sda3
[00:09] <michael_e_brown> cjwatson, but now for some reason, it is putting / (and, by extension, /boot) on logical partition
[00:09] <cjwatson> I know, I made the change
[00:09] <cjwatson> it makes much more sense for just about all other boot loader arrangements
[00:09] <michael_e_brown> cjwatson, so does automatic ubiquity now support using recipes for partman?
[00:09] <cjwatson> 00:06 <cjwatson> has been there since automation in general was added in gutsy
[00:09] <cjwatson> that didn't need anything special, it's just a standard consequence of using partman-auto
[00:10] <michael_e_brown> ok. didnt know that.
[00:11] <cjwatson> weakening the primary partition constraint on / makes certain partitioning scenarios a lot simpler
[00:11] <superm1> i'll put together a recipe then and give a run tomorrow morning with that
[00:11] <michael_e_brown> cjwatson, the problem is that /boot needs to be on a primary
[00:11] <cjwatson> the PC partition table format is very restrictive with regard to primary partitions; it caused practical problems, for instance, with standard auto-resize installs of Ubuntu on stock Dell machines
[00:12] <cjwatson> no, that is not true in general
[00:12] <cjwatson> it is true if you're chaining from DOS MBR
[00:12] <michael_e_brown> in our specific case.\
[00:12] <cjwatson> but if you're using GRUB in the MBR (the standard Ubuntu approach) it's not the case
[00:12] <michael_e_brown> understood.
[00:13] <cjwatson> in your case, overriding the standard partition recipes with a custom one is definitely reasonable
[00:13] <cjwatson> and I'll have a think about whether we can support DOS MBR in a more inline fashion
[00:13] <michael_e_brown> cjwatson, it isnt a big deal if we can do a recipe which superm1 is working on
[00:13] <cjwatson> right, should be dead easy
[00:14] <superm1> well i'll do it tonight before i head to bed at least.  dinner for now :)
[04:58] <raju> cjwatson, i am getting error while booting the live cd ( which i created based on the docs given in ubuntu )
[05:00] <raju> cjwatson, error is like "/bin/sh can't access tty ; job control turned off"
[05:01] <raju> i took the gutsy livecd of 22 kernel
[10:31] <CIA-24> ubiquity: cjwatson * r2571 ubiquity/ (debian/changelog ubiquity/components/language.py): * Run fontconfig-voodoo as root (LP: #203086).
[14:42] <CIA-24> ubiquity: evand * r2572 ubiquity/ (debian/changelog ubiquity/frontend/noninteractive.py):
[14:42] <CIA-24> ubiquity: * Properly return in debconf progress functions in the noninteractive
[14:42] <CIA-24> ubiquity:  frontend. Thanks Colin Watson.
[14:42] <CIA-24> ubiquity: * Print progress updates on a new line again in the noninteractive
[14:42] <CIA-24> ubiquity:  frontend.
[14:42] <evand> superm1: ^
[14:43] <superm1> evand, fixing packages installation? :)
[14:43] <evand> That will fix the apt not finding packages on the CD bug.
[14:43] <superm1> oh just progress
[14:43] <superm1> that's still great
[14:43] <superm1> probably resolves the 1000 percent bug
[14:44] <evand> probably not actually, I imagine that bug relates to my lack of use of some of the other progress bits.  But I will fix that, it's on my list, it's just not as high a priority as some of the other items.
[14:44] <evand> superm1: but r2572 definitely fixes installing oem-config for me.
[14:46] <superm1> very good.  we'll be able to preseed languages and such then again too
[14:47] <superm1> thanks for tracking that one down.
[14:47]  * superm1 pulls updates to see what in the devil this fix actually ended up being :)
[14:48] <evand> superm1: cjwatson is definitely the one to thank on this one.
[14:49] <superm1> thanks a bunch cjwatson :)
[14:49] <cjwatson> superm1: I suspect (and this is just zen debugging) that the reason it broke was that the incorrect implementations of progress functions caused the progress bar to be cancelled, which maps to status 30 from any of the db_progress command
[14:49] <cjwatson> s
[14:49] <cjwatson> which would probably cause things to bail out
[14:50] <superm1> interesting that without a progress bar it bails though?
[14:50] <superm1> i didn't realize it was so dependent
[14:50] <cjwatson> there's still a progress bar under the hood, even if it isn't displayed
[14:50] <cjwatson> it's calling db_progress, and the frontend is setting up the internal structures and replying appropriately
[14:50] <cjwatson> it just wasn't stubbed out in quite the right way
[14:50] <superm1> ah
[14:51] <superm1> with the beta coming up, assuming we run into no more issues with noninteractive, will you guys be building a DVD at beta time?
[14:55] <cjwatson> I'd expect so, although whether it gets tagged as beta depends on whether we manage to get testing for it
[14:58] <superm1> okay well if it goes in a day or two after beta that's fine, just so long as we can have a dvd mastered with a collection of these fixes so we can get all the testing with language packages preseeded and such in
[15:10] <cjwatson> there should be an n-daily DVD build at the very least
[18:00] <mario_limonciell> evand, preseed files get loaded on the fly when ubiquity/d-i starts, not at boot, right?  They are just "specified" from the kernel command line
[18:03] <evand> mario_limonciell: no, they get loaded as part of casper
[18:04] <mario_limonciell> evand, oh that would explain why my changes weren't looking like they took effect with each run :)
[18:04] <evand> scripts/casper-bottom/24preseed
[18:04] <evand> heh
[18:04] <mario_limonciell> can i rerun that script after the OS is started to reseed?
[18:04] <evand> I generally just cat seed | debconf-set-selections
[18:04] <mario_limonciell> okay that will do
[18:04] <mario_limonciell> thanks
[18:04] <evand> you're welcome
[18:16] <mario_limonciell> evand, out of curiosity, if you preseed an expert recipe, would it actually show up on the page where you select partitioning layouts?
[18:20] <CIA-24> ubiquity: evand * r2573 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[18:20] <CIA-24> ubiquity: * When clicking back from the advanced partitioner, go back to the first
[18:20] <CIA-24> ubiquity:  partitioning page rather than the keyboard page. Thanks Jonathan
[18:20] <CIA-24> ubiquity:  Riddell.
[18:23] <evand> mario_limonciell: no, not unless you ran ubiquity with --automatic, but then it would skip the page entirely.
[18:23] <evand> well, skip the UI portion of the page
[18:23] <evand> it still runs the d-i code
[18:24] <mario_limonciell> oh i see
[18:26] <mario_limonciell> okay curiosity number 2: if it's just running the d-i code,  would it be possible to preseed say a LVM install provided all the right debconf variables are set?
[18:27] <evand> no, because ubiquity sucks in only the d-i components it actually uses
[18:27] <evand> and partman-lvm is not among them
[18:27] <mario_limonciell> oh boo :(
[18:27] <mario_limonciell> that would have been a really neat workaround to use
[18:27] <evand> heh, sorry
[18:27] <evand> possibly Intrepid, but we'll find out for sure in May.
[18:28] <mario_limonciell> it would really only have benefited on the systems that we were going to do dm-raid on
[18:28] <mario_limonciell> since dm-raid fell through and all
[18:28] <mario_limonciell> so not a big loss
[18:28] <evand> ah, I was just going to say
[18:42] <mebrown> mario_limonciell, ping
[18:46] <mebrown> mario_limonciell, nm...
[19:03] <CIA-24> ubiquity: evand * r2574 ubiquity/bin/ubiquity: Typo
[19:07] <mario_limonciell> mebrown, hey i'm here
[20:39] <mebrown> is there a way to manually mount a partition from the cmdline but supress the automount message that pops up in gnome?
[20:39] <mebrown> eg. when I mount the Dell reinstallation partition on /dev/sda2, it pops up an autorun dialog
[20:40] <evand> mebrown: see bug 199129
[20:40] <ubotu> Launchpad bug 199129 in ubiquity "Auto-resize install fails to mount drive" [Undecided,New] https://launchpad.net/bugs/199129
[20:41] <evand> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/199129/comments/9 specifically might work
[20:41] <ubotu> Launchpad bug 199129 in ubiquity "Auto-resize install fails to mount drive" [Undecided,New]
[20:41] <evand> otherwise you can play whack-a-mole on the nautilus/gnome-vfs gconf keys like we've been doing in ubiquity
[20:42] <mebrown> hmm... thanks
[20:42] <mebrown> I'll try it.
[20:43] <mebrown> evand, not complaining, just think it is funny that this is the cmdline in my .desktop file for this:
[20:43] <mebrown> Exec=gnome-terminal --hide-menubar -x sudo sudo hal-lock --interface org.freedesktop.Hal.Device.Storage --exclusive --run /bin/bash /usr/local/bin/make-dvd.sh
[20:43] <mebrown> gnome terminal runs sudo which runs hal-lock which runs /bin/bash which runs my script
[20:43] <mebrown> that's *almost* longer than my script
[20:43] <mebrown> :)
[20:43] <evand> lol
[21:01] <mebrown> evand, doesnt appear to work for me
[21:01] <mebrown> evand, this is running on a full desktop after install
[21:01] <evand> Is that double sudo a pasting error?
[21:03] <evand> I don't think run lets you pass arguments
[21:03] <mebrown> evand, I messed that up. but it still doesnt work after fixing
[21:03] <evand> I'd get rid of the /bin/bash.
[21:05] <mebrown> ah.
[21:05] <mebrown> I get it.
[21:06] <mebrown> appears to work. thanks!
[21:06] <mebrown> putting quotes around the cmd also works
[21:06] <evand> mebrown: you're welcome
[21:06] <mebrown> doh.
[21:06] <evand> ah, good call
[21:06] <mebrown> the window popped up again
[21:06] <mebrown> just took a few more seconds
[21:06] <evand> argh
[21:07] <evand> hrm
[21:08] <mebrown> Exec=gnome-terminal --hide-menubar -x sudo hal-lock --interface org.freedesktop.Hal.Device.Storage --exclusive --run "/bin/bash /usr/local/bin/make-dvd.sh"
[21:08] <mebrown> thats what I have so far.
[21:08] <mebrown> it runs, but it obviously doesnt lock something
[21:08] <mebrown> as I get an autorun dialog
[21:10] <mebrown> Well, a partial solution: delete the autorun.inf. Problem is that I still get a nautilus browser popup.
[21:13] <evand> So the alternative solution is to unset the appropriate gconf keys and then set them back when you're done running.  These would be...
[21:14] <evand>  /desktop/gnome/volume_manager/automount_drives, /desktop/gnome/volume_manager/automount_media, /apps/nautilus/desktop/volumes_visible, /apps/nautilus/preferences/media_automount, /apps/nautilus/preferences/media_automount_open
[21:14] <evand> it's ugly and GNOME has a habit of changing these on us.
[21:14] <mebrown> hmm...
[21:14] <evand> still trying to figure out why hal-lock wont work though
[21:14] <evand> as that seems to be the most elegant solution
[21:15] <mebrown> the autorun dialog was a complete showstopper as users will invariably click the wrong thing.
[21:15] <mebrown> since I've gotten it to just a nautilus popup, that *may* be sufficient for now
[21:15] <mebrown> (esp. since nautilus goes away when the DVD create is finished)
[21:40] <xivulon> what is the status of bug #8497 ? I see it has been marked as fixed upstream
[21:40] <ubotu> Launchpad bug 8497 in grub "grub guessed BIOS disk order incorrectly" [Medium,Confirmed] https://launchpad.net/bugs/8497
[21:57] <michael_e_brown_> shouldnt grub use EDD so it doesnt have to guess?
[21:57] <TheMuso> What is everybody's thoughts on disabling the running of pulseaudio in only-ubiquity mode? Speech doesn't rely on it, so it can do without it, and I've tested code here that disables it successfully.
[21:58] <TheMuso> Pulseaudio is only run because of gnome-settings-daemon honouring gconf values.
[21:59] <michael_e_brown_> no screen reader for ubiquity?
[22:00] <TheMuso> michael_e_brown_: Not quite. What I'm saying is that the screen reader's speech output component can work with or without pulseaudio, so its pointless to run pulseaudio just for that, and most people won't be using speech anyway.
[22:00] <michael_e_brown_> ah
[22:00] <michael_e_brown_> makes sense, i suppose
[22:00] <TheMuso> So even now when you boot only-ubiquity, pulseaudio is running, whether you know it or not.
[22:03] <mario_limonciell> TheMuso, well what's the advantage of going through that effort to do it though?
[22:03] <mario_limonciell> a 1-3 meg memory savings?
[22:04] <TheMuso> mario_limonciell: Yes, I was expecting this to be raised. :)
[22:04] <mario_limonciell> it may be useful to keep in place especially if ubiquity-slideshow ever materializes.  but to that same level its easy to add back
[22:04] <michael_e_brown_> just for reference, every meg helps
[22:05] <michael_e_brown_> on my PS3 with 200MB of RAM, current state of gutsy is sad
[22:05] <mario_limonciell> michael_e_brown, well ppc already has it's fair share of "kill me processes" :)
[22:05] <TheMuso> The only other issue that needs resolving for speech to work now, is for the ubiquity-dm session to be able to refresh knowledge of groups via pam or whatever it does, so that the ubuntu user can actually talk to the audio device.
[22:53] <armand> hello y a des gens