#ubuntu-installer 2007-01-16
<tepsipakki> humm, I've merged syslinux-3.31
<tepsipakki> ..but it doesn't build on feisty, ok with dapper :I
<tepsipakki> hah, gentoo had a nossp-patch for that, so it's fine now
<cjwatson> ~ # archdetect
<cjwatson> i386/mac
<cjwatson> woot
<tepsipakki> yay
<tepsipakki> pity that my boss hates macs, so no chance to get them
<cjwatson> bugger, I'd forgotten that the BOOT_DEBUG=3 trick doesn't work if you have a USB keyboard
<cjwatson> maybe I should rejig all that at some point to happen earlier
<cjwatson> and no udevcontrol; can't think of a way to tweak the log priority by hand from sh, given that I have to talk to a UNIX-domain socket ...
<cjwatson> oh well, bed
#ubuntu-installer 2007-01-17
<mark> oh yes, I had forgotten about this channel
* Starting logfile irclogs/ubuntu-installer.log
#ubuntu-installer 2007-01-18
<CIA-4> ubiquity: cjwatson * r1812 ubiquity/ (configure configure.ac): bump to 1.3.13
<cjwatson> neat, it works
#ubuntu-installer 2007-01-19
<CIA-4> ubiquity: cjwatson * r1813 ubiquity/ (d-i/manifest debian/changelog):
<CIA-4> ubiquity: * Automatic update of included source packages: base-installer
<CIA-4> ubiquity:  1.70ubuntu2, console-setup 1.13ubuntu5, grub-installer 1.20ubuntu2,
<CIA-4> ubiquity:  partman-base 100ubuntu3, partman-efi 11ubuntu1, silo-installer
<CIA-4> ubiquity:  1.07ubuntu3.
<CIA-4> ubiquity: cjwatson * r1814 ubiquity/debian/changelog: releasing version 1.3.13
<tepsipakki> cjwatson: I have vmware workstatin 6 beta, and feisty installed on /dev/sda, not /dev/hda :)
<cjwatson> no doubt depends on the exact hardware it's emulating
<tepsipakki> heh, true.. it's emulating a scsi-drive :P
<thom> cjwatson: is there any way to tell which interface the installer is trying to dhcp?
<tepsipakki> yes
<tepsipakki> interface=eth0
<tepsipakki> or whatever
<tepsipakki> on the cmdline
<tepsipakki> or netcfg/choose_interface in preseed file
<thom> no, that's not what i asked
<cjwatson> you mean to find out, not to force, right?
<cjwatson> from what level?
<thom> well, it's running from a preseed, and i want to confirm whether the correct file was being loaded by pxelinux
<thom> i've now done so by deleting most of the pxelinux.cfg so it tells me
<thom> but yeah, having it say in syslog might be nice
<cjwatson> it's on the dhclient command line, if you're at the console at the time
<cjwatson>             execlp("dhclient", "dhclient", "-e", interface, NULL);
<cjwatson> thom: should also be in /var/log/installer/cdebconf/questions.dat post-reboot, netcfg/choose_interface
<cjwatson> thom: or, heck, just look in /etc/network/interfaces
<cjwatson> the one after auto is the one it's using
<thom> yeah, it was bombing out immediately with unknown interface, so i couldn't get it in ps
<cjwatson> try debconf-get netcfg/choose_interface then
<cjwatson> (after netcfg exits)
#ubuntu-installer 2007-01-20
<xivulon> hi all
<evand> hi
<xivulon> I have a question
<evand> xivulon: Just ask, but stick around as, depending on your question, it could take a while to answer, if anyone can answer it.
<xivulon> I have created a custom initrd that contains preseed and loopmounts the isofile, but d-i insists in looking for the cdrom/hd
<xivulon> Is there any parameter (preseed or kernel) to point d-i to use the files within the mounted iso? Preseed is under / and already loaded in the startup phase.
<xivulon> Hi all
#ubuntu-installer 2007-01-21
<tepsipakki> hrm, installed feisty on a partition which is the last 10GB of a 300GB disk.. and it won't boot
<tepsipakki> wonrder if there is a limit for grub
<tepsipakki> -r
<evand> cjwatson: Do you know of any way around the problem that partman-commit is seemingly needed to get the fifos in /var/lib/partman back when the old advanced partitioner is used, other than making that the program used in my prepare function?
<CIA-4> ubiquity: cjwatson * r1815 ubiquity/ (d-i/lists/i386 debian/changelog): * Use partman-efi on i386.
#ubuntu-installer 2008-01-14
<stelt> on "create new empty partition table on this device" it also says "Note that you will be able to undo this operation later if you wish." Shouldn't that be "... wil NOT ..." ?
<evand> No, because the partition table changes are not committed until you press the Install button.
<stelt> evand, that's not an "Undo", but a "Cancel" then. The current text obviously gives misinterpretation to some people
<evand> actually, both are true.  You can undo the changes you make to the partition table on that same page, and you can cancel the install before you press the Install button.
<stelt> agreed. But that doesn't remove the significant room for misinterpretation
<evand> stelt: Can you file a bug report on this and assign it to me?
<evand> or just paste the bug number in here and I'll triage it myself
<stelt> "When the 'install' is finally committed ... " might be a basis for a better text
<stelt> i'll see if i can report and post the bug nr here
<evand> thanks
<stelt> https://bugs.launchpad.net/ubuntu-express/+bug/182733
<ubotu> Launchpad bug 182733 in ubuntu-express "ambiguous wording in "prepare partitions"" [Undecided,New]
<evand> thanks
<evand> oh
<stelt> oh?
<evand> For future reference when filing bugs, you want to set the project to Ubuntu and the file against the ubiquity source package.
<evand> We handle the installer bugs on their source packages, and ubuntu-express was renamed to ubiquity a while back.
<evand> But no worries, I'll fix it for this one.  Thanks again for filing this.
<stelt> when i tried to manually make a partition at liveCDs' "install" and picked "dont_use" the whole installer crashed and so did the error report thing :-(
<stelt> a URL giving a detailed list of differences between the live CD and the alternate CD please
<CIA-8> ubiquity: superm1 * r2408 ubiquity/ (10 files in 5 dirs): adjust to use mythbuntu-common
<CIA-8> ubiquity: superm1 * r2409 ubiquity/scripts/mythbuntu/mythbuntu_install.py: its not urgent to raise InstallStepErrors if there is something wrong with lirc. Let the install finish
<Le_Vert> evand: I just tried your patch for ubiquity/partman/preseed
<Le_Vert> it works when choosing guided partitionning on the whole disk
<Le_Vert> but crash when using manual partitionning :)
<evand> yikes, I'll have to fix that then.
<xivulon> evand anything I can help with on my side?
<xivulon> re #177868 can you please also extend that to mkswap?
<evand> will do
<xivulon> thanks
<twb> cjwatson: say, did the netboot syntax for casper change in hardy?
<twb> I'm trying to netboot an alpha image, and it seems to think I supplied an nfs rootserver but not a rootpath.
<twb> ...with APPEND boot=casper initrd=ubuntu-live/ubuntu-7.10-desktop-i386/casper/initrd.gz rw netboot=nfs nfsroot=192.168.67.1:/srv/netboot/ubuntu-live/ubuntu-7.10-desktop-i386 quiet splash
<twb> Oops, that's still gutsy.  So I've done something wrong, because gutsy used to work.
<cjwatson> hmm, not that I know of; the list of changes is really small
<cjwatson> surely NFSROOT= though
<twb> You mean uppercase?
<cjwatson> I don't know why nfsroot= worked in gutsy ;-)
<cjwatson> yeah
<twb> Hmm, I've never done it upper case before
<twb> If it doesn't understand nfsroot (lowercase), then it's probably getting roothost from DHCP; which would explain why it gets that but not rootpath.
<cjwatson> ah, that could be it
<cjwatson> nfsroot works in Debian and is what is documented, but there was a screwy merge at some point and our casper is missing some of the option parsing :(
<cjwatson> somebody needs to bring it back into sync
<twb> You mean Debian's casper, or live-initramfs?
<cjwatson> Debian's casper before the name change; I assume live-initramfs too
<evand> xivulon: is there any particular reason you used "$(basename /host$path)" = "swap.disk" instead of checking the fs argument?  If there isn't, I'll make that change to your patch as swap.disk is wubi-specific.
<evand> in autopartition-loop, that is.
<twb> cjwatson: using NFSROOT didn't help
<twb> Maybe I need to do `exportfs -va' to update it, even though it's a subtree.
<cjwatson> I have a feeling you're beyond me already
<twb> Yeah
<twb> It's rtfs time
<xivulon> evand no reason
<xivulon> it's only important to make sure that when we need to generate swap files, they are contiguous and fully zeroed
<xivulon> the code simply identifies a swap file and as you pointed out using fs is a better choice
<evand> indeed, ok
<choudesh> hello
<choudesh> I need a bit of help here. I am customizing the liveCD, trying to add the dist/pool folders. It seems when I add these folders, sqaushfs just hangs on boot up
<choudesh> cjwatson, you around?
<cjwatson> there's no need to /msg me
<cjwatson> it's my evening, and nagging me will make me grouchy
<cjwatson> 12 minutes response time is pretty good at nearly 9pm ;)
<choudesh> heh
<cjwatson> I've seen your mail, but have not yet had a chance to work out what might be wrong
<cjwatson> however it would help if you could provide log messages
<choudesh> didn't want to flood the channel with my issues
<choudesh> hmm, how would I produce the log?
<cjwatson> transcribing the last few things you see would be fine
<cjwatson> I assume you're ascribing the issue to squashfs due to some log messages you're seeing
<choudesh> well, it never gets past the sqaushfs so I am pretty sure that is it.
<cjwatson> "gets past the squashfs"?
<choudesh> It is not using lzma, so it isn't a decompression issue
<cjwatson> at what stage in the boot process does it hang?
<cjwatson> boot without quiet or splash on the kernel command line to get more detail
<choudesh> during boot, after initramfs, about kernel init, and right before it goes to decompress the squashfs. I see the squashfs markers, but it never gets past that
<choudesh> I have - with both verbose and debug
<cjwatson> at that point you should be able to tell us the last few things on the screen
<choudesh> ok - I will get you a detailed log of what happens. If you don't mind I will email it to you.
<cjwatson> are you sure you don't mean the initrd?
<cjwatson> because there's no point in the boot process that can be described as "decompressing the squashfs"
<cjwatson> the squashfs is *mounted*, and bits of it are decompressed as needed
<cjwatson> it's not all decompressed into memory in one go or anything
<cjwatson> e-mail's fine
<xivulon> http://diozaka.org/octod/
<xivulon> ops sorry
<xivulon> evand please note I pushed rev 41 in partman-auto-loop/lupin-support
#ubuntu-installer 2008-01-15
<evand> ok thanks
<CIA-8> ubiquity: superm1 * r2410 ubiquity/scripts/mythbuntu/mythbuntu_install.py: add support for modular lircrc generation
<tjaalton> cjwatson: I'm merging xkeyboard-config, and I think it's no longer necessary to ship the symlinks in /etc/X11/xkb, do you agree?
<tjaalton> x11-xkb-utils (former xkbutils) doesn't ship symlinks there anymore, and the tools use the new path
<cjwatson> please keep them to simplify upgrades from dapper until after hardy
<tjaalton> ok
<mathiaz> Hi :) - what's the option in the preseed file to enable an sshd server during instllation in hardy ?
<mathiaz> and also remote syslogging
<evand> I imagine it's something like d-i preseed/early_command string anna-install openssh-client-udeb
<evand> but I'm not sure if that's exactly correct
<mathiaz> evand: openssh-client ? or openssh-server ?
<cjwatson> no, I think you're looking for network-console
<cjwatson> see the installation guide, under "Using the Ubuntu Installer" / "Using Individual Components" / "Miscellaneous"
<cjwatson> oh, and to use it by default, setting anna/choose_modules to network-console should do it
<mathiaz> cjwatson: is the installation guide for gutsy on help.u.c ?
<cjwatson> remote syslogging is missing at present; Matt Proud at Google was working on it, and I have some back mail on the subject to review
<cjwatson> mathiaz: no, but IIRC feisty's will do; otherwise install the installation-guide-i386 package and you can have it locally
<mathiaz> cjwatson: ah... thanks.
<evand> ah, I misread.  Sorry about that.
<mathiaz> hum... network-console is used to manually install over ssh.
<cjwatson> yes, is that not what you asked for?
<mathiaz> What I'd like to do is to use preseed to automate the installation
<mathiaz> and if something goes wrong, I'd like to be able to ssh into the box to debug it
<cjwatson> hmm, that's not really available
<cjwatson> short of network-console
<cjwatson> you can install openssh-server-udeb in the same way as network-console above, but it won't be configured, so you'll need to set up a configuration file in a preseed file
<mathiaz> hum... I have access to the boxes via a remote serial console server
<mathiaz> but I haven't figured out how to switch to another console over the remote serial console
<mathiaz> so when something goes wrong, I just see the installation interface.
<mathiaz> IIRC I can use ALT-F2 to switch to another console during installation and debug stuff.
<mathiaz> Is there an alternate way to open a second console during installation time ?
<cjwatson> back up to the main menu and select "execute a shell"
<mathiaz> cjwatson: ah.. that should work for me then - thanks :)
<CIA-8> casper: cjwatson * r458 casper/ (debian/changelog scripts/casper-bottom/36disable_trackerd):
<CIA-8> casper: * Disable tracker-applet as well as trackerd, otherwise the former starts
<CIA-8> casper:  the latter.
<CIA-8> casper: cjwatson * r459 casper/ (bin/casper-snapshot debian/changelog):
<CIA-8> casper: * casper-snapshot: Fix argument parsing (thanks, Tormod Volden;
<CIA-8> casper:  LP: #179411).
<CIA-8> casper: cjwatson * r460 casper/debian/changelog: releasing version 1.114
<danp> hi
<danp> i'm trying to create a preseed setup where i use an early_command script to set networking parameters
<danp> but it doesn't seem to be working. in my script, i source confmodule and use db_set for the relevant netcfg/* things. i've tried messing with it quite a bit and the installer still tries DHCP
<danp> my preseed file and early script are at: http://glueless.net/preseed/
<CIA-8> partman-auto-loop: evand * r38 partman-auto-loop.ubuntu/ (3 files in 2 dirs):
<CIA-8> partman-auto-loop: * Allow disk images to be created externally (LP: #176019).
<CIA-8> partman-auto-loop: * Added template required by autopartition-loop.
<evand> I'm not sure I did that merge properly.  I merged with lupin-support, but removed some of the changes with the intention of reviewing them with xivulon when he's around.
<cjwatson> danp: are you using network preseeding?
<cjwatson> danp: if so, the early_command (and indeed the entire preseed file) is processed after netcfg ...
<danp> no, i'm using hd-media
<danp> my script is definitely run before the DHCP stuff comes up on the console (because if it errors out it stops the process before that)
<danp> i was cancelling the DHCP attempt and then using one of the consoles to see if my things got set
<danp> it seemed hit and miss. am i missing something?
<cjwatson> ok, obviously a bit more complicated; I'd like to help you now but I have to go to bed or my wife is going to get irritated :)
<cjwatson> could you post the syslog from the running installer somewhere as well?
<cjwatson> and ideally either send e-mail to ubuntu-installer@lists.ubuntu.com, or stay on this channel, so that I can get back to you
<cjwatson> you can extract the syslog using the "Save debug logs" entry on the installer's main menu
#ubuntu-installer 2008-01-16
<danp> sure, i can do that tomorrow. thanks for thinking about it :)
<danp> unless my early script errored, though, i didn't see anything in syslog from it
<stelt> At what site can i see changes in the installer ?   And how can i profit from them? As i'm working with the liveCD, cause the installer crashes on partition stuff
<exodos> hi, the version of gutsy kernel was upgraded to 2.6.22-14.47, but Packages file in gutsy/main/debian-installer/binary-i386/ is not aware of this change
<exodos> can anybody take care of this?
<exodos> gutsy/main/installer-{arch}/current/images/ should be also updated I think
<cjwatson> no, that's not correct
<cjwatson> gutsy wasn't changed - a new version was uploaded to gutsy-security and gutsy-updates
<cjwatson> it would be wrong to change dists/gutsy/
<cjwatson> I think we would only worry about uploading a new set of installer images if the changes involved a remote security vulnerability that could be exploited during installation
<exodos> but is it possible to include 2.6.22-14.47 in gutsy/main/debian-installer/binary-i386/Packages at least
<exodos> as current one makes ubuntu mirrors based on Packages files (like apt-mirror) unworkable with installer
<cjwatson> no, I'm afraid it isn't
<cjwatson> dists/gutsy is absolutely fixed and unchangeable
<cjwatson> I've heard some reports of bugs like this, and I think it may be down to a bug in the mirroring tools; can you reproduce the problem with the master archive?
<cjwatson> if a mirroring tool produces a result that doesn't work but the master archive does work, then it is undeniably a bug in the mirroring tool
<exodos> ok, i will check this
<exodos> is gutsy-security or gutsy-updates included in installer sources.list?
<exodos> because 2.6.22-14.47 is trying to be installed now
<cjwatson> the installer does use gutsy-security and gutsy-updates
<cjwatson> if that isn't part of your mirror, then you need to add it
<exodos> ok, I think that should solve it
<exodos> adding main/debian-installer from gutsy-secutiry and gutsy-updates to mirror fixed my problem
<exodos> thanks cjwatson
<cjwatson> good
<danp> cjwatson: i put my syslog up at http://glueless.net/preseed/
<danp> DHCP shows up a couple times near the end since i was trying to get the logs accesible
<danp> after i let DHCP finish it did complain about the hostname string i have set in my early script
<danp> but it still did DHCP
<twb> Now my x login looks beautiful - completely black except for "Login:" and then "Password:"
<xivulon> evand, any progress with the patches?
<cjwatson> danp: the problem is that netcfg isn't installed when that preseed file is handled, so all your db_set calls fail because the questions don't exist. I'd recommend instead either just putting all that stuff into the preseed file, or (if it needs to be conditional) piping stuff to debconf-set-selections which will deal with creating the question structures for you.
<twb> Oops, wrong channel.
<evand> xivulon: I merged some of your partman-auto-loop changes yesterday, I'm looking over bug 151579 right now, actually
<ubotu> Launchpad bug 151579 in wubi "umountfs must check whether a mountpoint contains a loopmounted root file" [High,Fix committed] https://launchpad.net/bugs/151579
<evand> xivulon: why is the /host/boot situation needed?  It seems like quite the special case that boot would be a subfolder of the host filesystem.
<evand> also, why is the full path needed for sendsigs.omit'ing ntfs-3g and ntfs?  Is there another process with the same name running at the same time as ntfs-3g?
<cjwatson> the full path isn't needed, I took that out, didn't I?
<evand> I'm assuming it isn't, I left that part of the merge out.
<xivulon> evand don't see /host/boot in the patch for 15179, what are you referring to?
<evand> xivulon: sorry, that was poor transitioning.  I'm asking you about other bug reports.
<xivulon> ah
<xivulon> can you remind me which one?
<evand> Specifically, 173659 and...
<evand> I don't see a bug report for the latter, but it's your usage of the full path for sendsigs.omit in your partman-auto-loop.lupin-support branch.
<xivulon> http://codebrowse.launchpad.net/~ago/partman-auto-loop/lupin-support/annotate/ago%40nbago-20080114235447-9rmsbro57lb2zsru?file_id=hostboot-20071221000351-3qf78yoaep16wys3-2
<xivulon> that's the new code for fstab.d
<evand> indeed, I don't see why the use case for that is necessary.
<evand> and I'm asking you to explain why you need /boot to be a subfolder of the host filesystem.
<xivulon> because in loopinstallations boot has to be an ntfs folder
<xivulon> so it can be accessed by grub4dos
<evand> ah, argh.
<xivulon> it cannot be inside the loopfile
<xivulon> so we need to bindmount in fstab
<evand> fair enough :/
<evand> so regarding your partman-auto-loop.lupin-support branch, is there any reason why you're specifying the full path or is that just leftover from an earlier version?
<xivulon> you mean for sendsigs?  no reason on top of my head
<evand> ok, I left that out when I merged as its not necessary, I just wanted to check with you to make sure there wasn't some reasoning that I was missing.
<evand> thanks for clearing those up
<xivulon> re 15179 by the way use the patch mentioned in the last-1 post
<xivulon> it is more generic and should be closer to what cjwatson suggested
<evand> indeed, that's what I was working with
<xivulon> in fact it's not a patch, well insertion points should be clear
<xivulon> echo $skip_devices | grep -qs $DEV"$" && continue
<xivulon> that goes inside the loop at the top, the rest goes before the loop
<xivulon> it basically skips all mountpoints that appear in /proc/mounts before /
<xivulon> cjwatson I assume that is what you suggested
<cjwatson> IIRC yes
<xivulon> evand note that 173659 involves 2 files in partman-auto-loop/lupin-support: mount.d/70bind and fstab.d/hostboot
<evand> indeed
<xivulon> in mount.d you might want to also check type: [ "$type" == none ] || exit 1
<xivulon> mount.d/70bind and it is [ "$type" = none ] || exit 1
<danp> cjwatson: so i can send those same answers to debconf-set-selections in my early script and it should work?
<cjwatson> danp: yeah
<danp> awesome, thank you. i'll give that a shot
<danp> it's been driving me bonkers :P
<cjwatson> you might also find it illuminating to cat /bin/debconf-set-selections in the installer; ignoring the rather verbose parsing code, you can see how it uses debconf
<danp> it's looking like something like 'netcfg netcfg/disable_dhcp boolean false' would do it
<xivulon> evand have added a comment to Bug #151579
<ubotu> Launchpad bug 151579 in wubi "umountfs must check whether a mountpoint contains a loopmounted root file" [High,Fix committed] https://launchpad.net/bugs/151579
<cjwatson> danp: d-i rather than netcfg at the start of the line (for arcane reasons) but yes
<cjwatson> danp: err, and you want true not false?
<evand> ok
<xivulon> it contains the patch for umountroot, so that any filesystem still  standing gets remounted r/o (as opposed to doing that only for /)
<danp> cjwatson: oh, right. i was looking at the output of d-g-s on another machine
<cjwatson> so 'd-i netcfg/disable_dhcp boolean true' to clarify
<xivulon> I did not test that last patch
<danp> cool
<danp> would that also work for things that are available when the preseed file is loaded? like if i wanted to just generate one big input to d-s-s
<danp> or do i have to use db_set for those things
<cjwatson> debconf-set-selections is what's used for the preseed file itself; you can use it for anything
<xivulon> evand for autopartition-loop note that I submitted a change 2 days ago', http://codebrowse.launchpad.net/~ago/partman-auto-loop/lupin-support/revision/41
<cjwatson> it is a superset of db_set
<cjwatson> I would put anything unconditional into the main preseed file, but that's just me
<danp> right
<xivulon> the issue was that when I called requires_disk_space, I checked for the existance of loopfiles in /host, but /host was not avalaible at that stage, so had to shuffle things around
<evand> xivulon: I already merged those changes.
<xivulon> good
<evand> cjwatson: any thoughts on how I should proceed with bug 183426 (basically, partman runs ridiculously slow for calc)?  Looking over the logs, nothing jumps out, and I'd hate to make him run through another install to get an strace or set -x on whatever part of partman is hanging.
<ubotu> Launchpad bug 183426 in ubiquity "[hardy] alpha-3: i386 desktop cd - partition gui hangs" [Undecided,New] https://launchpad.net/bugs/183426
<danp> cjwatson: success! thank you very much
<danp> my simple static test worked, now i can move back to the boot param-based stuff i was doing
<danp> is there a way to mix information from DHCP and static configuration? say, if i wanted to provide a hostname and IP but have everything else (netmask, gateway, domain, etc.) provided by DHCP
<danp> but in the end i want a static interfaces file
<evand> xivulon: What was the reasoning that Szabolcs gave for formatting the file rather than the loop device?
<xivulon> He said that it was safer to format the file directly without loopdev intermediaries, I never really digged any further simply changed the code
<xivulon> The patch by the way also add some safety net, if the host device get formatted instead of the loop file people are not going to be too happy
<evand> hrm, I'll have to follow up with him on that as I got an inquiry as to why it was necessary.  Is email the best way to reach him, or is he on IRC as well?
<xivulon> I usually email him
<evand> ok, thanks
<xivulon> szaka@ntfs-3g.org
<xivulon> once you are there you may ask if there are any relevant upgrades to ntfs-3g which are worth considering for inclusion (to which of course he'll reply yes)
<xivulon> I'd be particularly interested in fallocate and fschk and safety of write operations on non-zeroed/non-contiguous loop-files
<evand> I thought fallocate wasn't in the mainline kernel yet?
<evand> something about and endless bikeshed over arguments to it
<evand> an*
<xivulon> did not follow that, never mind than
<xivulon> IIRC the suggestion came when I was asking about possible solutions re system freezes users reported during I/O operations. It was one of the things he asked me to change, it did not fix the issue (turned out to be a 2.6.22 kernel problem) but I left the code there anyway since my understanding was that it was safer anyway
<xivulon> and did not seem to have any negatives
<evand> Can I get another pair of eyes on this, does this look reasonably correct? cjwatson? http://pastebin.ubuntu.com/3610/
<evand> xivulon: your patch failed in the case of there being nothing before / as NR is the number of lines processed which ends up being all of them
<cjwatson> evand: hmm, the second field of /proc/mounts isn't necessarily unique so I'm unsure about that
<evand> xivulon: actually, that assertion is wrong, but it still fails
<evand> ah, hrm
<xivulon> hmm it works for me
<xivulon> your version though returns only /
<evand> xivulon: it fails if the second field is not unique, which as cjwatson points out, so does mine
<xivulon> awk '$1!~"^rootfs" && $2=="/" {print NR}' /proc/mounts
<cjwatson> evand: instead of reading from /proc/mounts as it does, why not arrange to read from the output of sed -n '/^rootfs/,$p' /proc/mounts ?
<cjwatson> you don't need to mess around with line numbers :)
<cjwatson> just "print from ^rootfs to end of file" is what you want
<cjwatson> anyway, got to go, see you tomorrow
<evand> ah, good call, thanks!
<xivulon> you mean in the above you have more than 2 mntpoints as / ?
<evand> enjoy your evening, goodbye
<evand> xivulon: yes
<xivulon> one being rootfs
<xivulon> can we have a list of devices that are not "real" devices?
<xivulon> disk devices I mean
<evand> xivulon: for example, I have:
<evand> rootfs / rootfs rw 0 0
<evand> /dev/disk/by-uuid/0666f72f-99e1-4948-b718-220f48093423 / ext3 rw,errors=remount-ro,data=ordered 0 0
<xivulon> rootfs should be skipped
<evand> your command returns 6, the position of the latter
<xivulon> which is correct
<xivulon> should return the position of the "real" root-device
<evand> ah, my mistake
<cjwatson> xivulon: you don't need to have a list of devices. you just need to trim everything above ^rootfs out of /proc/mounts before unmounting stuff. no complexity beyond that is required.
<xivulon> I trimmed everything about "real" /
<xivulon> as opposed to rootfs
<xivulon> I trimmed everything ABOVE "real" root device
<xivulon> i.e. in the case of evand everything above and including /dev/disk/by-uuid/0666f72f-99e1-4948-b718-220f48093423 is NOT unmounted
<xivulon> I think that is correct
<cjwatson> there's no need to explicitly skip rootfs because the code inside the loop already does that
<cjwatson>                 case "$MTPT" in
<cjwatson>                   /|/proc|/dev|/.dev|/dev/pts|/dev/shm|/proc/*|/sys|/var/run|/var/lock)
<cjwatson>                         continue
<xivulon> hmm
<cjwatson> anyway, really gone
<xivulon> the root_line looks for the line number of the real root
<xivulon> hence it has to ignore rootfs
<xivulon> that is the point to trim from
<xivulon> whatever is above that point is not unmounted, if rootfs happens to be above it will be skept
<xivulon> in fact I think it was your suggestion to ignore rootfs and focusing on / when determining what chunk of /proc/mounts to skip
<xivulon> evand any q on the code? I think it is correct
<xivulon> cjwatson re list of devices, that is just another way of splitting /proc/mounts in 2, the list contains the devices of the first chunk of /proc/mounts (containg everything up to and including root) that have to be skept
<xivulon> looping through the remaing chunk of /proc/mounts would yield same results
<xivulon> http://paste.ubuntu-nl.org/52193/ for instance does the same thing of the patch submitted
<evand> xivulon: I don't see anything particularly wrong with it aside from it no longer being explicit in what mount points its skipping, but I want to wait for cjwatson to look it over before I commit it as this is a pretty important package we're messing with.
<xivulon> This is safer: http://paste.ubuntu-nl.org/52195/
<xivulon> in case someone has 0 or 3+ root lines in /proc/mounts (for reasons I ignore)
<xivulon> we can move to the grub patches then =)
<evand> heh ok
<xivulon> have to go now will be back in 1/2 hour or so
<evand> ok
<xivulon> evand in autopartition-loop>setup_loop I would keep [ "$1" != 0 ] || return
<xivulon> it avoids having a recipe with 0 sized /home
<xivulon> for instance
<evand> ah, then this also needs to be changed:
<evand>         if [ ! -f "/host$path" ] && [ $1 -gt 0 ]; then
<evand> as we've already established by that point that the size is not 0.
<evand> ok, fair enough
<xivulon> the one at the top catches both pre-existing images and images to be created
<xivulon> the one in the if sentence works only for new images
<evand> right, I'm saying that the if statement can be shorted to just the file test
<evand> as the size check is redundant
<CIA-22> grub-installer: evand * r721 grub-installer.ubuntu/ (debian/changelog grub-installer): * Handle cases where /boot is bindmounted (LP: #181658).
<xivulon> if the size check is on top sure
<evand> indeed
<CIA-22> partman-auto-loop: evand * r39 partman-auto-loop.ubuntu/autopartition-loop: Fix size test in setup_loop.
<Thugacation> hey can someone help me with a problem
<evand> please don't ask to ask a question, just ask it.
<Thugacation> ok but it's stupid
<Thugacation> when i try to start wubi-cdboot.exe it gives me error message "Could not find any appropriate CD"
<evand> xivulon: ^
<Thugacation> why does xivulon know all about the installer
<xivulon> Thugacation, the CD has to be in the tray
<evand> Thugacation: xivulon is the author of Wubi.
<cjwatson> xivulon is one of the wubi team
<Thugacation> why can't i just boot the installer from windows
<cjwatson> wubi *is* booting the installer from Windows
<xivulon> wubi-cdboot is designed to assist those people that cannot boot from CD
<xivulon> it basically boots from HD and then continues off the CD
<xivulon> without editing the bios
<cjwatson> if you prefer to boot it natively and are prepared to repartition, you can certainly also do that; set your BIOS to boot from CD and reboot
<cjwatson> that is indeed the standard way to start Ubuntu
<xivulon> wubi.exe (downloaded from the website) works off the HD solely
<Thugacation> so i can install it without having to burn any CD's
<Thugacation> because i dont have cd's
<cjwatson> for that, you need wubi proper, not wubi-cdboot
<xivulon> that cjwatson reminds of bug #181734
<ubotu> Launchpad bug 181734 in casper "Prompt the user to insert a CD if a live media is not detected" [Undecided,New] https://launchpad.net/bugs/181734
<cjwatson> as xivulon says, you can download it from wubi-installer.org
<Thugacation> ok thanks for your helps
<xivulon> np
<Thugacation> so if i have 2 hard drives... a 200gb for windows and a 80gb for ubuntu... i can install linux to the 80gb via wubi-installer right
<xivulon> yes
<Thugacation> yes i see the screenshots thank u
<xivulon> well in fact wubi is for installing ubuntu inside of windows
<xivulon> without changing the partitions
<xivulon> but
<xivulon> it you already have a partition allocated exclusively for ubuntu then a proper installation is better
<Thugacation> a proper installation with a CD huh
<Thugacation> damn guess i shall go buy some
<xivulon> you can use unetbootin (a spinoff of wubi that allows to install via netboot to dedicated partition)
<xivulon> I might add netboot to wubi but so far it's not planned
<xivulon> netinstall I mean
#ubuntu-installer 2008-01-17
<ago> evand any other bug you want to go through tonight?
<tjaalton> could I request a new d-i against -4 kernel?
<cjwatson> tjaalton: sure, on its way
<CIA-22> debian-installer: cjwatson * r869 ubuntu/ (10 files in 4 dirs): * Move to 2.6.24-4 kernels.
<tjaalton> cjwatson: thanks!
<CIA-22> debian-installer: cjwatson * r870 ubuntu/debian/changelog: releasing version 20070308ubuntu26
<xivulon> hi evand
<xivulon> any q over remaining patches?
<evand> xivulon: I'll let you know, but none currently.
<xivulon> what's the status of bug #173659 and bug #151579?
<ubotu> Launchpad bug 173659 in wubi "Add /host/boot to fstab" [Medium,Fix committed] https://launchpad.net/bugs/173659
<ubotu> Launchpad bug 151579 in wubi "umountfs must check whether a mountpoint contains a loopmounted root file" [High,Fix committed] https://launchpad.net/bugs/151579
<evand> I'll take care of the former next.  As for the latter, cjwatson, does http://paste.ubuntu-nl.org/52195/ look ok to you or would you prefer the solution you had originally suggested?
<xivulon> evand can you also look into bug #177868? Without the new hooks is very difficult for me to do releases (have to support 2 hooks)
<ubotu> Launchpad bug 177868 in wubi "When loopfiles are used mkfs has to target the file and not the containing device" [Low,Fix committed] https://launchpad.net/bugs/177868
<evand> Are you sure that's the right bug?
<xivulon> That mostly involves merging https://code.launchpad.net/~ubuntu-installer/lupin/hardy
<xivulon> ehm nope
<evand> heh
<xivulon> I meant bug #144798
<ubotu> Launchpad bug 144798 in casper "Merge lupin functionality + add external hooks" [Wishlist,Confirmed] https://launchpad.net/bugs/144798
<cjwatson> evand: it looks horrendously complicated and much harder than my suggestion, but it's your call
<xivulon> copied the wrong line
<evand> ok, I'll take some more time to look at that then.
<xivulon> cjwatson what was your proposal on that?
<xivulon> I can recode if you give some guidance
<cjwatson> some derivative of: sed -n '/^rootfs/,$p' /proc/mounts
<cjwatson> messing about with line numbers is almost always an overcomplex option in Unix
<xivulon> cjwatson one thing is not clear to me
<xivulon> do we want to skip all mountpoints above root, or all mountpoints above rootfs?
<xivulon> My understanding was the first case
<cjwatson> oh, hmm, yeah, should be root. adjust the regexp accordingly
<cjwatson> /^\/[^ ]* \//
<cjwatson> /^\/[^ ]* \//
<cjwatson> /^\/[^ ]* \/ /
<cjwatson> my point is just to avoid having to read through the file multiple times, work out line numbers, use lots of commands - an elegance thing :)
<xivulon> Heh I am not a bash esthetist, getting things to work is good enough for me :P
<xivulon> sh
<cjwatson> I think it's sort of important in the shutdown procedure to call as few external commands as possible, for efficiency
<xivulon> I agree
<xivulon> now I get the regex
<xivulon> I like it
<xivulon> yep much better http://paste.ubuntu-nl.org/52272/
<xivulon> evand ^
<cjwatson> looks good
<xivulon> cjwatson, what is the sed command to print the top half of the file as opposed to the bottom half?
<xivulon> needed in umountroot
<xivulon> in fact not needed
<cjwatson> 0,/regex/
<xivulon> ah was trying $p,/regex/
<xivulon> was close
<cjwatson> well, sed -n '0,/regex/p' to be a little more verbose
<cjwatson> alternatively sed '/regex/q' tells sed to quit as soon as it encounters /regex/ (before printing that line)
<cjwatson> you can do similar things in awk too of course, sed just fits my brain better
<xivulon> cjwatson, evand in bug #151579 last comment is also a patch for umounroot, can you please review that too?
<ubotu> Launchpad bug 151579 in wubi "umountfs must check whether a mountpoint contains a loopmounted root file" [High,Fix committed] https://launchpad.net/bugs/151579
<evand> will do
<xivulon> I have added colin suggestion as a comment, so the other one to check is now comment n-1 https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/151579/comments/5
<ubotu> Launchpad bug 151579 in wubi "umountfs must check whether a mountpoint contains a loopmounted root file" [High,Fix committed]
<xivulon> evand re lupin/#144798 https://code.launchpad.net/~ubuntu-installer/lupin/hardy, I am only intrested in the casper package, you can skip lupin-helpers alltogether
<evand> noted
<xivulon> lupin/casper by the way might become a separate package, called maybe custom-installation
<xivulon> with 2 packages, 1 for casper and 1 for the alternate initrd
<xivulon> that basically now provides external hooks to modify the installation using files on local hard disks
<xivulon> what's your view on that?
<evand> hrm, no complaints.  But I'm more concerned with getting this done as we have it set up at the moment.
<xivulon> re casper, you can simply merge the old lupin/casper with the new one
<xivulon> suggestion only moves lupin/hardy/casper to a different launchpad project, + adds code for the alternate initrd to provide equivalent hooks
<evand> cjwatson, xivulon: May I ask that you both just eye this over one last time before I send it to the buildds? http://pastebin.ubuntu.com/3623/
<xivulon> looks good to me
<xivulon> thanks a lot
<cjwatson> evand: hmm, <(...) is a bashism
<cjwatson> that's a /bin/sh script so it'll break
<cjwatson> maybe use a temporary file if that's possible at that stage?
<evand> hrm
<evand> so:
<evand>         sed -n '/^\/[^ ]* \/ /,$p' /proc/mounts > tempmounts
<evand>         exec 9<&0 < tempmounts
<cjwatson> well, put it in a known-safe temporary directory (*not* /tmp; /var/run maybe?)
<evand> ok, indeed I wasn't sure where to put it and was just going to ask
<xivulon> skip_mountpoints=$(sed -n '0,/^\/[^ ]* \/ /p' /proc/mounts)
<xivulon> maybe
<xivulon> http://paste.ubuntu-nl.org/52281/
<xivulon> evand, cjwatson ^
<xivulon> the above those not use a file and I believe is also safer code
<xivulon> if for instance a mountpoint appears below root using the same device of a mountpoint above root will also be skept
<xivulon> which is the correct behaviour IMHO
<cjwatson> err ... no, it's still important to umount such a device even if it happens to be mounted multiple times
<xivulon> This is required when you have mountbinds for instance,
<cjwatson> quite the opposite
<xivulon> don't agree
<cjwatson> you need to unmount the bind mount
<cjwatson> you don't need to unmount the thing it's a bind-mount of
<xivulon> true
<cjwatson> therefore it is not correct to fail to unmount something just because the same device appears before root
<xivulon> remembered wrongly that it would umount the device
<xivulon> but it does umount -f -r -d $REG_MTPTS
<cjwatson> yes, that's fine
<xivulon> yep
<cjwatson> you can't umount a device, anyway
<cjwatson> the umount system call takes a mountpoint
<xivulon>  umount [-dflnrv] dir | device
<cjwatson> that is not a system call
<xivulon> ah
<cjwatson> that is a command
<cjwatson> man 2 umount
<xivulon> but doesn't umountfs use the command?
<xivulon> anyway moot point
<cjwatson> if you pass a device node to umount(8), it will simply look up the device node in mtab and figure out the mountpoint
<cjwatson> therefore it's not really unmounting by device, it's just a convenience
<cjwatson> my point is that you cannot tell the kernel "unmount everything mounted on this device"
<cjwatson> though it's true that if you pass a device to umount(8) it will try to unmount it from all the places where it's mounted
<xivulon> http://paste.ubuntu-nl.org/52284/
<xivulon> don't uses a file, but requires cut and grep
<cjwatson> that's incorrect. If /usr was mounted for some reason before the real / was mounted, and then a new /usr mounted over the top, the new /usr *must* still be unmounted during umountfs.
<xivulon> true
<xivulon> that's what I call a corner case
<cjwatson> but you seem to be putting serious effort into breaking this corner case when it's not necessary
<cjwatson> making this corner case work is *simpler*
<cjwatson> Evan's code above will take care of it just fine
<xivulon> one less then
<xivulon> evand you mentioned you were also working on #173659 any comment there? I'll be leaving in about 30m
<evand> nothing to report yet, I'm tied up with this sysvinit stuff at the moment.
<xivulon> sure
<evand> argh, xivulon's /host/boot to fstab patches fail for ubuntu inside ubuntu as you'll always have a boot directory inside /host.
<majikins> hi
<majikins> can someone help me with raid1 and lvm?
<majikins> I've setup via a howto on youtube
<majikins> testing to see if failover works
<majikins> disconnect one disk from the raid1 set and kernel loads but just gets stuck on either usb module load on cdrom
<majikins> on either disk
<majikins> anyone?
<Thugacation> yes?
<majikins> cool
<majikins> hi - hope you can help
<Thugacation> probably not
<majikins> maybe u can suggest where to go?
<majikins> I've installed ubuntu server with raid1 and lvm
<majikins> raid1 part does not quite work
<majikins> disconnect either disk of raid1 array and the system does not fully boot
<cjwatson> I think you need the kernel people rather than here
<cjwatson> #ubuntu-kernel
<majikins> cool - thank you
<CIA-22> oem-config: cjwatson * r397 oem-config/ (5 files in 4 dirs): * Activate appropriate input methods when changing language (LP: #181857).
<cjwatson> ^- fear the nasty code
<CIA-22> oem-config: cjwatson * r398 oem-config/lib/im_switch.py: remove stray debugging code
<cjwatson> evand: I think we might want something very similar to oem-config r397 in ubiquity at some point, though I'll want to test it more first
<xivulon> evand any bug you want to go through tonight?
<Thugacation> if you use wubi-installer to install linux to a folder on a windows os, doesnt that mean linux will run off of windows
<xivulon> nope
<xivulon> you can delete c:\windows and still boot wubi
<Thugacation> oooh... ahhh
<xivulon> you cannot remove the c: partition though
<Thugacation> i see
<cjwatson> Thugacation: it's just running from the Windows filesystem, that's all
<cjwatson> the Windows operating system is not running or otherwise involved
<Thugacation> yeah i had a brainfart for a second
<Thugacation> like windows is in c:\windows and wubi would be c:\wubi or something
<xivulon> basically a linux sees a file as a whole hard disk
#ubuntu-installer 2008-01-18
<xivulon> cjwatson anything against moving lupin/casper into a dedicated project called custom-installation?
<xivulon> aim is to allow modifying initrd/iso/installer using files and scripts available on local hard disk, lupin/casper code stays the same + I add lupin/alternate to provide equivalent functionality within the alternate CD
<xivulon> evand noticed your comment re #173659 would you mind expanding on it?
<xivulon> my understanding is that if you loopinstall inside linux, it will use /loopinstallation/disks/boot as /boot when you are within the loopinstallation
<xivulon> then the user will have to add an option to their regular grub pointing at /loopinstallation/disks/boot/grub/menu.lst
<xivulon> I did not test this configuration, but I assume that is what should happen
<xivulon> hence I do not see how the patch is problematic for linux based loopinstallations
<xivulon> the loopinstallation /boot is a directory sitting within the /host partition, but it is segregated from the host /boot dir.
<xivulon>  that's the same behaviour in linux and windows.
<thom> hell and death
<thom> there's no way i can see of forcing usb_storage not to load in gutsy's d-i
<thom> which means that #33249 kills autoinstalling :
<thom> (
<soren> thom: Isn't there a kernel option to disable usb altogether?
<thom> soren: yeah, trying that one. means no keyboard though
<soren> You're *auto*installing.
<thom> debugging past that point gets tricky ;)
<soren> Why do you care about a keybaord? :)
<thom> first gutsy autoinstall... i'm unconvinced it's gonna work flawlessly ;)
<soren> bug 33249
<ubotu> Launchpad bug 33249 in hw-detect "root partition once /dev/sdi1 then /dev/sda1" [Medium,Fix released] https://launchpad.net/bugs/33249
<soren> Does that still apply?
<thom> in as much that the USB mass storage still turns up as sda, yes
<soren> UUID based mounting surely should avoid that?
<thom> and there's nothing actually *attached* to the usb mass storage
<soren> Well, not avoid them showing up as sda, but it should alleviate any problems that might arise from it?
<thom> i guess i can just write a partman recipe for this specific hardware, but meh
<soren> I still fail to see how it's a problem?
<soren> From Edgy and onwards, we use UUID's all over the place?
<thom> d-i     partman-auto/disk       string  /dev/sda
<thom> is where the problem is. but like i say, a partman recipe for this hardware is not the end of the world
<thom> just irritating
<soren> Oh... Got it.
<CIA-22> ubiquity: cjwatson * r2411 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): * Simplify check for gconftool-2 being on $PATH.
<xivulon> evand ^^^
<evand> xivulon: I replied to the bug report directly.
<xivulon> ah
<evand> I also uploaded a new lupin.
<xivulon> great!
<xivulon> thanks a bunch
<evand> It hasn't hit the buildds yet though.
<evand> Anytime
<xivulon> so basically now we only have the grub bugs left out!
<evand> indeed
<xivulon> I won't be around this w/e though
<xivulon> if you have any q I'd rather answer today
<evand> I'll be in transit this weekend, so I wont be around either.
<xivulon> the 2 patches are about 10 lines in total, basically one patch detects whether we are using a loopinstallation and set kopt/kopt_2_6 to use the root and loop arguments correctly
<xivulon> the second patch simply ensures that grub-installer works when /boot is mounbinded
<evand> ok
<Jean-Paul> Hi everybody
<Jean-Paul> I don't know if this is the proper place for this mquestion, but here it is: I'm trying to update xserver-xorg-core using Update Manager
<Jean-Paul> only I get this error: "W: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1_i386.deb  403 Forbidden"
<evand> It's not, but the update was blocked as it caused serious problems.  Just ignore it for the time being.
<Jean-Paul> I did update the rest of the updates that were available today
<Jean-Paul> won't that cause any conflicts?
<evand> Nope
<Jean-Paul> thank you, I was wories about that
<Jean-Paul> *worried
<evand> You're welcome
<evand> Future reference though, such questions are best asked in #ubuntu.
<Jean-Paul> ok, thanks
<Jean-Paul> bye everybody (got a flight to catch :p)
<CIA-22> partman-auto-loop: evand * r40 partman-auto-loop.ubuntu/ (7 files in 4 dirs): * Add /host/boot to fstab (LP: #173659). Thanks Agostino Russo.
<CIA-22> oem-config: cjwatson * r399 oem-config/lib/im_switch.py: fix sense of XMODIFIERS test
<xivulon> evand added a comment to 175772 with new code to replace the first chunk, + there is no longer any need for umounthost in lupin-support (since new umountroot does the same thing)
<evand> ok
<xivulon> still need `kopt_2_6="$default_kopt"` down at ~822+
<CIA-22> oem-config: cjwatson * r400 oem-config/lib/im_switch.py: export GTK_IM_MODULE, QT_IM_MODULE, and XMODIFIERS; run input method as mortal user if sudoed
<cjwatson> mebrown: OK, I think this input method stuff is basically working now, although I've only tested it in the context of ubiquity, not oem-config (ubiquity is easier to fiddle with on the fly)
<cjwatson> mebrown: for ubiquity, the caveats are that (a) the locale you select isn't actually generated until much later due to memory constraints so scim will have the wrong input method selected by default (b) Chinese support isn't installed at present on the live CD due to space constraints
<cjwatson> mebrown: (a) only affects oem-config if you're using a language other than that selected by default during installation, so your default-to-Chinese systems won't do that
<cjwatson> (I think)
<cjwatson> mebrown: (b) ought not to affect oem-config since the full language-support-* package ought to be installed
<cjwatson> oh, and by "Chinese support" I meant "Chinese input method support" not translations and such
<CIA-22> oem-config: cjwatson * r401 oem-config/lib/im_switch.py: don't read all_ALL and default; that would involve starting up scim even for English
<CIA-22> oem-config: cjwatson * r402 oem-config/lib/im_switch.py: delete GTK_IM_MODULE, QT_IM_MODULE, and XMODIFIERS from environment if they vanish from IM configuration
<cjwatson> drat, can't quite get it to persuade gtk to switch input method on the fly though
<CIA-22> oem-config: cjwatson * r403 oem-config/ (lib/im_switch.py oem-config): inform GTK about input method change
<CIA-22> grub-installer: evand * r722 grub-installer.ubuntu/debian/control: Restore proper Original-Vcs-Svn field.
<CIA-22> grub-installer: evand * r723 grub-installer.ubuntu/debian/changelog: releasing version 1.27ubuntu2
<CIA-22> partman-auto-loop: evand * r41 partman-auto-loop.ubuntu/debian/changelog: releasing version 0ubuntu13
<xivulon> evand thanks again for merging the patches
<evand> xivulon: you're welcome.  Thanks for writing them.
<xivulon> I think now all the pieces are in place and as soon as the ISO is ready I should be able to have a +/- working wubi
<evand> awesome!
<xivulon> A shame I am not around this w/e, but hopefully will have something to play with mon-wed
<evand> let me know how it goes and we'll see about getting the new version on the CD
<xivulon> I would expect to have alphas next week, we can have maybe a few days of testing just in case there is a major blunder
<xivulon> then we can put it on CD
<evand> indeed
<evand> enjoy your weekend
<xivulon> you too
#ubuntu-installer 2008-01-19
<mebrown> cjwatson, thanks.
<mebrown> cjwatson, for us, customer will never see ubiquity, so as long as firstboot (oem-config) works ok, I'm happy.
<superm1> cjwatson, in case it has been overlooked, have you looked at the fix attached to bug 38442?
<ubotu> Launchpad bug 38442 in ubiquity "Ubiquity dialogues too large for 800x600 display" [High,Confirmed] https://launchpad.net/bugs/38442
<superm1> it appears to be functional
<superm1> from what i was just testing in my VM
<superm1> http://launchpadlibrarian.net/10893039/ubiquity.diff
<evand> superm1: that bug falls on my lap now, but yes, I have seen that patch.  The proper way to fix this is to make the timezone widget fit in a more reasonable size, which is nearing completion.
<superm1> evand, ah its good that you've narrowed down which widget was doing it
<evand> well it was more than one area, but after fixing the others this is what's left
<superm1> i'll have to check out my mythbuntu widget areas too for our UI.  i suppose i probably have a few that are a bit large too
<evand> ah, indeed
<superm1> still enabling that fullscreen ui may be useful when launching into ubiquity only mode off the disk
<superm1> and eliminate the necessity of a window manager in such cases
<evand> hrm, it's a good point that I'll have to give more thought.
<evand> but first, sleep
<evand> goodnight
<superm1> indeed
<superm1> night :)
<CIA-22> ubiquity: superm1 * r2412 ubiquity/scripts/mythbuntu/mythbuntu_install.py: correct minor typo on transmitter support
#ubuntu-installer 2008-01-20
<Robin> how to format a locked harddrive in gparted (dualbooting ith winxp)
<Robin> with winxp*
<xivulon> evand, I looked briefly at the daily build of the 20th but it's still the old lupin/casper, is that normal?
#ubuntu-installer 2009-01-12
<cjwatson> ls
<cjwatson> (d'oh)
<cjwatson> YKYBHTLW you type ls instead of /names ...
 * StevenK can't expand YKYBHTLW ...
<cjwatson> you know you've been hacking too long when
<persia> You know you've been hacking too late
<StevenK> Ahhh
<davmor2> xivulon: I did a couple of tests for slangasek today on hardy.2 and umenu is throwing up an invalid cd detected on the 20090112.1 cd
<kirkland> evand: hey, are you around?
<evand> kirkland: hi
<kirkland> evand: hey, i just saw slangasek's alpha3 freeze note and wondered if the encrypted home option might land in the graphical installer in time?
<evand> I'll try to get it in and uploaded today
<kirkland> evand: excellent, thanks.
<kirkland> evand: ping me when you do, and i'll download the next daily iso and add some testing to the mix
<evand> ok
<evand> will do
<xivulon> davmor2: did not look at hardy
<xivulon> I assume that the version has to be bumped up to 8.04.2
<xivulon> evand ^
<xivulon> that is both for wubi and umenu
<xivulon> and isolisto.ini
<evand> xivulon: Context?
<davmor2> xivulon: I think so just checking now
<xivulon> evand, I think that there is an issue with the new release of hardy
<davmor2> xivulon: yes 8.04.2 is now the number for the cd
<xivulon> we still have 8.04.1 in the code, so that all the checks within wubi/umenu will fail in 8.04.2
<xivulon> you basically have to grep the source for "8.04.1" and replace with "8.04.2" in both umenu and wubi branches
<xivulon> evand could you take care of that? I can push that tonight
<evand> ugh, remind me why the check is so restrictive?
<xivulon> It just tries to make sure that ISO/CD is what a given version of umenu/wubi is supposed to be handling, it was set up to match the full version string
<xivulon> we can relax that in jaunty, but for hardy/intrepid, we will have to up the version manually
<evand> of course, and please do change it for jaunty
<xivulon> will do
<xivulon> if the urls change though it will require a manual change to isolist.ini anyway (which might be the place where we also keep the version string)
<evand> can we not just assume that all versions will follow similar form and grab the version from .disk/info, then use it wherever needed in Wubi
<xivulon> the issue is when I do not have an ISO at all, I have to download, so I need to know the version string (if it enters the url)
<evand> hrm
<xivulon> You could otherwise assume that ubuntu.com/releases/8.04 will always point to the correct "subversion" i.e. .../releases/8.04.2
<persia> Perhaps a "current" symlink?
<xivulon> at the moment the way it is coded in jaunty, is that you need to update the version string (and urls) in isolist.ini as a single entry point, if urls satisfy the above I can relax the version string match in the code
<xivulon> so that 8.04 is ok also for 8.04.2
<xivulon> that I guess depend on the webmaster, I am ok with any solution
<xivulon> at the moment http://releases.ubuntu.com/8.04/ and http://releases.ubuntu.com/8.04.1 point to the same place.
<xivulon> I assume that 8.04 already works as a sort of "current" pointer
<xivulon> that of course has to hold for all the flavors covered
<evand> indeed
<evand> I was just going to mention that after I poked through the wubi code
<xivulon> I will simply relax the version check in jaunty to accept partial matches
<evand> ok
<xivulon> for hardy could you please do the changes? I think that steve would appreciate a quick fix there.
<evand> already on it
<evand> bzr is just taking ages to branch
<xivulon> thanks
<xivulon> yes the original bzr branch has a lot of junk in the history (my first one)... New one is much cleaner.
<superm1> evand, are you planning another ubiquity upload for alpha 3?  i've got a few things i wanted to merge in for the mythbuntu frontend yet and wanted to see where you were at on it so i have an idea when i'd need to have everything mergable by
<evand> yes
<xivulon> hmm I might have half working wubi/umenu code by tonight... at least to the point of being able to install in normal circumstances
<evand> superm1: ideally by tomorrow
<xivulon> with a few UI quircks
<evand> I think I'm still safe to upload then
<superm1> evand, okay yeah that should be fine.  i've got one more thing to do tonight
<evand> xivulon: wonderful!
<xivulon> well still haven't sorted out the transparency issues (could do with some help from win32 devs, as the documentation I found is quite poor)
<xivulon> and all the text is not finalized at all
<xivulon> plus I have python subrpocess insisting in opening a shell every time it runs
<cjwatson> xivulon: 8.04 already indeed does work as a "current" pointer, by intention
<xivulon> cjwatson, great so I will assume that from now on (jaunty), I'd guess that we can keep upping the string for intrepid/hardy
<cjwatson> intrepid is unlikely to get any point releases so you shouldn't need to worry about that
<xivulon> we will have to remember for hardy, it completely slipped under my radar for this release, sorry about that
<xivulon> evand note that umenu is now already in the same package as wubi, so you only need wubi.exe, launching that when a CD is inserted should in fact display the umenu screen
<xivulon> (so the theory goes...)
<evand> cjwatson: whenever you have a moment, can you add wubi commits to the cia bot, assuming you find such messages to be appropriate here
<evand> xivulon: noted; thanks
<xivulon> I will rename the branches jaunty.intrepid -> trunk soon
<xivulon> sorry jaunty.python -> trunk
<xivulon> as soon as I can install at least on my pc
<cjwatson> evand: done, though of course it relies on all committers dealing with the client-side setup as usual
<xivulon> will setup cia (noted)
<cjwatson> evand: BTW, feel free to set yourself up on cia.vc and claim joint ownership of the ubuntu-installer CIA bot
<cjwatson> xivulon: http://wiki.ubuntu.com/InstallerDevelopment has instructions
<evand> cjwatson: didn't realize I could
<cjwatson> it has quite lax access control and relies on history in case of problems
<xivulon> cjwatson: thx, I assume that the branch rename will not create particular issues
<cjwatson> CIA doesn't care much
<cjwatson> it'll just produce messages with the new name (assuming that 'bzr nick' matches the new name)
<evand> neat, though not the easiest thing to find on one's own
<evand> xivulon: 8.04.2 wubi uploaded to http://people.ubuntu.com/~evand/wubi/Wubi-8.04.2.exe and http://people.ubuntu.com/~evand/wubi/Wubi-8.04.2-standard.exe
<evand> I'm in the process of modifying cdimage to grab the correction version when building for hardy
<davmor2> evand: So it should be working tomorrow then?
<evand> davmor2: assuming slangasek or someone else generates new 8.04.2 CDs from cdimage, yes
<davmor2> evand: Cool I'll try it out tomorrow then :)
<evand> thanks!
<davmor2> np's
<evand> fingers crossed, I think I did that properly.  Next cd build of 8.04.2 should have the updated Wubi
<davmor2> nice one (crosses finger to be on the safe side)
<xivulon> evand thanks
<bdmurray> Is bug 310083 a duplicate of something else?
<ubottu> Launchpad bug 310083 in ubiquity "ubiquity crashed with KeyError in partman_edit_dialog()" [Undecided,Confirmed] https://launchpad.net/bugs/310083
<evand> Should be fixed with the next ubiquity release
<bdmurray> next being before Alpha 3?
<evand> indeed
#ubuntu-installer 2009-01-13
<xivulon> evand I am going to rename wubi/jaunty.python branch to wubi/trunk
<CIA-3> wubi: Agostino Russo * r52 trunk/ (16 files in 8 dirs):
<CIA-3> wubi: * Do not show the console when running pylauncher (thanks Hampus
<CIA-3> wubi:  Wessman)
<CIA-3> wubi: * Added memory and size checks
<CIA-3> wubi: * Added tabstops to controls in winui
<CIA-3> wubi: * When checking the version string, be less strict and allow
<CIA-3> wubi:  for subversions (thanks Evan Dandrea)
<CIA-3> wubi: Agostino Russo * r53 trunk/ (6 files in 6 dirs):
<CIA-3> wubi: * Fixed typo in the grub menu template
<CIA-3> wubi: * Run the uninstaller if the binary name begings with 'uninstall-'
<CIA-3> wubi: * Make sure that the backup dir is named after the target dir
<xivulon> I can get wubi to boot, but the preseed is not read
<xivulon> http://paste.ubuntu.com/104275
<xivulon> Did anything change re (initrd) preseeding?
<xivulon> the preseed file is now copied by lupin-casper/casper/scripts/casper-premount/30custom-installation into the initrd root
<xivulon> have to go, will follow up in 1h
<cjwatson> xivulon: initrd preseeding shouldn't have changed at all
<xivulon> cjwatson: ok will do some digging tonight
<xivulon> evand, with the above caveat, you can start playing with it.
<xivulon> for your reference here is my personal todo list: http://paste.ubuntu.com/104312/ (I will add bugs in lp later on)
<xivulon> note that now it is the trunk branch (lp:wubi)
<CIA-3> ubiquity: cjwatson * r2967 ubiquity/ (26 files in 5 dirs): Update copyright years.
<davmor2> xivulon: did the changes to umenu make it into the rebuild 20090113.1 is still saying invalid cd detected
<xivulon> ah didn't check that, assumed that evand had fixed it
<xivulon> let me browse the code online
<xivulon> ah no commit, I think evand produced the binaries yesterday.
<xivulon> well it would be a branch off rev 31 anyway
<davmor2> cjwatson: did ubiquity get encrypted home in yet do you know off hand?
<cjwatson> no
<xivulon> davmor2, although a bit rough, you might want to start testing wubi on the windows side, see above link about issues I am already aware of.
<davmor2> xivulon: is this on jaunty or hardy.2
<xivulon> jaunty, I cannot do much for .2 while in the office, and anyway it is mostly up to evand to ship the builds
<xivulon> you might have to build it yourself: bzr branch lp:wubi wubi && cd wubi && make
<xivulon> a few things will be installed inside wine, just accept the default options
<davmor2> xivulon: Right I'll give it a bash after I have installed kubuntu and had a play with that
<CIA-3> wubi: evand * r508 wubi.hardy/debian/changelog: releasing version 8.04.2
<evand> xivulon: As I understand it, the umenu check for a valid CD is fairly lax.  test_cd() just looks for the squashfs and .disk/info file, so the only update needed to umenu is for the version number printed on the UI
<davmor2> evand: xivulon: I'm getting the invalid cd detected with today's Ubuntu 9.04 i386 cd
<evand> hrm
<evand> is this the first time you've tested umenu in Jaunty or were you getting the same error previously?
<davmor2> evand: first test
<davmor2> not had much testing time so far
<evand> hrm, umenu doesn't have a logging option
<evand> offhand I'm not sure, but the new umenu/wubi should be landing soon
<evand> so lets not worry about this too much
<evand> I really need to get a copy of Windows so I can better track and help fix these things in the future.
<cjwatson> pretty sure you could expense one
<evand> Perhaps, though I'm leaning towards grabbing the Windows 7 beta as that's free and good until August.
<davmor2> evand: but not necessarily useful as most are still on xp/vista
<evand> davmor2: point taken
<davmor2> evand: cjwatson: ubiquity just crashed at the end of a kubuntu install uploading apport stuff now let you know when it's up
<evand> thanks
<davmor2> evand: bug 316800
<ubottu> Bug 316800 on http://launchpad.net/bugs/316800 is private
<davmor2> changed privacy
<xivulon> evand correct, if you see rev 31, it is going to be the same thing
<xivulon> http://bazaar.launchpad.net/~ubuntu-installer/umenu/devel/revision/31
<xivulon> for wubi see rev 502 (mostly the changes to data/isolist.ini)
<cjwatson> davmor2: whoops, my bad
<davmor2> cjwatson: np's
<cjwatson> I didn't have time to test that :-(
<CIA-3> ubiquity: cjwatson * r2968 ubiquity/ (debian/changelog scripts/install.py): Fetch subarchitecture in remove_extras (LP: #316800).
<davmor2> cjwatson: I'm guessing that this will effect ubiquity across the board then yes?
<CIA-3> ubiquity: cjwatson * r2969 ubiquity/debian/changelog: update for duped bug
<cjwatson> yes
<CIA-3> ubiquity: superm1 * r2970 ubiquity/ (5 files in 3 dirs): merge with mythbuntu ubiquity branch to simplify a lot of post install code and depend on maintainer scripts for packages rather than code that was rewritten specifically for ubiquity
<davmor2> cjwatson: I'll try it again tomorrow morning and see if it works :)
<xivulon> evand I will be home in 1-2h. do you want me to branch off wubi and umenu for 8.04.2?
<evand> xivulon: wubi 8.04.2 is already released and pushed.
<evand> umenu I just need to push
<xivulon> great , thanks a lot for that
<evand> anytime
<evand> Hrm, not exactly a hiccup at CIA
#ubuntu-installer 2009-01-14
<superm1> looks like CIA is limping and not working.. I just committed one more fix for ubiquity that's retroactive to the encryption stuff for mythbuntu_ui. (don't want that in there for now at least)
<superm1> kirkland, do you think there is a lot of value to offering in mythbuntu_ui?  I seem to think that for those types of boxes, a majority are autologinn'ed, so didn't want to present the option even to the user
<kirkland> superm1: hmm, i don't think i fully grasp your question
<cjwatson> evand: I think you need to add {set,get}_encrypt_home stubs to the noninteractive frontend too, otherwise it'll crash
<evand> ah, nice catch
<cjwatson> evand: maybe it would be worth having the simple "save result in a boolean member" implementation in BaseFrontend to simplify frontend implementations
<cjwatson> (same for auto-login)
<evand> still doesn't quite work yet, I need to add ecryptfs-utils to the proper seed
<evand> ah, noted
<cjwatson> seed> no time like the present ;-)
<evand> indeed :)
<cjwatson> the alternative answer is to have ubiquity depend on ecryptfs-utils
<cjwatson> that might be tidier
<cjwatson> though I concede that we are not as consistent and clear and obvious as we might be here
<evand> hrm, fair enough.  Will do.
<superm1> kirkland, i dont think that question should even be offered on the mythbuntu frontend.  it defeats user experience of the box if it present
<superm1> or well if it's used
<kirkland> superm1: oh, sorry, you mean the encrypt-home bit on mythtv's installer?
<superm1> mythbuntu installer - not the debconf for mythtv
<superm1> currently i put it to just hide offering it
<kirkland> superm1: i don't think it needs to be in the mythbuntu installer
<cjwatson> is autologin an option in the mythbuntu installer?
<cjwatson> or is it mandatory?
<superm1> cjwatson, if it's a frontend install, it's mandatory.  if it's a backend install it's not done at all
<cjwatson> I was under the impression that the plan was to make encrypt-home and auto-login mutually exclusive choices
<superm1> so that's why the line i put in to just hide the whole vbox should do the trick
<cjwatson> ok, so if it's mandatory then I agree that it makes sense not to offer encrypt-home
<evand> cjwatson: on further inspection, I'm not sure I follow you on your suggestion regarding "save result in a boolean member".  Are you suggesting I modify the code to use a callback to store a boolean value in a regular boolean variable?
<CIA-3> wubi: Agostino Russo * r54 trunk/ (5 files in 4 dirs):
<CIA-3> wubi: * Typo, it is preseed.cfg and not preseed.conf
<CIA-3> wubi: * Cleaned up custom installation hooks
<CIA-3> wubi: * Trailing white space does not get along well with line continuations
<CIA-3> wubi:  in preseed.cfg
<CIA-3> ubiquity: evand * r2974 ubiquity/debian/control: Depend on ecryptfs-utils so that it's available in the squashfs for the encrypted home option.
<CIA-3> ubiquity: evand * r2975 ubiquity/ubiquity/frontend/noninteractive.py: Add home encryption stubs to the noninteractive frontend.
<evand> superm1: anything else you'd like to land before I release?
<superm1> evand, i've got small odds and ends that haven't been tested yet, so nothing critical - i say go ahead with release
<evand> will do; thanks
<CIA-3> ubiquity: evand * r2976 ubiquity/debian/ (80 files in 2 dirs): Add i18n support for the login options.
<CIA-3> ubiquity: evand * r2977 ubiquity/ (d-i/manifest debian/changelog):
<CIA-3> ubiquity: Automatic update of included source packages: apt-setup
<CIA-3> ubiquity: 1:0.37ubuntu8, partconf 1.30ubuntu1.
<CIA-3> ubiquity: evand * r2978 ubiquity/debian/changelog: releasing version 1.11.3
<davmor2> cjwatson:  I got something weird goning on with Xubuntu alt.  It's popped up a message saying " Please insert the disc labeled: 'Xubuntu 9.04 _ Jaunty Jackalope_ - Alpha i386 (20090113)' in the drive '/cdrom/' and press enter.
<cjwatson> evand: I meant the same thing that noninteractive does with auto-login - saves it in self.auto_login
<cjwatson> evand: I was just suggesting promoting that from noninteractive to base since it's harmless and simplifies noninteractive
<cjwatson> davmor2: at what point?
<davmor2> Just after http proxy info
<davmor2> and add user
<cjwatson> sounds like bug 316618
<ubottu> Launchpad bug 316618 in debian-installer "jaunty alternate cd media change error" [Undecided,Incomplete] https://launchpad.net/bugs/316618
<davmor2> yeap hang on though I got the wrong image this morning re-syncing
<davmor2> cjwatson: I setup a cron job rsyncing the iso's but it must of done it before the updates went through
<xivulon> cjwatson, I got the preseed sorted (was a type), but then it enters into a loop: http://paste.ubuntu.com/104759/
<xivulon> not sure if that rings any bell, I will investigate the matter tonight
<cjwatson> davmor2: I'm going to be looking at this one ASAP anyway
<cjwatson> since I thought I'd fixed it but seem to have made it worse somehow
<cjwatson> xivulon: anything in the other log files? I'd expect a traceback somewhere
<xivulon> sorry cjwatson, took that at 2 am and went to sleep
<xivulon> will do more work tonight
<cjwatson> Jan 14 01:33:07 ubiquity: ['log-output', '-t', 'ubiquity', '--pass-stdout', '/bin/partman-commit'] exited with code 141
<cjwatson> xivulon: that's a segfault ... not good
<cjwatson> also a parted exception about rereading the partition table on /dev/loop2
<xivulon> yep noticed that, davmor2 maybe you could reproduce that too
<davmor2> xivulon: I'll have a look shortly
<xivulon> the recipe used is very similar to http://paste.ubuntu.com/104275/
<xivulon> davmor2, get the latest lp:wubi code, compile as explained yesterday, and run in windows
<xivulon> feel free to ask if you need any help
<davmor2> right oh
<cjwatson> for that /dev/loop2 thing, I need /var/log/partman as well
<cjwatson> that goes for any partitioning problems
<CIA-3> pkgsel: cjwatson * r128 ubuntu/debian/ (changelog postinst): Fix logic to check whether pkgsel/language-packs has been preseeded.
<CIA-3> cdrom-detect: cjwatson * r435 ubuntu/debian/ (cdrom-detect.postinst cdrom-detect.templates changelog):
<CIA-3> cdrom-detect: Record the filesystem used to mount cdrom-detect/cdrom_device in
<CIA-3> cdrom-detect: cdrom-detect/cdrom_fs for later use.
<CIA-3> apt-setup: cjwatson * r157 ubuntu/ (debian/changelog generators/40cdrom load-install-cd):
<CIA-3> apt-setup: Use cdrom-detect/cdrom_fs when remounting the CD to ensure that we do so
<CIA-3> apt-setup: using the same filesystem.
<cjwatson> none of this fixes davmor2's problem, just stuff I noticed
<davmor2> cjwatson: any idea why xubuntu live 64 build died there's one for the 13th and not for the 14th which is why the script to download died before the alternate cds
<cjwatson> have you checked the build logs?
<cjwatson> looks like a transient failure, anyway
<cjwatson> I'd recommend that you make your script cope with individual images along the way not existing
<cjwatson> I've kicked off a quick rebuild of just that image
<davmor2> cjwatson: thanks.  If I knew how to code I would so I'll get onto the people that wrote it instead :)
<cjwatson> well, it's just that I make the build logs public so that I can spend more time coding and less time investigating problems ;-)
<davmor2> I think it is since they put in the md5sum checker before that the script would just sync what was there
<cjwatson> huh? not true
<cjwatson> err, oh, sorry
<cjwatson> you're talking about the download script you're using, not about the CD build scripts
<cjwatson> I misunderstood
<davmor2> cjwatson: yes sorry not very clear :)
<cjwatson> davmor2: I've added new debugging instructions to bug 316618 - if you have time to run them through too it might help me ...
<ubottu> Launchpad bug 316618 in debian-installer "jaunty alternate cd media change error" [High,Confirmed] https://launchpad.net/bugs/316618
<james_w> does ubiquity write /etc/login.defs by any chance, or does it just leave that up to shadow to create?
<cjwatson> not directly, certainly
<davmor2> cjwatson: np's but it'll be after lunch now if that's okay
<cjwatson> davmor2: that's fine, thanks
<james_w> ok, thanks. Just investigating a surprising conffile prompt
<cjwatson> james_w: I can't think of anything in d-i that does that - /etc/login.defs is a conffile so it would be a bug if the installer wrote it
<james_w> cjwatson: ok, thanks, it seems I may have modified the file then
<cjwatson> check maintainer scripts just in case something there is buggy?
<james_w> can't see anything touching this file
<Scix> d-i shared/accepted-sun-dlj-v1-1 boolean true does not work in preseeding. I'm getting the meessage that i have not accepted the license. Any ideas?
<cjwatson> you've used the wrong owner. owner "d-i" means "this is only relevant to the core installer; don't copy me into the target system"
<cjwatson> use the package name for the Java package you want to preseed in that way instead of "d-i"
<Scix> OK, I'll try that. But d-i ldap-auth-config/dbrootlogin boolean true works. Why?
<Scix> is there any man pages for d-i and preseeding?
<Scix> i have googled some, but cant find anythig godt, besides the one in the ubuntu documentation
<cjwatson> no, it's in the installation guide
<cjwatson> d-i isn't great for manual pages at the moment
<cjwatson> I have no idea why ldap-auth-config/dbrootlogin works. Luck?
<Scix> hehe, many. I'm full of it :p
<Scix> *maybe
<cjwatson> oh, well, you're just setting ldap-auth-config/dbrootlogin to its default value
<cjwatson> anyway, I'd expect that to need 'ldap-auth-config ldap-auth-config/dbrootlogin boolean true'
<cjwatson> and would recommend you change your file
<Scix> d-i ldap-auth-config/rootbinddn string cn=administrator,dc=skole,dc=lk,dc=local also works, so it's not only default settings :)
<cjwatson> I don't know offhand why it's working, but that doesn't change my general statement
<Scix> thats ok ;) i'm just saying it. Won't argue about it :)
<Scix> but tanks for the tip :)
<cjwatson> where did you get the preseed line you used, so that I can correct documentation if I can?
<Scix> i found it using DEBCONF_DEBUG, and then just tried. It says in the ubuntu documentation that you can use d-i foo/bar
<cjwatson> which documentation? (URL if possible)
<Scix> https://help.ubuntu.com/8.10/installation-guide/i386/preseed-advanced.html#preseed-seenflag
<cjwatson> OK, I've committed a change to the upstream installation guide (which should filter down to Ubuntu in time) as follows:
<cjwatson> Note that the <quote>d-i</quote> owner should only be used for variables
<cjwatson> used in the installer itself. For variables belonging to packages installed
<cjwatson> on the target system, you should use the name of that package instead. See
<cjwatson> the footnote to <xref linkend="preseed-bootparms"/>.
<davmor2> cjwatson: right lunch finished just rebooting to start for the logs for you
<cjwatson> thanks
<davmor2> cjwatson: just double checking there are only 4 file I need to change to set -ex correct?
<cjwatson> yes
<davmor2> np's
<davmor2> cjwatson: you know how normally when you hit go back it goes to the main menu on d-i it don't on that screen it just keeps looping on itself.  I've added the new syslog to the bug so hope it helps
<cjwatson> yeah, go back is implemented programmatically so doesn't always go to the main menu
<cjwatson> ok, thanks
<davmor2> np's just ping me if there is anything else you need
<cjwatson> argh, I can't figure this out at all
<cjwatson> this is doing my head in
<davmor2> cjwatson: Deep breath hold it count to 10.  Swear a lot then look at it again calmly ;)
<cjwatson> davmor2: oh, hmm, do you still have this running?
<davmor2> yeap
<cjwatson> davmor2: can you switch to tty2 and run 'ls /cdrom'
<cjwatson> just tell me whether it returns an error or not, I don't need the output
<davmor2> no error just output
<cjwatson> davmor2: ok, now the same with 'ls /target/cdrom'
<davmor2> no output no error
<cjwatson> bingo
<cjwatson> thanks, I can take it from here
<davmor2> np's
<CIA-3> apt-setup: cjwatson * r158 ubuntu/ (debian/changelog generators/40cdrom generators/41cdset):
<CIA-3> apt-setup: Make sure apt-cdrom doesn't unmount the CD in the first place if cd_type
<CIA-3> apt-setup: ends with /single (LP: #316618).
<CIA-3> cdrom-detect: cjwatson * r436 ubuntu/debian/changelog: releasing version 1.30ubuntu2
<evand> argh, encryption option still broken.
 * evand digs
<CIA-3> apt-setup: cjwatson * r159 ubuntu/debian/changelog: releasing version 1:0.37ubuntu9
<davmor2> evand: is that on live?
<evand> yes
<davmor2> that's okay then thought I was going mad
<evand> heh
<davmor2> I've seen encrypted on alternate and had it working so it through me when I saw it was broken
<cjwatson> bug 317124 is weird, partman has clearly got totally confused
<ubottu> Launchpad bug 317124 in ubiquity "jaunty installer fails to accept manual ext4 schema" [Undecided,New] https://launchpad.net/bugs/317124
<cjwatson> Jan 14 14:39:16 ubuntu ubiquity: /lib/partman/choose_partition/60partition_tree/do_option: 113:
<cjwatson> Jan 14 14:39:16 ubuntu ubiquity: /lib/partman/active_partition/Use: not found
<cjwatson> evand: don't suppose this has anything to do with your recent changes?
<evand> yes it would, prior to the fix I believe
<evand> unless that's using today's CD
<cjwatson> oh yes, it's ubiquity 1.11.2
<evand> ah, good
<cjwatson> ok, can you merge or whatever as appropriate then?
<evand> will do
<cjwatson> thanks
<davmor2> cjwatson: do you think they'll be any chance of a rebuild so we can test the fix or will it be a case of have a look tomorrow?
<cjwatson> davmor2: I think it's potentially a3-critical so will probably rebuild later today
<davmor2> Cool :)
<cjwatson> still don't really understand why I couldn't reproduce it myself
<davmor2> cjwatson: look up is your favourite ornament lying down?
<davmor2> If not then that explains everytyhing :)
<evand> ah, libecryptfs.so.0.0.0 has gone missing in the target filesystem
<davmor2> evand: I'm not sure what that means but I'm guessing it's not good :)
<cjwatson> evand: might need to change user-setup to apt-install ecryptfs-utils in user-setup-ask rather than in user-setup-apply?
<cjwatson> at the moment it's later than blacklist generation
<evand> ahh
<evand> indeed I had suspected it was the blacklisting
<Scix> d-i preseed/late_command string auth-client-config -a -p lac_ldap failure with returncode 127. What does this mean?
<cjwatson> dunno, that's not an installer problem, means that that command failed. Investigate that command, which is not one maintained by the installer developers
<cjwatson> oh, you probably just need to run it chrooted
<cjwatson> try prefixing 'chroot /target' to the value
<Scix> posibly outdated docs to? http://ubuntuforums.org/showpost.php?p=6521410&postcount=8
<Scix> but as you said, it's not a installer problem
<Scix> tanks anyway :)
<cjwatson> those aren't docs, they're forum posts
<cjwatson> they're also aimed at setting it up after installation, not during installation
<cjwatson> adding chroot /target will probably fix it; I think exit code 127 means "command not found" (but check the syslog, I'm sure it will say)
<Scix> cjwatson, https://help.ubuntu.com/8.10/serverguide/C/openldap-server.html#openldap-auth-config
<davmor2> xivulon: can you have another look at https://launchpad.net/bugs/204133
<ubottu> Ubuntu bug 204133 in wubi/8.04 "wubi install unusable - Buffer I/O error on device loop0" [High,In progress]
<cjwatson> Scix: again, those are post-install directions
<Scix> sorry off topic
<cjwatson> and should be perfectly correct if you change it to 'd-i preseed/late_command string chroot /target auth-client-config -a -p lac_ldap' and ensure that the appropriate packages are installed first
<xivulon> ah davmor2 left, too late
<Ng> is there a way to select which drive d-i (specifically the netboot installer) will use?
<Ng> I have a machine with two array controllers on it, one of which has no disks and is showing up as cciss/c0d0 and partman refuses to go near it. I don't see a way inside the installer to switch to c0d1 which has disks and partitions. Just curious if there is an option I can set on the commandline before i go hunting/reporting bugs
<kirkland> evand: shall i download the desktop daily?  has the encrypt-home option made it in yet?
<evand> kirkland: it is, but it's broken at the moment.  Trying to work out exactly what's wrong (aside from the blacklisting picking up some ecryptfs files it shouldn't)
<kirkland> evand: okay, let me know if you need my help ;-)
<kirkland> evand: thanks!
<evand> anytime
<cjwatson> Ng: does it show up in the manual partitioner at all?
<cjwatson> Ng: if not, there is no "switch" because it's a bug :-)
<Ng> cjwatson: I can't get that to show up, I get a message from parted I've slightly forgotten (booting again now, but it's serial console, so will take a while) and offers Ignore/Cancel. Ignore just dumps me back to the menu
<Ng> cciss/c0d1 is in a lower slot number according to the bios, but I guess linux is enumerating in a different order because c0d0 is the one that has no disks
<Ng> (this is with jaunty, fwiw)
<cjwatson> I need /var/log/syslog and /var/log/partman; it's probably a parted bug of some kind
<cjwatson> I'm interested in whether the kernel detects it sanely
<Ng> I'll see what I can do. I suspect I'm going to be going to the DC tomorrow morning with a CD to do this by hand, in which case I can pull files off more easily than right now over serial
<Ng> "Unable to determine geometry of file/device /dev/cciss/c0d0. You should not use Parted unless you REALLY know what you're doing!\n\nWarning!\n\nIgnore\nCancel"
<Ng> Ignore => main menu. selecting Partition Disks from there takes me back to the geometry error
<Ng> err, where I said c0d1/c0d0 earlier I mean c1d0/c0d0. according to syslog partman is at least looking at c1d0 because it's noticed there are old LVM partitions on there
<Ng>  /var/log/partman is short enough to sanely paste: http://pastebin.ubuntu.com/104938/
<Ng> but i guess that's not very interesting, since it's being called on the "first" disk controller and obviously failing because there are no disks there
<cjwatson> (I have to go out for a bit, sorry, I'm running an hour late as it is)
<Scix> how can i run a sh script with preseed/late_command? Is it even posible?
<Scix> have to run a script after installation is done
<evand> yes, just pass the absolute filename of the script to preseed/late_command
<Scix> evand, absolute file name? Where do I save the file?
<evand> if you put it on the root of the CD, then preseed/late_command string sh /cdrom/your_script.sh
<Scix> sorry, i'm using network
<Scix> why cant i get this to work? Getting not-found in syslog... d-i preseed/late_command string auth-client-config -t nss -p lac_ldap; pam-auth-update ldap; echo "session required pam_mkhomedir.so skel=/etc/skel/ umask=0700" >> /etc/pam.d/common-session
<evand> Because you're not chrooted into the target filesystem
<evand> Please see the documentation:
<evand> https://help.ubuntu.com/8.10/installation-guide/i386/preseed-advanced.html
<Scix> I've read that page at least 10 times, but i'm to dumb to find out what to do x-)
<evand> preseed/late_command string in-target auth-client-config -t nss -p lac_ldap; in-target pam-auth-update-ldap; echo "session required pam_mkhomedir.so skel=/etc/sel/ umask=0700" >> /target/etc/pam.d/common-session
<evand> ^ I think that would work
<Scix> ok, so the trick is to put in-target in the front of the command?
<evand> right, that will set up the chroot
<cjwatson> evand: he failed to read the suggestion I gave him, so good luck :-/
<cjwatson> (I'd already suggested chroot /target, which apparently he ignored; in-target would do as well of course)
<evand> heh
<khashayar> Hi all, I'm testing the cdimage release candidates for alpha 3 (alternate installer), and have stumbled on a peculiar problem where the installer asks the user to insert a "disc labeled Ubuntu ...".
<khashayar> Are there any other logs than those under /var/log from the installation environment that I need to catch for the bugreport?
<charlie-tca> Is that a current download (just recently or earlier today)?
<khashayar> charlie-tca: Yes, downloaded today
<khashayar> But I've seen the same thing over the last few days.
<charlie-tca> Yes, but the images were rebuilt for today because of that bug. It should be fixed in 14.1
<khashayar> Oh, I'm testing 14
<khashayar> I'll take another look.
<charlie-tca> Thanks
<khashayar> I'm also testing the Ubuntustudio ISOs, but they're not updated?
<charlie-tca> I think they are still working on them
<khashayar> charlie-tca: thanks. I'll poke around a bit and see what I can find.
<charlie-tca> Okay. The normal Ubuntu cd's are still oversized, so they have to be built yet
<khashayar> So the images found here don't have the bugs resolved? http://cdimage.ubuntu.com/daily/current/ (I've no problem burning to DVD)
<charlie-tca> I think the images are valid, but it looks like you are up to 14.2
<khashayar> It seems so. But 14.2 is what I should test, then?
<charlie-tca> yes, if you burn it to dvd it should work
<khashayar> Great. I'll test as soon as the image is downloaded and will report here how I faired. Thanks for the help!
<charlie-tca> no problem.  Thanks for helping
<TheMuso> /c/c
#ubuntu-installer 2009-01-15
<xivulon_> cjwatson, here is the partman log http://paste.ubuntu.com/105013/
<cjwatson> khashayar: bug 316618
<ubottu> Launchpad bug 316618 in apt-setup "jaunty alternate cd media change error" [High,Fix released] https://launchpad.net/bugs/316618
<cjwatson> it was indeed very peculiar, I couldn't actually reproduce it myself, but I *think* I've fixed it
<TheMuso> cjwatson: Neither was I, i.e unable to reproduce that issue. had no problem with CD testing.
<khashayar> cjwatson: I can confirm that it was fixed here as well. Now waiting for those ubuntustudio disks :-)
<cjwatson> khashayar: great, good to have confirmation!
<cjwatson> xivulon_: (acknowledged, may take a while to digest)
<xivulon_> let me know if there is any further info you need I have the system running atm
<cjwatson> I might simply be too tired to attempt it tonight :-/
<xivulon_> that makes 2 of us
<cjwatson> that's odd, why isn't that device PED_DEVICE_FILE
<cjwatson> oh, of course /dev/loop2 wouldn't be
<cjwatson> xivulon_: this completely breaks wubi, right?
<xivulon_> yes, ubiquity just stops
<xivulon_> or better it keeps churning for a long time (until I stop it)
<cjwatson> xivulon_: fixed in the parted upload I just did, I *think*
<cjwatson> obviously it's possible it will fail later
<cjwatson> that said I'm not sure why it's hitting that code path to begin with (that should be for old kernels only, I think), but honestly can't be bothered to figure it out right now :)
<xivulon_> cjwatson, thanks, was tempted to try the patch, but have to sleep, will give it a go tomorrow
<Ng> I think I found two more bugs, only one of which matters at the moment - I started the installer with a disk tha tpreviously had a couple of primary partitoins and a large logical one used by LVM
<Ng> I've removed all the LVs and the VG, but it won't let me remove the LVM partition, it tells me it's still in use by the VG I've removed
<Ng> displaying the LVM config in that section tells me there are no volume groups
#ubuntu-installer 2009-01-16
<xivulon_> cjwatson I get partman-auto-loop/unclean-host error although the virtual disk file is empty and should not generate that
<kirkland> i'm having trouble installing from today's desktop-amd64 installer, failing on formatting the partition
<kirkland> "The ext3 file system creation in partition #1 of SCSI1 (0,0,0) (sda) failed."
<cjwatson> xivulon_: logs again, I guess :-/ Too late for me to attempt to debug it now
<cjwatson> kirkland: same for you
<cjwatson> (unless evand's handy)
<kirkland> cjwatson: not an emergency
<cjwatson> well, it might be if other folks are seeing it
<kirkland> cjwatson: i'll gather for you though
<kirkland> cjwatson: yeah, i'm just doing some daily iso testing ;-)
<cjwatson> oh, I should update partman-auto-loop for ext4, I notice
<kirkland> cjwatson: evand: I like the presentation of the encrypt-home bit!  cheers for that!
<cjwatson> all evand's work
<kirkland> cjwatson: particular logs you want?  the usual?
<CIA-3> partman-auto-loop: cjwatson * r47 ubuntu/ (autopartition-loop debian/changelog): Add ext4 support.
<xivulon_> cjwatson I guess this is due to autopartition-loop, will have a quick go myself at it
<cjwatson> kirkland: syslog and partman
<kirkland> cjwatson: sure
<cjwatson> xivulon_: odd, I can't imagine how that would fire if there weren't really any images
<cjwatson> 'mount -t auto -o loop,ro /host$path /tmpmountpoint' has to succeed
<cjwatson> you might want to set -x it to see exactly what's going on
<kirkland> cjwatson: what should I file the LP bug against?
<cjwatson> ubiquity
 * kirkland always gets it wrong :-)
<cjwatson> alternate => debian-installer, desktop => ubiquity
<cjwatson> as a rule of thumb
<xivulon_> already done that (-x)
<kirkland> cjwatson: ah, i usually file this sort of thing against partman
<cjwatson> oh, you can do that but TBH it is tricky to figure out which partman component is involved without code inspection
<cjwatson> I get it wrong on a regular basis
<cjwatson> (I'd rather partman were just one big component really, but it wasn't my idea and it's pain to merge them)
<kirkland> cjwatson: that's the part i meant i always get wrong :-)
<kirkland> * kirkland always gets it wrong :-)
<kirkland> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/317709
<ubottu> Launchpad bug 317709 in ubiquity "jaunty: ext3 filesystem creation failed" [Undecided,New]
<kirkland> cjwatson: with partman, syslog, and screenshot
<cjwatson> ok
<cjwatson> Jan 16 00:30:33 ubuntu ubiquity: /bin/partman-commit: 23: stralign: not found
<cjwatson> Jan 16 00:30:36 ubuntu udevd-event[7286]: mknod(/dev/pktcdvd/control, 020660, (10,62) failed: Too many levels of symbolic links
<cjwatson> Jan 16 00:30:36 ubuntu partman: mke2fs 1.41.3 (12-Oct-2008)
<cjwatson> Jan 16 00:30:36 ubuntu partman: Could not stat /dev/sda1 --- No such file or directory
<cjwatson> the combination of all of that is not all that encouraging
<cjwatson> can you check whether /dev/sda1 exists?
<cjwatson> the stralign thing is harmless but I'll fix it anyway
<xivulon_> cjwatson I zeroed the virtual disk and it works, looks like a left-over from a previous test (not sure why because I uninstalled)
<cjwatson> xivulon_: hmm. oh well ...
<xivulon_> well sort of works, seems to get stacked on the same point as last time
<xivulon_> logs on their way
<CIA-3> partman-base: cjwatson * r122 ubuntu/ (debian/changelog partman-commit):
<CIA-3> partman-base: Resynchronise partman-commit with partman, fixing harmless warning about
<CIA-3> partman-base: stralign.
<cjwatson> kirkland: I'm wondering if the udevd failure there rendered it somehow unable to create /dev/sda1. Would be strange
<cjwatson> or whether it actually wasn't /dev/sda1 at all. 'udevadm info --export-db' or similar might be worth hunting through
<kirkland> cjwatson: this a kvm, qcow2 disk
<cjwatson> same as I use for testing
<cjwatson> a single mknod() failing shouldn't break anything else, from my reading of udevd's code
<xivulon_> cjwatson, paste.ubuntu.com/105383
<evand> kirkland: cjwatson: the design was mpt's suggestion
<davmor2> cjwatson: there seems to of been an epic fail with ubiquity oem so I'm trying an alt install of it.  If I get a fail I'll throw up the log files
<davmor2> encrypted lvm is causing issues with the ext2 /boot failing to partition
<davmor2> cjwatson: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/317618
<ubottu> Launchpad bug 317618 in debian-installer "Xubuntu jaunty-alternate-i386.iso fails to re-partition 40GB drive w/multiple partitions" [Undecided,New]
<cjwatson> davmor2: bug 317791 perhaps?
<ubottu> Launchpad bug 317791 in oem-config "oem-config-dm installer fails" [Undecided,New] https://launchpad.net/bugs/317791
<cjwatson> bugger, it's going to take over three hours to download the desktop image
<davmor2> cjwatson: sorry away just got back.
<davmor2> I can reproduce it every time the install is different to what is already on the hd
<davmor2> cjwatson: my hd has borked a bit on the test machine that I was installing oem on so I need to wipe and try again
<cjwatson> davmor2: I didn't mention it here, but I figured out the problem
<cjwatson> new parted upload is working its way through
<cjwatson> will have affected both d-i and ubiquity, I'm afraid, probably pretty much hosing all partitioning :-(
<davmor2> :(
<davmor2> never mind give me something to do any ideas on when the new images will be up?
<cjwatson> couple of hours - the new parted won't have finished publishing yet
<cjwatson> slangasek is already going to hurt me, I'm sure
<cjwatson> since it was due to a patch I shoved through at short notice for wubi
<davmor2> charlie-tca: there's a fix in place for the partitioning issue but it will need a respin on most of the images
<charlie-tca> Good news, then!
<charlie-tca> I am trying to be patient :-)
<davmor2> cjwatson: here borrow my stab/bullet/bomb proof vest for when you tell slangasek
 * charlie-tca thinks it _can_ be that bad
<cjwatson> I pushed in a late change which broke the world. That tends to make one unpopular
<davmor2> especially as the release date has been pushed back a day already :(
<davmor2> cjwatson: on a plus side most of the apps have been tested now so it's only the installer
<cjwatson> mm
<cjwatson> as long as nobody uploaded changes ...
<davmor2> and waiting for the images
<davmor2> no don't point that bit out to slangasek though ;)
<xivulon> cjwatson left you some logs yesterday night, not sure if you noticed, doesn't look to different from previous one
<cjwatson> xivulon: I thought you said the problem was solved - anyway there was a parted bug I created by trying to fix your previous issue
<cjwatson> so that could easily be it
<xivulon> will today iso include all relevant fixes?
<cjwatson> I'm about to rebuild
<cjwatson> today's is broken
<xivulon> good I will test tonight
<xivulon> thanks for the patches
<xivulon> reading https://wiki.ubuntu.com/UDSJaunty/Report/Foundations it seems that grub2 will happen for jaunty, my understanding of what happened at UDS (I missed that track) was quite different
<cjwatson> it doesn't say that at all
<cjwatson> it's in a section marked "These features involve development or other actions by the community, and thus we cannot guarantee their implementation within this release cycle"
<cjwatson> not at all definite
<xivulon> thanks for clarifying
<CIA-3> partman-target: cjwatson * r743 ubuntu/ (debian/changelog finish.d/fstab_removable_media_entries):
<CIA-3> partman-target: Fix disk_containing function to use its argument rather than relying on
<CIA-3> partman-target: $dev.
<cjwatson> evand: assigned bug 317068 to you since you said you were working on the same thing yesterday
<ubottu> Launchpad bug 317068 in ubiquity "ubiquity crashed with InstallStepError in configure_user()" [Undecided,In progress] https://launchpad.net/bugs/317068
<superm1> xivulon, grub2 was supposed to be added as an option into the installer (and preseedable) so more feedback could be gathered on it this cycle from what I recall in discussions
<tjaalton> I'd be willing to test it, and make it available
<cjwatson> I think somebody needs to get its update-grub equivalent up to par with our Ubuntu modifications to grub first
<cjwatson> and in general check all our modifications over - which will be a fairly long job unfortunately
<tjaalton> hmm :)
<tjaalton> I'll poke it next week
<tjaalton> oh, that's not a part of the installer.. what does d-i need in order to be able to use it?
<cjwatson> grub-installer already has basically the relevant code
<cjwatson> Debian did that
<tjaalton> right
<cjwatson> although we've temporarily disabled it until such time as we actually want to use it
<tjaalton> and what about the gtk+ frontend?
<evand> cjwatson: ok; thanks
<cjwatson> tjaalton: no progress since you last asked
<superm1> cjwatson, who wrote a majority of the update-grub modifications?  perhaps since they are best versed upon what was changed they should be the one who opts to poke it?  I added a few things in it in hardy at some point to bring it closer, but i'm sure there is still a lot missing
<tjaalton> cjwatson: heh ok
<cjwatson> superm1: err, a cast of thousands^Wseveral
<cjwatson> no matter who does it it'll be a matter of painstakingly going through the diff
<superm1> cjwatson, ah...
<tjaalton> heh, debdiff is 12k lines :)
<tjaalton> of the package, update-grub alone is ~1000 lines
<superm1> well update-grub would be the only thing that needed updating though.
<CIA-3> oem-config: cjwatson * r577 trunk/debian/ (changelog oem-config-udeb.postinst): Suppress user-setup's encrypted home directory question in OEM mode.
<tjaalton> I see slangasek on the list of update-grub contributors :)
<superm1> cjwatson, why suppress that question in OEM mode?  Shouldn't users of preinstalled systems be able to have the same question presented?
<xivulon> had a couple of patches in the update-grub related to wubi, but if grub2 supports loop mounting and vfat/ntfs they might not need to be ported
<xivulon> I can play with that once I can get the installation to complete
<cjwatson> superm1: the suppression is in the first stage; I haven't yet got round to *adding* the question to the second stage but I agree that that makes sense
<cjwatson> superm1: i.e. it doesn't make sense for the OEM customisation user to have an encrypted home directory
<superm1> cjwatson, oh okay :)
<davmor2> xivulon: cjwatson: evand: Umenu is still coming up with invalid CD detected
<davmor2> wubi starts up and immediately starts downloading from the interweb
<evand> davmor2: jaunty or 8.04.2?
<davmor2> latest respin of jaunty
<davmor2> evand: this one 8e01f42693bb81a9b27bc4224cf5bb64 *jaunty-desktop-i386.iso
<evand> davmor2: we're on the cusp of replacing umenu and wubi with a python rewrite, but have not done so yet.  So I'd hold off on testing them for the time being.
<davmor2> evand np's
 * davmor2 moves onto m-a instead
<cjwatson> sorry, didn't realise the rewrite was happening
<cjwatson> well, at least not soon
<davmor2> cjwatson: np's I needed xp on for migration-assistant anyway :)
<evand> No worries.  xivulon has been working on it, and it seems to almost be ready enough for the CDs.
* You're now known as ubuntulog
<CIA-3> partman-target: cjwatson * r744 ubuntu/ (debian/changelog finish.d/fstab_removable_media_entries):
<CIA-3> partman-target: Fix use of udevinfo rather than udevadm info when checking if a disk is
<CIA-3> partman-target: USB.
<davmor2> meh hd is playing up need to low level format it
<kirkland> cjwatson: is there a desktop iso yet that fixes the filesystem creation failure i had yesterday?
<cjwatson> kirkland: yep, current one
<cjwatson> it turned out to be a parted bug I introduced, once I reproduced it (albeit on alternate)
<kirkland> cjwatson:  http://cdimage.ubuntu.com/ubuntu-server/daily/current/jaunty-server-amd64.iso ?
<kirkland> cjwatson: sorry, that's server
<cjwatson> kirkland: not affected
<kirkland>  wget http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-amd64.iso
<cjwatson> yes
<kirkland> cjwatson: cool, thanks, i'm downloading
<davmor2> yay hd fixed try again
<cjwatson> evand: just looking at the oem-config language screen - would it be worth sorting the languages down then right, rather than right then down? so:
<cjwatson> A D G               A B C
<cjwatson> B E H  rather than  D E F
<cjwatson> C F I               G H I
<cjwatson> I find it rather hard to read at the moment and am wondering if that's why - FWIW the gfxboot language screen is sorted the first way
<cjwatson> I think people are typically used to reading right then down for flowing text, but down then right for columns (compare newspaper layout)
<evand> cjwatson: sure, I'm not tied to either way
<cjwatson> hmm, except it isn't clear to me that you can tell an iconview to do that
<cjwatson> it seems to be pretty set on laying them out in rows
<evand> yikes
<cjwatson> I filed http://bugzilla.gnome.org/show_bug.cgi?id=568033 upstream
<ubottu> Gnome bug 568033 in GtkIconView "horizontal item ordering for GtkIconView" [Enhancement,Unconfirmed]
<CarlFK1> alt installer: where all is the username used?  /home/user and /etc/passwd is all I can think of
<cjwatson> I wouldn't like to try to list every possible place
<cjwatson> programs have a bad habit of copying the username around
<cjwatson> I'd just grep for it if you care
<cjwatson> and 'find' as well, since it ends up in filenames (e.g. the crontab spool)
<kirkland> cjwatson: hmm, i still haven't successfully installed the jaunty desktop :-/
<kirkland> cjwatson: latest try ended with a python backtrace
<cjwatson> kirkland: with encrypt-home enabled?
<kirkland> cjwatson: tried to send an error report but my connectivity is poor at the moment (in the car)
<kirkland> cjwatson: yup
<kirkland> cjwatson: i'm trying without now
<cjwatson> kirkland: that's known
<kirkland> cjwatson: ah, okay
<kirkland> cjwatson: evand looking at it, or does he need my help?
<cjwatson> I've lost the bug number, but it's on the jaunty tech overview page
<cjwatson> bug 317068
<ubottu> Launchpad bug 317068 in ubiquity "ubiquity crashed with InstallStepError in configure_user()" [Undecided,In progress] https://launchpad.net/bugs/317068
<kirkland> cjwatson: gotcha.  so that's not going to be fixed in time for the alpha?
<cjwatson> no, afraid not
<kirkland> :-/ :-/ :-/
<cjwatson> we only found out about it rather too late
<kirkland> i know, i understand
<cjwatson> yeah, I'm disappointed, but there you go
<kirkland> i've downloaded an ISO a day trying it :-)
<kirkland> (2 some days)
<kirkland> well, on the bright side, we might get the filename encryption in the kernel and working before the next alpha
<cjwatson> it wasn't helped by me screwing up parted ...
#ubuntu-installer 2009-01-17
<xivulon_> I am asked for the pwd although that is preseeded d-i passwd/user/password/crypted password xxx
<xivulon_> was there any change there?
<xivulon_> that is passwd/user-password-crypted
<xivulon_> and I get "ClockSetup failed with code 1" (d-i clock-setup/utc boolean false)
<tjaalton> hmmh, grub2 doesn't support password locking yet, so it's a no-go here.. therefore no porting effort by me :/
<xivulon_> other than the above, I managed to boot for the first time :)
<xivulon_> woo just did apt-cache search grub
<xivulon_> there are things like grub-invaders
<xivulon_> that would be cool
<superm1> did something change w/ CIA?  I just merged another revision and it's just hanging at "Submitting revision to CIA."
<xivulon_> I managed to boot using grub2 from a loopmounted filesystem using the loopback and ntfs modules
<superm1> cool :)
<xivulon_> yeah that would simplify things quite a bit on my side, and we would no longer need a bindmounted /boot
<xivulon_> and there would be no need for grub4dos
#ubuntu-installer 2009-01-18
<CIA-59> wubi: Agostino Russo * r55 trunk/ (14 files in 9 dirs): Improved arch detection
#ubuntu-installer 2010-01-18
<CIA-6> ubiquity: superm1 * r3664 ubiquity/ (debian/changelog scripts/mythbuntu/mythbuntu_install.py):
<CIA-6> ubiquity: Drop old hack for reconfiguring mythbuntu-default-settings since
<CIA-6> ubiquity: this is fixed in user-setup now.
<CIA-6> debian-installer: cjwatson * r1202 karmic-proposed/ (build/config/common debian/changelog): Use udebs from karmic-security, karmic-proposed, and karmic-updates.
<CIA-6> debian-installer: cjwatson * r1203 karmic-proposed/ (10 files in 3 dirs): Move to 2.6.31-17 kernels.
<CIA-6> debian-installer: cjwatson * r1204 karmic-proposed/ (build/config/armel/imx51.cfg debian/changelog): Move iMX51 images to 2.6.31-107 kernels.
<CIA-6> debian-installer: cjwatson * r1205 karmic-proposed/ (build/config/armel/dove.cfg debian/changelog): Move Dove images to 2.6.31-210 kernels.
<CIA-6> debian-installer: cjwatson * r1206 karmic-proposed/debian/changelog: fix version
<CIA-6> debian-installer: cjwatson * r1207 karmic-proposed/debian/changelog: releasing version 20081029ubuntu70.1
<CIA-6> ubiquity: cjwatson * r3665 ubiquity/ (12 files in 6 dirs):
<CIA-6> ubiquity: Only restart debconf-communicator when changing language, not every time
<CIA-6> ubiquity: we switch page. This speeds up page transitions quite a bit.
<ev> hrm, perhaps target-config would've been a better place for the apparmor cache generation stuff.
<ev> debconf-communicator> oh, nice!
<saispo> hi
<saispo> anyone known how to bypass gpg check in preseed ?
<saispo> i lost the d-i line :/
<cjwatson> saispo: https://help.ubuntu.com/9.10/installation-guide/i386/preseed-contents.html search for "gpg"
<saispo> good ! thanks cjwatson
<cjwatson> ev: I asked James about the GeoIP ticket today; we've tentatively set a due date of 1st Feb, and he's going to hunt around for somebody to implement it.  Will that be time enough for you?
<ev> cjwatson: yes
<cjwatson> great, thanks
<ev> and thanks for chasing it
<cjwatson> hmm, there's something odd about translation handling right now.  plugin pages aren't getting translated
<CIA-6> ubiquity: evand * r3666 ubiquity/ (debian/changelog scripts/install.py):
<CIA-6> ubiquity: * Don't try to generate an apparmor cache in oem-config.
<CIA-6> ubiquity: * Slightly better exception printing in scripts/install.py
<ev> I'd put money on it being that the widgets for each plugin page are not added to frontend.all_widgets.  I worked around that for removing labels from the focus ring, but didn't think to do the same for translations.
<cjwatson> that was my first guess but it seems not to be true
<cjwatson> aha
<cjwatson> I wonder if this is because each plugin instantiates its own gtk.Builder
<cjwatson> which means that of course self.builder.get_objects() in the frontend doesn't return plugin objects
 * cjwatson tries http://paste.ubuntu.com/358553/
<cjwatson> not quite
<cjwatson> hmm, that's no good.  we do genuinely need a different builder for each plugin due to how signal connection works.
<cjwatson> ev: actually you're right, I was confusing frontend.all_widgets with mod.all_widgets
<ev> ahh
<CIA-6> ubiquity: cjwatson * r3667 ubiquity/ (6 files in 3 dirs):
<CIA-6> ubiquity: * GTK frontend:
<CIA-6> ubiquity:  - Check plugin builders as well when adding widgets (setting their
<CIA-6> ubiquity:  names, making them callable by the toplevel, etc.). This fixes
<CIA-6> ubiquity:  translations of the language, timezone, and keyboard pages.
<CIA-6> ubiquity: cjwatson * r3668 ubiquity/ubiquity/frontend/ (gtk_ui.py kde_ui.py): spacing
<CIA-6> ubiquity: cjwatson * r3669 ubiquity/ (3 files in 2 dirs): Fix immediate retranslation when changing language.
<CIA-6> ubiquity: cjwatson * r3670 ubiquity/ubiquity/frontend/kde_ui.py: spelling
<CIA-6> ubiquity: cjwatson * r3671 ubiquity/ubiquity/frontend/kde_ui.py: show_browser died a long time ago, and I think this was a GTK thing anyway
<cjwatson> ev: does http://paste.ubuntu.com/358609/ feel right to you?  this (a) changes regain_privileges/drop_privileges to keep a semaphore, so that if you call regain/drop within a regain/drop pair funny things don't happen (b) makes drop_all_privileges permanent so that you get an assertion if you try to call regain/drop thereafter (c) adds a context manager so that you can do 'with raised_privileges(): BLOCK'
 * ev looks
<cjwatson> (c) sometimes results in greater nesting, but if we use it consistently then we avoid forgetting about putting drop_privileges in a finally: block and that sort of thing
<ev> looks fantastic
<ev> thanks for doing that
<ev> (and hooray for python 2.6)
<cjwatson> ev: ok, cool.  2.5, BTW :-)
<ev> err yeah
<ilowe_> Hi guys, I'm trying to preseed an installation on hardware raid and can't seem to find the d-i line to skip the "Do you want to enable RAID" question during the install. Any ideas?
<CIA-6> ubiquity: cjwatson * r3672 ubiquity/ubiquity/frontend/kde_ui.py: use regain_privileges rather than writing out the same code
<CIA-6> ubiquity: cjwatson * r3673 ubiquity/ (debian/changelog ubiquity/misc.py):
<CIA-6> ubiquity: Add a semaphore to misc.regain_privileges and misc.drop_privileges, so
<CIA-6> ubiquity: that a drop/regain pair always returns to the previous state.
<CIA-6> ubiquity: misc.drop_all_privileges is now more clearly one-way, enforced by an
<CIA-6> ubiquity: assertion.
<superm1> cjwatson, is there a reason that /usr/share/apt-setup/release-files/archive.ubuntu.com contains tons of files from older releases on current media?
<CIA-6> ubiquity: cjwatson * r3674 ubiquity/ubiquity/ (debconfcommunicator.py i18n.py): factor out unnecessary subprocess_setup functions that just call misc.regain_privileges
<cjwatson> superm1: we could probably ditch those
<cjwatson> ev: oh yeah, you had to use the with_statement pragma in 2.5, hmm
<CIA-6> apt-setup: cjwatson * r180 ubuntu/ (61 files in 23 dirs): Remove Release files for old releases.
<ev> ah, whoops.  Are you already working on that or shall I add the from future imports?
<cjwatson> we could just require 2.6
<cjwatson> I don't particularly mind that
<ev> I'm fine with that as well
<cjwatson> I found a neater way to do some of this too
<cjwatson> @raise_privileges
<cjwatson> def func(...):
<cjwatson>     ...
<cjwatson> does mean you have to carefully distinguish between raised_privileges (context manager) and raise_privileges (decorator); I did find a way to make the same spelling work for both, but the cure was worse than the disease
<ev> heh, very cool though
<ev> I'm a big fan of decorators
<ev> I use one for threads_enter/_leave in usb-creator
<cjwatson> (cure worse than the disease: it required a class with def __init__(func=None).  I'm OK with default arguments but I don't like the effect of passing a defaulted argument being to make the class be a completely different category of thing)
<ev> yeah, yikes
<CIA-6> ubiquity: evand * r3675 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
<CIA-6> ubiquity: GNOME Bug #56070 (can't click button twice) has long since been
<CIA-6> ubiquity: closed. Remove hack.
<ubottu> Gnome bug 56070 in gtk "Can't click button after setting it sensitive." [Major,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=56070
<ev> cjwatson: is there a particular reason why UTF characters, specifically an ellipsis, are not used in debconf description fields?  Digging through my ~/bzr doesn't find any, and my google-fu is failing to find a reason.  I can understand why we didn't do it historically, but what doesn't have proper unicode support these days?
<ev> s/UTF/unicode/
#ubuntu-installer 2010-01-19
<CIA-6> ubiquity: evand * r3676 ubiquity/ubiquity/frontend/gtk_ui.py: Missed one spot that had a bgo 56070 workaround.
<cjwatson> ev: I guess not that many people are believers in the Unicode ellipsis in English text; it always seemed to be asking for trouble to me :-)
<ev> I think it looks a bit nicer (http://tecnocode.co.uk/2009/10/01/unicode-in-gnome/), but not enough for me to go and invalidate a whole bunch of translations.
<cjwatson> the other constraint might be that gettext restricts msgids to ASCII-only
<cjwatson> or strongly recommends, anyway
<cjwatson> this is apparently because if gettext doesn't find a translation it returns the msgid unchanged without doing any recoding
<cjwatson> but the upshot is that if you try to put non-ASCII text in msgids, you get whines on stderr all the time, so most people avoid it
<CIA-6> grub-installer: cjwatson * r833 no-device-map/ (debian/changelog grub-installer): Use an appropriate OS device name rather than (hd0) if possible.
<ev> perhaps its best solved in en_* then.
<ikt> heya anyone alive >.>
<ev> cjwatson, michaelforrest: (bug 414912, bug 336751) thoughts? http://people.canonical.com/~evand/tmp/transitions.html
<ubottu> Launchpad bug 414912 in ubiquity "Poor progress feedback for Back/Forward on slow machine" [Undecided,New] https://launchpad.net/bugs/414912
<ubottu> Launchpad bug 336751 in ubiquity ""Starting up the partitioner" uses separate window misleadingly" [Low,Confirmed] https://launchpad.net/bugs/336751
<ev> I'm afraid it's even more jarring than the existing version.
<cjwatson> ev: I was hoping we could use a status bar or something
<cjwatson> I agree this is pretty jarring
<cjwatson> I like what you've done with the manual partitioner though!
<ev> thanks
<ev> I think I need to smooth that out a bit
<michaelforrest> ev let's talk about this in a bit
<michaelforrest> (I am about to go to a meeting )
<ev> michaelforrest: sure thing
<cjwatson> does it disable the UI when the spinner is up in the manual partitioner?
<ev> yes
<cjwatson> in bug 336751, mpt said "A status bar would be quite inappropriate in an assistant-style window such as the installer", but gives no reasoning for this declaration
<ubottu> Launchpad bug 336751 in ubiquity ""Starting up the partitioner" uses separate window misleadingly" [Low,Confirmed] https://launchpad.net/bugs/336751
<ev> cjwatson: indeed, that's what I was going off of
<ev> it's a shame he's not around, but perhaps michaelforrest (when he gets back) understands what mpt's reasoning would be
<cjwatson> I'm concerned at that sort of declaration since it seems that the result is things looking much worse :)
<ev> agreed
<cjwatson> maybe not a status bar, but could we do something like the spinner you did for the manual partitioner, but in some other bit of blank space?
<cjwatson> I don't know what's consistently available ...
<cjwatson> ikt: replied to your mail
<ev> the space between step X of X and back forward next
<ev> err quit back forward
<ev> that's about it :)
<ev> for what it's worth, this is all in ~ev/ubiquity/progress_indicator
<ev> PyGTK 2.17.0-0ubuntu2 just hit the archive with GtkSpinner
<CIA-6> ubiquity: cjwatson * r3677 ubiquity/ (10 files in 4 dirs):
<CIA-6> ubiquity: Add a context manager (raised_privileges) and a function decorator
<CIA-6> ubiquity: (raise_privileges) that are equivalent to a
<CIA-6> ubiquity: regain_privileges/drop_privileges pair, but that wrap up the required
<CIA-6> ubiquity: try/finally logic to make it less likely that we'll end up at the wrong
<CIA-6> ubiquity: privilege level by mistake.
<ikt> cjwatson: cheers :)
<CIA-6> ubiquity: cjwatson * r3678 ubiquity/ (debian/changelog ubiquity/auto_update.py):
<CIA-6> ubiquity: When attempting to upgrade the installer, only stop debconf-communicator
<CIA-6> ubiquity: once we've determined that we actually have something to upgrade.
<CIA-35> grub-installer: cjwatson * r834 no-device-map/ (debian/changelog grub-installer):
<CIA-35> grub-installer: When installing from non-CD media, we only need to reset the default
<CIA-35> grub-installer: boot device if we would otherwise end up installing GRUB to the
<CIA-35> grub-installer: installation media.
<CIA-35> ubiquity: cjwatson * r3679 ubiquity/debian/ (changelog control): Require Python 2.6, for the 'with' statement.
<CIA-35> grub-installer: cjwatson * r835 no-device-map/debian/changelog: grammar
<CIA-35> ubiquity: cjwatson * r3680 ubiquity/ (6 files in 4 dirs):
<CIA-35> ubiquity: Move default GRUB target calculation to ubiquity.misc, which is a better
<CIA-35> ubiquity: location for common code than ubiquity.components.summary. Try to avoid
<CIA-35> ubiquity: using (hd0) as the target (prefer the first device from grub-mkdevicemap
<CIA-35> ubiquity: output if possible), and, when installing from a non-CD medium, only
<CIA-35> ubiquity: reset the default boot device if we would otherwise end up installing
<CIA-35> ubiquity: GRUB to the installation medium.
<CIA-35> ubiquity: cjwatson * r3681 ubiquity/debian/changelog: LP: #508725 appears to be fixed by debconf-communicator work
<CIA-35> localechooser: cjwatson * r154 ubuntu/debian/changelog: releasing version 2.12ubuntu3
<Lyaa> hya - anyone working on patman-iscsi ?
<Lyaa> partman-iscsi, that is
<CIA-35> ubiquity: cjwatson * r3682 ubiquity/debian/changelog: r3678 fixes LP: #495175
<cjwatson> Lyaa: yes, but more currently I'm working on having dinner.  Please say what the problem is and hang around, and I'll get back to you
<Lyaa> cjwatson: i've managed to launch the Lucid's installer via PXE and installed in iscsi-root (<- it has *really* improved even since Karmic! ;-))
<Lyaa> cjwatson: but the generated /etc/iscsi.initramfs is wrong.. it has $*USERNAME* ans $*PASSWORD* set to "<NULL>" which leads to no avail while initramfs-hook starts logging in that target
<Lyaa> it should be left out completly or at leadt set to =""
<Lyaa> least..
<Lyaa> (then the only thing that's left for me is to find out how to re-order the network module probing in initramfs to get the right eth0-device pointing into the target's direction..grr..)
<cjwatson> Lyaa: hmm.  could I see the installer logs?  /var/log/installer/syslog and /var/log/installer/partman, particularly
<cjwatson> Lyaa: doing something about network probing is on my list, but it won't be by way of module probe order, it'll be by remembering the right network device to use
<cjwatson> Lyaa: I'd like a copy of iscsi.initramfs as well
<dmarkey_> hmm.. is there a reason ubuntu still doesnt support being installed as a domU
<Lyaa> cjwatson: hmm.. about module reordering: i've added now a file "udevrules" below /etc/initramfs-tools/hooks/ that copies over the 70-net-persistent file to initramfs image
<Lyaa> cjwatson: that does the trick ;-)
<Lyaa> cjwatson: so now my nics get (re)numbered according to udev-rules in the running system
<Lyaa> cjwatson: about the log files: any  special sub part of them to nopaste? or complete logs?
<Lyaa> cjwatson: additionaly i do not have any syslog output - i had to kill some processes (i.e sysklogd) due to low ram on that machine (i.e 64MB.. )
<Lyaa> cjwatson: however, i have the partman log
<Lyaa> . o 0 ( hmm .. and i've killed the lines from iscsi.initramfs rather than commenting them.. )
<Lyaa> i guess i'm a louzy bug reporter..
<Lyaa> :)
<cjwatson> Lyaa: you killed sysklogd in the installer?
<cjwatson> Lyaa: the net-persistent stuff should already be copied, if it isn't that's a bug
<Lyaa> cjwatson: ha! .. found the original : http://paste.ubuntu.com/359236/
<cjwatson> hmm.  indeed it isn't.  we should fix that.
<cjwatson> Lyaa: complete logs> always
<Lyaa> btw: kernel cmdline "... blacklist=particular_module..." is not honored either by init-premount/blacklist
<cjwatson> hang on, I can't deal with all this at once :)
<Lyaa> take your time :-)
<cjwatson> Lyaa: can you answer "you killed sysklogd in the installer?"
<Lyaa> cjwatson: right after d-i started with the dialog-menu, i switched to console 2, activetaed the busybox shell, did a "ps" and killed all tasks (i.e syslogd and klogd) to get more ram
<Lyaa> as i said, it's a diskless machine with only 64MB ram ..
<Lyaa> and tht seems to be too low for current d-i
<cjwatson> drat
<Lyaa> additionally i've unloaded some modules that were autoloaded by the installer (like: filesystems that are not used further on (i.e xfs, jfs, ..)
<Lyaa> cjwatson: but with the generated variables in iscsi.initramfs you see from the script local-top/iscsi line 68: "${ISCSI_USERNAME:+-u "$ISCSI_USERNAME"}" that this _will_ fail obviously ;-)
<cjwatson> yeah, I'm looking into that part of it now
<cjwatson> <NULL> there is certainly wrong, it's just a matter of detecting that gracefully
<cjwatson> hoping to avoid a simple string comparison
<Lyaa> is that a string/scalar representation of a null-value?
<cjwatson> looks like I may not have a lot of choice
<cjwatson> apparently so
<cjwatson> I don't see a way to distinguish between a username that's genuinely "<NULL>" and a NULL value.  OTOH "<NULL>" probably isn't allowed by the iSCSI spec anyway so ...
<Lyaa> hmm .. don't try to parse it in the init(ramfs) script but while generating that value ?
<cjwatson> that's what I'm doing.
<Lyaa> no offense :-)
<cjwatson> but the <NULL> text itself is generated inside the kernel.
<cjwatson> so I can't actually intervene there.
<Lyaa> so actually emit some warning during install: "what?!? no password on the target? that's insecure!" - fix your security and set a password" :-)))
<cjwatson> no
<CIA-35> partman-iscsi: cjwatson * r44 ubuntu/ (debian/changelog init.d/iscsi):
<CIA-35> partman-iscsi: Cope with "<NULL>" text in username, password, username_in, and
<CIA-35> partman-iscsi: password_in files.
<cjwatson> ^- that
<CIA-35> partman-iscsi: cjwatson * r45 ubuntu/debian/changelog: releasing version 11
<Lyaa> is that also an issue for backports to 9.10..?
<cjwatson> no, because 9.10 didn't have iSCSI authentication support
<Lyaa> oic
<cjwatson> not that I can effectively change the 9.10 installer anyway
<cjwatson> it is what it was
<Lyaa> so now i still have to dive into initramfs to get early swap on that target - still experiencing OOM there..
<cjwatson> Lyaa: is http://paste.ubuntu.com/359249/ reasonably close to what you used in your initramfs hook?
<Lyaa> . o 0 ( 64MB is not state of the art .. sigh )
<Lyaa> cjwatson: I've copied the original udev from /usr/share/... to /etc/initramfs-tools/hooks/udevrules and adapted like this: http://paste.ubuntu.com/359251/
<cjwatson> I'm hoping that this fixes bug 473036
<ubottu> Launchpad bug 473036 in partman-iscsi "iscsi-root install will only use net0 for iscsi-target connectivity" [Undecided,Incomplete] https://launchpad.net/bugs/473036
<Lyaa> ..but it's been just a quick hack
<cjwatson> near enough equivalent then.
<cjwatson> (except for my inability to spell /etc/udev/rules.d, apparently)
<cjwatson> you're copying to /lib/udev/rules.d/ instead, but udevd should look in both places.
<Lyaa> actually, i've tried to blacklist the other nic-module using /proc/cmdline parsing by blacklist - that failed
<cjwatson> that's outside my area of expertise
<cjwatson> best to file it as an initramfs-tools bug, I think
<Lyaa> but that will obviosly fail if you have two nics using the same driver
<cjwatson> I think I might talk with our udev maintainer about this, rather than going ahead and fixing it right away
<cjwatson> the NFS and NBD paths have essentially the same problem
<cjwatson> and I don't see why 70-persistent-net.rules shouldn't just be universally copied in, really
<Lyaa> yeah - that's mainly because i did now know it initramfs' "udev" is the real udev or some kind of busybox {u,m}dev that only looks in /lib/udev/rules.d/ - it's not FHS, but alas it's the initrd.. who really cares ;-)
<cjwatson> it's the real udev but with a cut-down configuration
<cjwatson> the reduced tools are sometimes more trouble than they're worth
<Lyaa> actually, the devices _should be_ the same order as during install, as they are enumerated by pci-bus-id.. but again i renumbered them during install phase.. ;-)
<cjwatson> this category of problem is what the persistent rules files are for
<Lyaa> Alt-F2, Shell, modprobe -r nic0, modprobe -r nic1; nano /etc/udev/rules.d/70-net-persistent.net.rules and swapped eth0 with eth1, saved, udevadm control --reload; modprobe in order -> swapped names
<cjwatson> eww.  why was that worth it?
<cjwatson> IOW why does the naming matter?
<Lyaa> the machine has two nics - one is on-board.. and that's the (only) one with PXE..
<cjwatson> as long as they're the same from installer through initramfs to running system, it shouldn't matter?
<Lyaa> and it boots from it - altering the name during boot and run mostly leads to even more fuzz..
<cjwatson> I'm confused, and want to understand this
<cjwatson> why does it matter whether eth0 is the PXE one?  PXE-booting should be before Linux assigns names, and independent of it
<Lyaa> the machine detects the on-board first and does not initialize the PCI-card
<cjwatson> sure, but udev will assign it a name that's consistent with what was available in the installer (once this initramfs hook fix is applied, wherever it goes), and with what the installed system expects
<Lyaa> so it does PXE via the on-board, get it's IP and chainloads a gPXE image which does iSCSI .. and you have a INT13 disk whioch loads the boot loader .. that Kernel does ipconfig and initiator again
<cjwatson> it's entirely possible for the first device that's detected to be assigned eth1
<Lyaa> and you know by yourself, it does only probe for iSCI on device "eth0" ;-)
<cjwatson> but that is not true?
<cjwatson> or at any rate it is certainly not supposed to be true!
<cjwatson> it's supposed to try bringing up all interfaces
<Lyaa> and the other nic points in another network which does not reach the iscsi target
<Lyaa> hmm?
<cjwatson> ok, so the problem is not that it only probes eth0, it's that it tries bringing up all interfaces and only tries probing the first in asciibetical order
<cjwatson> thank you, that clarifies things
<Lyaa> it does - but the Kernel bringing the PCI card up as eth0 and tries to get a hold for the Target on that nic
<cjwatson> the kernel does what it's told by userspace, in this regard
<cjwatson> the kernel does not do iSCSI login by itself
<cjwatson> as far as I can see, eth0 is not hardcoded anywhere relevant
<cjwatson> if it is, we should fix that, but I don't believe it is
<Lyaa> right - you may work around this by specifying "ip=all" on Kernel cmdline
<cjwatson> whoa, wait a sec
<cjwatson> OH, I see now
<cjwatson> ./conf/initramfs.conf:65:DEVICE=eth0
<cjwatson> silly thing
<cjwatson> OK, I take it back that it isn't hardcoded
<Lyaa> then ipconfig probes DHCP on all nics - but then booting takes like ages on timeouts when one nic has no link
<cjwatson> so we need partman-iscsi to remember the network device used
<cjwatson> regrettably, I'm not sure I can find this in /sys ...
<Lyaa> hmm .. some "ip route show | grep $TARGET_SUBNET | grep_for_dev"-magic..?
<cjwatson> Lyaa: in the installer, which device did you select at the network configuration stage?  did you select the interface that's to be used for iSCSI?
<cjwatson> the installer normally only brings up one network device, IIRC
<cjwatson> at the moment, I'm thinking of remembering the network device selected in netcfg in ISCSI_NETDEVICE in iscsi.initramfs
<Lyaa> i've selected eth0 in d-i .. but that had been after I altered the device names in udev
<Lyaa> but that should work out
<cody-somerville> grrr... I seem to be causing Ubiquity to crash somehow. :/
<cjwatson> Lyaa: eth0 (pre-renaming) was the right device to use for iscsi, then?
<Lyaa> nah - Kernel, d-i, some userspace, whatever would called that nic "eth1".. so i swapped the name right before entering the "Network configuration" item
<Lyaa> then it had been displayed as "eth0"
<cody-somerville> cjwatson, Does Ubiquity in karmic support creating users with a blank password? UserSetupApply is failing with code 1 and thats the only thing I can think of thats different from another build I have that works fine.
<cjwatson> OK.  So all we need to do is lose that renaming and remember that we should use eth1 at initramfs time.
<Lyaa> cjwatson: think so
<cjwatson> cody-somerville: only if user-setup/allow-password-empty is set to tru
<cjwatson> true
<cody-somerville> cjwatson, I have that. And d-i passwd/user-password{,-again} password
 * cody-somerville takes a peak at ubiquity's source.
<cody-somerville> It looks like I might want to use the ubiquity in karmic-updates before moving forward.
<cjwatson> I'm not convinced ...
<cjwatson> I suggest using ubiquity --debug in the first instance
<cjwatson> getting a full debconf trace is usually the quickest way to attack these problems
<cjwatson> then show the full log
<cjwatson> (/var/log/installer/debug - use a non-valuable password!)
<cody-somerville> /var/log/installer/debug says its failing on UserSetupApply and running it manually I see "No password supplied" repeated three times followed by "chpassword: (user ubuntu) pam_chauthtok() failed, error:\n Authentication token manipulation error.
<cody-somerville> I'll try running ubiquity with --debug
<cjwatson> you don't have any other odd backports of things like shadow or pam, do you?
<cody-somerville> Nope. Just pointing at karmic.
<cjwatson> I'm at a loss just now, then
<cjwatson> I don't see any interesting changes in user-setup
<cody-somerville> To be honest, I think I ran into this issue before but never bothered to look into it and just put in a dummy password instead.
<cjwatson> Lyaa: will you be available for retesting of lucid daily builds at some later point, once we've fixed this?  if you could e-mail me at cjwatson@ubuntu.com, I can get in touch with you
<CIA-35> user-setup: superm1 * r77 user-setup/ (debian/changelog user-setup-apply):
<CIA-35> user-setup: Fix automatic login on situations where custom.conf didn't exist
<CIA-35> user-setup: already on the target.
<CIA-35> user-setup: superm1 * r78 user-setup/debian/changelog: releasing version 1.28ubuntu3
#ubuntu-installer 2010-01-20
<Lyaa> cjwatson: well thanks - keep up the good work! :) off to bed.. ;-)
<CIA-35> user-setup: cjwatson * r212 ubuntu/ (debian/changelog user-setup-apply):
<CIA-35> user-setup: Fix automatic login on situations where custom.conf didn't exist
<CIA-35> user-setup: already on the target.
<CIA-35> user-setup: cjwatson * r213 ubuntu/debian/changelog: releasing version 1.28ubuntu3
<CIA-35> wubi: evand * r511 hardy/ (data/isolist.ini data/settings.nsh debian/changelog): Bump Ubuntu desktop images to 8.04.4
<CIA-35> ubiquity: superm1 * r3683 ubiquity/ (bin/ubiquity debian/changelog):
<CIA-35> ubiquity: Drop old hack for copying ^xserver-xorg onto the target system. No
<CIA-35> ubiquity: longer necessary as thse variables don't exist in current installs.
<ev> nice catch
<ev> michaelforrest: have you had a chance to look at the installer page transition stuff from yesterday?
<michaelforrest> ev: do you have a minute to talk me through it?
<michaelforrest> ev: I'm not sure I understand the rationale behind the changes
<ev> michaelforrest: sure
<ev> michaelforrest: there were two bugs associated with this, both filed by mpt:
<ev> https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/414912
<ubottu> Ubuntu bug 414912 in ubiquity "Poor progress feedback for Back/Forward on slow machine" [Undecided,New]
<ev> https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/336751
<ubottu> Ubuntu bug 336751 in ubiquity ""Starting up the partitioner" uses separate window misleadingly" [Low,Confirmed]
<michaelforrest> ev: I see
<michaelforrest> ev: I think we can certainly improve this visually!
<michaelforrest> ev: the full screen spinner is definitely not the way to go, but I think we can make some minor tweaks to make it a bit less in-your-face
<ev> michaelforrest: great
<ev> what are your thoughts on the spinner on the advanced partitioning page, just to the right of the partition buttons.  Is that okay?
<ev> http://people.canonical.com/~evand/tmp/transitions.html if you lost the link
<michaelforrest> ev I think we should make the other transitions match that style
<michaelforrest> I disagree with mpt's idea to hide everything instantly. greying out maybe, but all it really needs is a spinner like you have in the partitioning page
<ev> right, cjwatson mentioned yesterday the idea of having something of that style on the window for all of the transitions, but we were at a loss of where to put it
<ev> ah, indeed
<michaelforrest> to be honest, I don't think we need much more than a greying out of the Forward button, especially given that the mouse pointer spins
<ev> it already greys out
<ev> so are we already set then :) ?
<michaelforrest> I think a message would relieve the 'disconcertingness' of it
<michaelforrest> (just looking at how it used to work)
<cjwatson> thought: could we put a spinner on one of the buttons?
<michaelforrest> yeah I thought that too
<cjwatson> hmm, don't get a message that way though
<michaelforrest> in case the user is using the keyboard
<cjwatson> we disable the buttons anyway
<michaelforrest> and didn't click the button but pressed enter
<cjwatson> I'm thinking of the case where we're entering the timezone page, when we access the network to sync up the clock; in that case a message is nice since it might take a while
<cjwatson> for ordinary page transitions a spinner on Forward or Back as appropriate might doo the job
<cjwatson> do
<cjwatson> maybe I'm inventing too many alternatives here
<michaelforrest> it's common behaviour on the web for the button to grey out
<michaelforrest> but you'd see the ilttle globe spinning or whatever
<cjwatson> yeah, we do that already
<michaelforrest> but we see the mouse pointer spinning here
<cjwatson> (grey out)
<michaelforrest> I think the bug is invalid, to be honest!
<ev> hooray
<michaelforrest> the important one is not to ever spawn a new window
<cjwatson> right, that's bug 336751
<ubottu> Launchpad bug 336751 in ubiquity ""Starting up the partitioner" uses separate window misleadingly" [Low,Confirmed] https://launchpad.net/bugs/336751
<ev> so do we get rid of the progress dialogs then?
<michaelforrest> we need a consistent location to put this progress stuff, I think
<michaelforrest> I'll get otto to help me with a layout
<cjwatson> the question is how to convey the information in the progress dialogs (or cut-down versions of that information, as appropriate) without dialogs
<ev> right
<michaelforrest> we need to bring the dialogues into the body of the page instead of spawning a new window
<ev> michaelforrest: please keep me in the loop on that layout as this is a work item for me for 9.10
<cjwatson> for bug 414912, my feeling is that we should leave it open until we're in a position to be able to switch to the new page layout immediately
<ubottu> Launchpad bug 414912 in ubiquity "Poor progress feedback for Back/Forward on slow machine" [Undecided,New] https://launchpad.net/bugs/414912
<michaelforrest> I still haven't had a chance to show Mark the work I've done on the installer, but I am in a meeting with him today.
<cjwatson> that's what that bug really is, not dodgy workarounds with progress information :)
<ev> cjwatson: can you expand on that a bit?  I'm not sure I follow.
<cjwatson> on Forward, we finish off the backend work for the current page, start up the backend for the new page, then flip the UI
<cjwatson> hmm, there's some justification for this though
<cjwatson> the reason is that the backend gets to determine whether a page is going to be displayed at all (e.g. automation)
<cjwatson> so maybe this isn't a viable change
<ev> ah, indeed
<cjwatson> so I guess ignore my mutterings. :)
<CIA-35> ubiquity: cjwatson * r3684 ubiquity/.bzrignore: ignore po/*.gmo
<CIA-35> ubiquity: cjwatson * r3685 ubiquity/bin/ubiquity: revert incorrect VERSION change from r3683
<dpm> hi ev1, I'm trying to sort out the xkeyboard-config template in the translations import queue in LP. Has the path of the generated template been changed from po/xkeyboard-config.pot to debian/xkeyboard-config.pot?
<dpm> cjwatson, superm1, we've also got quite a lot of templates of type d-i/source/clock-setup/debian/po/templates.pot, d-i/source/preseed/debian/po/templates.pot, etc. for ubiquity in the imports queue. Are this merged into the main ubiquity template and thus can I safely block them from being imported?
<cjwatson> block 'em
<cjwatson> they're merged into debian-installer
<dpm> cjwatson, ok, blocked, thanks
<cjwatson> ev1: do you know what's going on with bug 488599?  I've seen that in my own tests
<ubottu> Bug 488599 on http://launchpad.net/bugs/488599 is private
 * ev1 looks
<cjwatson> I assume that win_size_req can't work properly until the window is realised or something, but I can't work out the correct fix
<ev1> I haven't noticed it yet.  Hrm, are you able to reproduce this?
<cjwatson> I could yesterday
 * cjwatson fires up another VM, yay for lots of RAM
<cjwatson> BTW, we should do a ubiquity upload at some point today - Scott's autotests are running into the bug Mario fixed in user-setup last night
<ev1> my initial thought is perhaps that callback fires more than once, and we can work around the problem by checking for a gdk window?
<ev1> indeed, will do
<cjwatson> damn.  now I'm not seeing it.  sorry
<ev1> it's okay
<ev1> I'll keep digging and see if I can find a definitive answer as to why that's happening
<cjwatson> I was seeing it literally every run yesterday
<CIA-41> ubiquity: cjwatson * r3686 ubiquity/ (debian/changelog ubiquity/filteredcommand.py):
<CIA-41> ubiquity: Initialise FilteredCommand.ui_loop_level earlier, just in case
<CIA-41> ubiquity: (LP: #484452).
<CIA-41> console-setup: evand * r121 console-setup.ubuntu/ (7 files in 3 dirs):
<CIA-41> console-setup: * Merge support for translated keyboard names from Debian.
<CIA-41> console-setup: * Update ckb/rules/base.xml to point at the new location.
 * ev shakes his fist at Keybuk for not pushing his console-setup changes to trunk
<ev> erm, actually
<ev> cjwatson: are we using lp:ubuntu/console-setup instead of lp:~ubuntu-core-dev/console-setup/ubuntu now?
<cjwatson> not as far as I'm concerned
<ev> okay, good
<cjwatson> I have an outstanding request open with james_w to make them identical, but in the meantime Keybuk is probably just being overly opinionated :)
<saispo> hi all
<ev> lol, always a safe assumption
<saispo> cjwatson: i try to bypass unauthenticated gpg package in preseed but if i have a personnal lsb-release and libldap, i got a red screen, he don't want to install them, it's normal ?
<cjwatson> I don't know
<saispo> ok
<cjwatson> if you want me to debug, I need full logs with DEBCONF_DEBUG=developer
<ev> cjwatson: before I go ahead and fix this with bzr diff -r70..72 | patch -p0 -d ../console-setup.ubuntu, do you know of any way to reconcile this as a proper bzr merge?
<ev> I tried merge -r70..72, but that failed miserably
<michaelforrest> ev: what can I do to see the installer from my normal desktop? I installed the ubiquity package which seemed promising..
<ev> michaelforrest: yeah, I would avoid doing that
<michaelforrest> ev: avoid looking at the installer?
<ev> sorry, avoid running it on your system
<michaelforrest> ev: or avoid installing the ubiquity package?
<michaelforrest> ev: I want to see it with the new theme-in-progress
<michaelforrest> ev: can't I just run it as though I was on a live cd?
<ev> michaelforrest: are you able to run it under a virtual machine?
<michaelforrest> ev: can't I just run it normally? what's the problem?
<michaelforrest> ev: I don't want to be maintaining yet another vm instance, especially since my ubuntu laptop doesn't have a cpu that supports virtualisation
<ev> michaelforrest: you can technically run it normally up to the point where it would start copying files
<michaelforrest> ev: yeah that's all I want to do
<ev> as that depends on files only present on the CD
<michaelforrest> I just want to quickly get a feel for how it looks
<ev> some things will still not work just right (such as getting the release name, as that relies on /.disk/info from the CD)
<michaelforrest> so given that I am prepared for glitches, can I do it?
<ev> sure
<ev> just be careful to not resize a partition and then hit next and confirm the dialog, or get to the summary page and press install.
<michaelforrest> yeah I'm not gonna do that, don't worry ;)
<CIA-41> ubiquity: cjwatson * r3687 ubiquity/ (3 files in 2 dirs): merge lp:~dylanmccall/ubiquity/lp-476269
<michaelforrest> so what do I need to do?
<ev> sure, just covering my bases
<ev> installing ubiquity-frontend-gtk should be enough
<michaelforrest> don't worry - I'm a responsible adult ;)
<cjwatson> ev: I don't think you can do it as a proper merge
<ev> cjwatson: patch it is.  Just wanted to be sure you weren't aware of any black magic.
<cjwatson> ev: only thing I'd suggest is to commit the patches one by one so you can use --author
<michaelforrest> ev:  perfect, thatnks
<ev> ah, will do
<michaelforrest> *thanks
<cjwatson> michaelforrest: the installer *will* change the configuration of your system even before you get to Install
<cjwatson> in particular the keyboard layout stuff
<ev> might want to have a console open with setxkbmap us or something similar
<ev> queued up, that is
<michaelforrest> cjwatson: that's fine. I just want a peak so as long as it's not doing something serious in the background it's fine
<michaelforrest> I've got what I need now anyway.
<michaelforrest> ev: do you think it would be productive for me to look at glade files?
<michaelforrest> ev: (assuming there are glade files for the interface screens)
<CIA-41> ubiquity: cjwatson * r3688 ubiquity/ubiquity/frontend/ (base.py gtk_ui.py): style
<ev> michaelforrest: can you be more specific?
<ev> there are, though some are filled out by the installer at runtime
<ev> the partition pages in particular
<ev> if you have a bzr branch, they're in gui/gtk; otherwise, look in /usr/share/ubiquity/gtk
<michaelforrest> ev: that's okay -I'm more interested in giving some of of the simpler pages a little love
<ev> awesome
<michaelforrest> ev: are they somewhere logical that I could view them in glade?
<ev> michaelforrest: /usr/share/ubiquity/gtk
<michaelforrest> ev: I will understand that there are localisation issues and so on - if you point me to the right repository I shouldn't need to bother you too much :)
<michaelforrest> ah, perfect
<CIA-41> ubiquity: cjwatson * r3689 ubiquity/ubiquity/frontend/kde_ui.py: sync KDE frontend with Dylan's slideshow changes
<ev> ubiquity.ui contains the main window that each step gets added to
<michaelforrest> ev: already there
<michaelforrest> doesn't look like there's much I could do here :(
<ev> each stepPageName.ui file contains the ui specific for that page
<ev> oh?
<michaelforrest> ev: well - not something that wouldn't be easier to achieve with mockups
<ev> gotcha
<robbiew> ev: do you know why Keybuk's daily installer and boot charts have stopped?
<ev> robbiew: there was a bug in user-setup that superm1 has since fixed
<ev> we're going to upload a new ubiquity today to fix it
<robbiew> ev: okay.  I actually don't mind that it broke, was more worried Keybuk's scripts were broken :P
<ev> nope :)
<robbiew> seems that the tool is doing its job then :D
<robbiew> thanks
<cjwatson> he was also having trouble syncing his output to the new people.canonical.com
<cjwatson> and couldn't easily deal with it while on a radically different timezone from most of IS
<ev> indeed, I think we'll be in a much better place with respect to automation of ubiquity than we've been in previous releases
<saispo> cjwatson: i can send you the full debug if you want
<cjwatson> saispo: sure
<saispo> ok, i grab it and where i can send it to you ?
<cjwatson> ubuntu-installer@lists.ubuntu.com
<cjwatson> can't promise to debug everyone's personal customisation problems though.
<saispo> i understand, no problem
<CIA-41> ubiquity: cjwatson * r3690 ubiquity/ (debian/changelog ubiquity/components/ubi-timezone.py): merge lp:~mterry/ubiquity/refresh-timezones
<CIA-41> console-setup: evand * r122 ubuntu/debian/ (changelog console-setup.initramfs-hook rules):
<CIA-41> console-setup: * debian/console-setup.initramfs-hook: There's no harm having the hook
<CIA-41> console-setup:  run in the non-framebuffer case, it just copies things into the
<CIA-41> console-setup:  initramfs which may be useful.
<CIA-41> console-setup: * debian/rules: That means we can copy the hook into scripts/panic as
<CIA-41> console-setup:  well (stripping the OPTION from it), so when we need a shell, we'll
<CIA-41> console-setup:  load the keymap.
<CIA-41> console-setup: evand * r123 console-setup/debian/changelog: releasing version 1.34ubuntu6
<ev> unless there are any objections, I'm going to release a new ubiquity in a few minutes
<saispo> cjwatson: sending, thanks
<saispo> cjwatson: my messages is in hold because the size is over than required
<saispo> it's a problem or you can moderate it ?
<ev> mterry: anything else you want to land?
<ev> ah sorry
<ev> didn't realize that was a merge at first
<mterry> ev, yeah, that patch has been sitting around since karmic released.  I don't have anything recent
<ev> okay cool
<CIA-41> ubiquity: evand * r3691 ubiquity/ (d-i/manifest debian/changelog):
<CIA-41> ubiquity: Automatic update of included source packages: localechooser
<CIA-41> ubiquity: 2.12ubuntu3, user-setup 1.28ubuntu3.
<CIA-41> ubiquity: evand * r3692 ubiquity/debian/changelog: releasing version 2.1.12
<CIA-41> console-setup: evand * r124 console-setup/ (Keyboard/KeyboardNames.pl debian/changelog): releasing version 1.34ubuntu7
<CIA-41> partman-uboot: cjwatson * r8 ubuntu/debian/ (partman-uboot.templates po/templates.pot): fix up .pot file a bit
<CIA-41> partman-uboot: cjwatson * r9 ubuntu/ (4 files in 3 dirs):
<CIA-41> partman-uboot: Use partman-basicfilesystems/mountpoint_manual rather than
<CIA-41> partman-uboot: partman-uboot/mountpoint_manual; there's no need for a different
<CIA-41> partman-uboot: template here, and it saves having to teach ubiquity about the extra one
<CIA-41> partman-uboot: (LP: #462798).
<CIA-41> partman-uboot: cjwatson * r8 2.1/ (commit.d/format_uboot debian/changelog):
<CIA-41> partman-uboot: mkfs.ext2 with -I 128 and not -b 4096 as this is what Marvell recommends
<CIA-41> partman-uboot: to work around a bug in older Uboots.
<CIA-41> partman-uboot: cjwatson * r10 ubuntu/ (commit.d/format_uboot debian/changelog): merge partman-uboot 2.1
<CIA-41> partman-uboot: cjwatson * r11 ubuntu/debian/changelog: releasing version 3
<CIA-41> ubiquity: cjwatson * r3693 ubiquity/ (bin/ubiquity bin/ubiquity-dm debian/changelog):
<CIA-41> ubiquity: Don't crash if something races with ubiquity or ubiquity-dm to create
<CIA-41> ubiquity: /var/log/installer (LP: #458806).
<superm1> what else would be making /var/log/installer?
<cjwatson> two simultaneous runs of ubiquity
<cjwatson> before it acquires the lock
<cjwatson> note that ubiquity-dm creates /var/log/installer, and that's outside ubiquity's main lock
<cjwatson> anyway, didn't seem that interesting to figure out exactly why, I just wanted to get another off the list
<superm1> oh i guess a real world scenario is if someone goes crazy clicking the icon a bunch because it's not opening instantly
<cjwatson> backtrack needs to deal with their own freaking bugs
<cjwatson> ev: have you seen bug 368060?  scary ...
<ubottu> Launchpad bug 368060 in ubiquity "Map of Kashmir when selecting the timezone is incorrect" [Undecided,New] https://launchpad.net/bugs/368060
<cjwatson> ev: bug 337306 may relate to the oem-config troubles you were having
<ubottu> Launchpad bug 337306 in debconf "oem-config task selection doesn't work with debconf-using packages" [Medium,Fix released] https://launchpad.net/bugs/337306
<cjwatson> ev: or maybe just look at how the server frontend does it
<CIA-41> grub-installer: cjwatson * r831 ubuntu/ (debian/changelog grub-installer):
<CIA-41> grub-installer: Don't check for LVM when we've already worked out that we're installing
<CIA-41> grub-installer: on SATA RAID.
<CIA-41> grub-installer: cjwatson * r832 ubuntu/debian/changelog: releasing version 1.49ubuntu2
<ev> cjwatson: thanks for the pointers
<ev> and yeah, yikes
<ev> cjwatson: shall I ask Ken to mock up something else?
<ev> not sure how else to represent it given that the time zone ends at that border.  We could just remove Kashmir, but I imagine that would make people just as angry.
<cjwatson> ev: I'm not sure - I haven't looked at it in detail
<cjwatson> ev: IIRC other implementations fuzz the line around there somehow
<ev> good call, I'll see what others do here
<superm1> cjwatson, how would you feel about something like this: http://pastebin.com/f76a9d3e1  ?  I think that would allow multiple files to be preseeded (as additional arguments)
<cjwatson> superm1: looks good to me except that it flips the override order of variables specified on the command line vs. those in files
<cjwatson> superm1: I think I'd recommend keeping the list of locations and processing them all at the end, to avoid inadvertently breaking some weird case or other
<superm1> cjwatson, okay, i'll flip that around.  i think either way, the order will suddenly matter at least for stacked preseed files
<superm1> not much of a way to avoid that
<cjwatson> I don't think that's true, this script isn't recursive
<cjwatson> just processing them all at the end would keep the same ordering semantics but permit specifying any or all of preseed/file= file= url=
<superm1> well i mean if multiple preseed files are specifying the same key, then it's entirely possible that the order they were specified on the command line will determine which one's setting of that key would take effect since they would still be individually loaded in via debconf-set-selections
<cjwatson> certainly
<cjwatson> but that's OK, I think
<superm1> Ok.
<superm1> in trying to get dmraid sorted out, i think this is gonna be necessary for our implementation of it
<cjwatson> I don't mind new handling being a bit odd, I just don't want to perturb existing handling
<superm1> Ok
<ev> has anyone actually been able to get the kubuntu lucid images to work in kvm?
<ev> ah, my bad
<ev> -vga std, in case anyone else runs into it
<dmarkey_> is it possible to disable ext4 in the installer
<dmarkey_> using preseed, etc
<smagoun> dmarkey_: 'd-i partman/default_filesystem string ext3' should set the filesystem to ext3
<dmarkey_> thats excellent, thanks
<CIA-41> casper: superm1 * r734 casper/ (debian/changelog scripts/casper-bottom/24preseed):
<CIA-41> casper: Support multiple preseed file/urlarguments on the kernel commandline
<CIA-41> casper: rather than just selecting the last one and going with that.
<dmarkey_> smagoun: how about force grub1?
<smagoun> dmarkey_: d-i grub-installer/grub2_instead_of_grub_legacy boolean false
<dmarkey_> are these documented anywhere
<cjwatson> but please tell us why you don't want grub2 (in a bug report) so that we can fix whatever it is.
<smagoun> dmarkey_: you mean besides the source? :) I am not sure
<cjwatson> the first is documented in the installation guide
<CIA-41> casper: superm1 * r735 casper/debian/ (changelog control): debian/control: Set Vcs-Bzr.
<cjwatson> the second isn't documented at the moment AFAICS
<dmarkey_> cjwatson: this is for a xen domu, pygrub doesnt support grub2 yet
<dmarkey_> not an ubuntu bug as such
<cjwatson> superm1: please use lp:ubuntu/casper not lp:casper, as discussed on #ubuntu-devel 2010-01-05
<cjwatson> dmarkey_: ok
<superm1> cjwatson, lol.  here i thought this one was right.  okay i'll push  there
<cjwatson> 16:51 <cjwatson> superm1,pitti,ev: please note for future commits that casper is in lp:ubuntu/casper now rather than lp:caspper
<dmarkey_> cjwatson: i think i was talking to you about a year ago about getting the ubuntu installer to work proberly under xen paravirt
<CIA-41> ubiquity: evand * r3694 ubiquity/ (6 files in 4 dirs): Support the new translated keyboard names in console-setup.
<cjwatson> dmarkey_: might have been - I'm afraid it hasn't been much of a priority for me to improve
<dmarkey_> but its so close
<dmarkey_> all it needs is the xen modules included
<cjwatson> "all"
<cjwatson> that needs a consistently maintained Xen kernel ...
<CIA-41> casper: superm1 * r745 casper/ (debian/changelog scripts/casper-bottom/24preseed):
<CIA-41> casper: Support multiple preseed file/urlarguments on the kernel commandline
<CIA-41> casper: rather than just selecting the last one and going with that.
<dmarkey_> nope
<dmarkey_> it doesnt need any seperate kernel
<CIA-41> ubiquity: evand * r3695 ubiquity/debian/changelog: LP bug reference for previous commit.
<CIA-41> casper: superm1 * r746 casper/debian/ (changelog control): debian/control: Set Vcs-Bzr.
<cjwatson> dmarkey_: do you mean xen-blkfront, xen-netfront, and netxen-nic?
<dmarkey_> yup
<dmarkey_> not sure about the 3rd, but the 1st 2 anyway
<cjwatson> neither xen-blkfront nor xen-netfront appears to be available in the lucid generic kernel
<dmarkey_> 64bit?
<cjwatson> i386
<dmarkey_> well they are in the vanilla kernel since .22
<dmarkey_> i think i seen this before, try 64bit, i bet they are there
<cjwatson> sure, but I'd rather keep d-i consistent.  why aren't they in the i386 generic build?
<cjwatson> the config for those appears to be common
<dmarkey_> im not sure
<cjwatson> config XEN
<cjwatson>         depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
<cjwatson>         depends on X86_CMPXCHG && X86_TSC
<cjwatson> maybe that's it
<dmarkey_> oh, PAE only?
<cjwatson> well, if it's 64-bit only, so be it; it would require a change to our kernel packaging to add those modules to the appropriate udebs
<dmarkey_> what are udebs
<cjwatson> (d-i's i386 build comes from -generic not -generic-pae, it doesn't get to use PAE bits; and in any case those modules don't seem to be in our -generic-pae build either)
<cjwatson> google please!
<cjwatson> anyway, file a bug against the 'linux' package in Ubuntu asking for those to be added
<cjwatson> refer them to me for the details if you like
<dmarkey_> oh, i'll do it tomorrow, bed time for me now
<cjwatson> from the arrangement in Debian, xen-blkfront goes in scsi-modules, xen-netfront in nic-modules, and netxen_nic in nic-extra-modules
<dmarkey_> thanks!
<dmarkey_> i see
<dmarkey_> would i include all this in the bug?
<cjwatson> netxen_nic is already in there
<cjwatson> yes
<dmarkey_> NetXen Multi port (1/10) Gigabit Network Driver
<dmarkey_> thats unrelated
<cjwatson> ok, skip that then
<dmarkey_> cool, talk tomorrow, thanks!
#ubuntu-installer 2010-01-21
<ev> argh, forgot that xkb-data-i18n hadn't been promoted yet
<cjwatson> ev: *clicketyclick* fixed for the next publisher run
<CIA-41> ubiquity: superm1 * r3696 ubiquity/ (scripts/install.py ubiquity/frontend/gtk_ui.py): whitespace cleanup
<CIA-41> ubiquity: superm1 * r3697 ubiquity/ (debian/changelog scripts/install.py): Remove another reference to a long dead xserver-xorg debconf question.
<CIA-41> ubiquity: superm1 * r3698 ubiquity/ (debian/changelog scripts/install.py): Don't try reconfiguring LRM, it's been superceded by DKMS based packages.
<CIA-41> ubiquity: evand * r3699 ubiquity/ (10 files in 6 dirs): Provide an option to determine the keymap from a decision tree.
<CIA-41> ubiquity: evand * r3700 ubiquity/ (5 files in 3 dirs):
<CIA-41> ubiquity: * Add missing parameter to exception in bin/ubiquity.
<CIA-41> ubiquity: * slideshow_get_available_locale is an instance method.
<ev> note to self, run pychecker before upload
<ev> ugh
<CIA-41> ubiquity: evand * r3701 ubiquity/scripts/install.py: [pychecker] Remove unused exception parameter.
<ev> cjwatson: have you run into issues with bogl-bterm and kvm?  It throws a GPF for me in karmic and lucid.
<cjwatson> haven't noticed it being *that* bad
<cjwatson> terminfo seems a bit misconfigured in d-i rescue mode, it's doing something wrong with backspace, but that could be the shell's fault
<ev> weird
<ev> by the way, there's a bug in debconf_ui, introduced by r3665.  self.db will always exist.  I think the solution is to get rid of the check in debconf_ui.debconf_communicator, but you might want to double check that, just to make sure I'm not railroading over a case that you had considered and I had not.
<cjwatson> hmm, I'd missed that
<cjwatson> I'm not sure removing the check is right though
<cjwatson> ignore that.  you're quite right, ditch the check
<cjwatson> you mean the hasattr bit?
<ev> yes
<cjwatson> hmm
<cjwatson> I think maybe we need to save the persistent d-c somewhere else
<ev> what about hasattr(self, 'db') and self.db is not None?
<cjwatson> the intended behaviour is:
<cjwatson>  * if DEBIAN_HAS_FRONTEND, only ever instantiate self.db once, and on subsequent debconf_communicator calls just return the previous one
<cjwatson>  * otherwise, as normal
<cjwatson> WDYT about http://paste.ubuntu.com/360085/ ?
<cjwatson> or indeed the hasattr check might just be irrelevant since debconf_communicator should only ever be called if self.db is None, but I suppose it's a safety check
<ev> it will never hit, as BaseFrontend gets instantiated first
<ev> which sets self.db = None
<cjwatson> ev: ah; then my patch combined with yours
<cjwatson> or indeed just 'if self.db is not None'
<cjwatson> http://paste.ubuntu.com/360089/
<ev> ah, good call
<CIA-41> ubiquity: evand * r3702 ubiquity/ (debian/changelog ubiquity/frontend/debconf_ui.py):
<CIA-41> ubiquity: The frontend always has a db attribute, per r3665, so revise the check in
<CIA-41> ubiquity: debconf_communicator. Thanks Colin Watson.
<CIA-41> ubiquity: evand * r3703 ubiquity/ (debian/changelog ubiquity/components/install.py): Add missing function argument to Install's prepare.
<superm1> ev, would you mind glancing over https://edge.launchpad.net/~superm1/ubiquity/mythbuntu-plugin-enhance r 3687, 3689 and 3690 to make sure those aren't doing anything to crackful before I continue wandering down that road?  I'm trying to convert as much of the deviations in mythbuntu_ui that are overriding functions (both in gtk_ui and install.py) directly into plugins and coming across some deficiencies
<ev> superm1: absolutely.  I'm knee deep in debconf_ui at the moment, but I'll try to find time for it later tonight.  If not tonight, definitely tomorrow.
<superm1> cool thanks, i won't be touching again until after work anyhow
<dmarkey> is there a way to get the LVM partitioner to put the boot partition on partition 1?
<superm1> note; if things look good, don't merge though - it's in an iffy state, i just want to make sure those particulars are good before i make the other bigger changes to mythbuntu_install.py
<ev> surely
<CIA-41> ubiquity: evand * r3704 ubiquity/debian/changelog: LP bug reference.
<ev> cjwatson: Just a heads up, debconf_ui is broken, with the bug surfacing in scripts/install.py.  It seems debconf doesn't like REGION in this context.  I'm looking into it (as I try to gather what I can for packages with debconf support in gtk oem-config), but I'm a bit out of my depth, so it might be a while.
<cjwatson> ev: if PROGRESS REGION is leaking through to debconf, that's the bug; it's supposed to be handled by the filter.  We probably shouldn't be running install.py unfiltered
<CIA-41> usb-creator: superm1 * r258 usb-creator/ (debian/changelog usbcreator/frontends/gtk/frontend.py):
<CIA-41> usb-creator: If hiding the persistence and iso selection in the UI, make sure to do
<CIA-41> usb-creator: so before window.show() to prevent weird sizing of the window
<CIA-41> usb-creator: superm1 * r259 usb-creator/usbcreator/frontends/gtk/frontend.py: Leave backend.detect_devices where it was, in case it depended on those previous signal handlers
<StevenK> cjwatson: Shall I update d-i for -11, or you'll take care of it?
<cjwatson> StevenK: if you have time, please go ahead
<StevenK> cjwatson: Uploaded, thanks.
#ubuntu-installer 2010-01-22
<ev> heads up - releasing a new ubiquity to take care of the slideshow variable issue
<CIA-41> ubiquity: evand * r3705 ubiquity/ (d-i/manifest debian/changelog):
<CIA-41> ubiquity: Automatic update of included source packages: console-setup
<CIA-41> ubiquity: 1.34ubuntu7, grub-installer 1.49ubuntu2, partman-uboot 3.
<CIA-41> ubiquity: evand * r3706 ubiquity/bin/ubiquity-dm: Found another missing exception parameter.
<CIA-41> ubiquity: evand * r3707 ubiquity/debian/changelog: releasing version 2.1.13
<davmor2> cjwatson: is today a good day to look at that grub issue in hardy, although I need to take the MIL off to hospital in a bit so it won't be till after that
<davmor2> cjwatson: Bug 185878
<ubottu> Launchpad bug 185878 in grub "GRUB installation fails if installing to certain non-ext3 filesystems" [High,Fix committed] https://launchpad.net/bugs/185878
<cjwatson> davmor2: hope so but I'm not sure yet
<CIA-41> ubiquity: evand * r3708 ubiquity/debian/ (changelog control): Add missing build dependency on keymapper.
<davmor2> cjwatson: as I say it won't be till later any how I'll give you a shout when I get back :)
<CIA-41> ubiquity: evand * r3709 ubiquity/d-i/update-control: Put keymapper build dependency in the right place.
<ev> superm1: I'm not sure I understand the motivation for splitting out install_misc, given that the only place it's used is in the Install subclass.
<CIA-41> ubiquity: evand * r3710 ubiquity/debian/changelog: releasing version 2.1.14
<dmarkey> sorry for repeating myself, but is there a way to get the LVM partitioner to place /boot on the first partition
<cjwatson> probably not automatically
<cjwatson> I'm sure you can do it using the manual partitioner
<cjwatson> or using a custom recipe
<dmarkey> ok, well in that case can i disable the lvm partitioner
<cjwatson> sure, please see the installation guide
<cjwatson> why does it matter which partition /boot is on?
<dmarkey> ah, xen specific issue, pygrub can only read menu.lst off the 1st partition
<cjwatson> you could take the default recipe and edit it to add $primary{ } to the /boot stanza
<cjwatson> I think that would do it
<cjwatson> looks like the reason it isn't the first partition is that the LVM envelope is always set as primary (which is probably a bug in itself) and thus /boot doesn't need to be as far as partman-auto is concerned
<dmarkey> cool, i'll do some research, is https://help.ubuntu.com/9.10/installation-guide/i386/preseed-contents.html my best reference?
<cjwatson> yes
<neriberto> hi people
<cjwatson> dmarkey: I've changed partman-auto-lvm upstream to not enforce that the LVM envelope is primary
<neriberto> someone can help me?
<cjwatson> neriberto: see the topic - "don't ask to ask, just ask"
<neriberto> i've been download a ISO of source...how can I rebuild this?
<dmarkey> cjwatson: cool, so the plhsical volume will be sda5?
<dmarkey> physical*
<cjwatson> neriberto: could you please ask on #ubuntu?  none of our usual installation methods work this way so it doesn't really make sense on this channel
<cjwatson> dmarkey: should be.  dunno if this will be in lucid though
<dmarkey> cjwatson: sorry for being a pain, but where would i get the default recipe
<neriberto> cjwatson but i am talking about ubuntu-server install
<neriberto> from source
<cjwatson> neriberto: the supported way to install ubuntu-server is from binaries
<cjwatson> we aren't Gentoo :)
<cjwatson> dmarkey: it's in the partman-auto source package, recipes/atomic
<neriberto> tks
<dmarkey> so i add $primary{ } and put the whole lot into: d-i partman-auto/expert_recipe?
<davmor2> cjwatson: right I'm back
<dmarkey> or is there partman-auto/atomic_recipe
<cjwatson> dmarkey: it's in the installation guide
<cjwatson> davmor2: I think I'm going to have to reproduce this before I'm able to comment
<davmor2> cjwatson: Ah okay in that case I'll get on with some desktop testing just give me a ping if you find a cure :)
<cjwatson> which gets back to the "my laptop's hard disk is too small" problem.  aargh.
<cjwatson> roll on May ...
<dmarkey> cjwatson: doesnt seem to be having an affect
<cjwatson> ok, I'm not sure then, sorry
<dmarkey> cool, thanks
<davmor2> cjwatson: can you not just buy a bigger harddrive?
<cjwatson> dmarkey: feel free to file a bug / send a mail or something with full logs; best if the installation in question was booted with DEBCONF_DEBUG=developer
<cjwatson> davmor2: I suck at hardware maintenance, don't make me do more of it ;-)
<cjwatson> I'll get a new laptop in May on our hardware refresh programme, so I'll just make sure it has an enormous disk
<ev> NAS + NFS for the win
<davmor2> ev: samba share here
<cjwatson> ev: yeah, I sort of use that for some things
<cjwatson> I may start using it a bit more, but it does mean that I'm restricted when working remotely
<ev> I just copy a few images and CDs over for that case
<ev> but it means that I don't have to worry about deleting daily-live CDs, or where I'm going to put yet another image.
<ev> copy over to my laptop, that is
<cjwatson> yeah.  I do have more disk than I can conveniently contemplate using on my fileserver.
<ev> heh
<cjwatson> as in I haven't even allocated half of it to LVs yet
<cjwatson> need to renumber UIDs on my fileserver to make NFS really convenient, though :-(
<dmarkey> cjwatson: you could use nfsv4
<cjwatson> yeah, I probably could
<cjwatson> should look into that in fact, thanks
 * ev bangs his head against the proverbial wall; this debconf_ui stuff is proving to be difficult to understand.
<ev> cjwatson: is there a simple answer to why debconf_ui needs to run under a debconf frontend?  Also, am I barking up the wrong tree here, given that it doesn't seem to make use of the passthrough frontend.
<ev> if you're busy, no worries.
<cjwatson> ev: debconf-communicate isn't up to the task of providing a UI - you need a proper debconf frontend for that
<cjwatson> and debconf_ui's purpose is to just let debconf do all the UI stuff
<ev> ah, duh, right
<cjwatson> ev: you may be barking up the wrong tree, I guess - remind me what you're trying to do?
<ev> work around the fact that the debconf database is locked when I'm trying to install packages in do_install
<ev> (in oem-config)
<cjwatson> ah, yeah, you don't want debconf_ui for this
<cjwatson> I think you should involve debconf-apt-progress somehow
<ev> yeah, I was looking at that as well
<cjwatson> there's an example in the man page that you should be able to adapt
<cjwatson> the reason oem-config gets away with it is that it uses tasksel to install packages, which in turn uses debconf-apt-progress
<ev> ah
<cjwatson> but I don't think you should need to use tasksel necessarilty
<cjwatson> -t
<ev> cool, thanks for the pointers, and sorry for this taking so long for me to wrap my ahead around.
<ev> just to clarify, this isn't to get debconf PROGRESS commands, but to be able to install packages to ask questions (postfix, in my test case).  I suspect this will require more than involving debconf-apt-progress as is, correct?
<ev> err that call INPUT
<cjwatson> no, that should be OK, debconf-apt-progress also shunts other debconf commands through passthrough
<cjwatson> that's how packages get to ask questions during pkgsel in d-i
<ev> cool, thanks
<ev> awesome, I think I'm definitely on the right track now
<ev> thanks a million, cjwatson
<cjwatson> yw
<dmarkey> cjwatson: it does work, pebkac
<dmarkey> i was missing "$"
<dmarkey> :(
<CIA-41> partman-iscsi: cjwatson * r46 ubuntu/ (debian/changelog finish.d/iscsi_settings):
<CIA-41> partman-iscsi: Remember the default network interface and record it in ISCSI_NETDEVICE
<CIA-41> partman-iscsi: in iscsi.initramfs (LP: #473036).
<CIA-41> partman-iscsi: cjwatson * r47 ubuntu/debian/changelog: releasing version 12
<CIA-41> grub-installer: cjwatson * r833 ubuntu/ (debian/changelog grub-installer):
<CIA-41> grub-installer: Add $partition_offset to $bootpart when deciding which partition to make
<CIA-41> grub-installer: active based on GRUB-style device names (found while testing fix for LP
<CIA-41> grub-installer: #185878).
<superm1> ev, it's because it can then be usable in other plugins.  each of those functions are currently used in some fashion in mythbuntu_install.py
<superm1> ev, i figured this is the easiest way to get them access to them without code duplication
<ev> But where are they or would be used that's not already a subclass of Install and can thus access them already?  Mind you, I'm not criticizing the approach, just trying to understand the rationale.
<ev> superm1: ^
#ubuntu-installer 2010-01-23
<CIA-41> ubiquity: superm1 * r3711 ubiquity/ (4 files in 3 dirs):
<CIA-41> ubiquity: Add a new template, ubiquity/only-show-installable-languages for modifying
<CIA-41> ubiquity: the behavior of what languages to offer on an invokation based upon
<CIA-41> ubiquity: what's installed or "available" to install according to an apt cache.
<superm1> ev, well plugins aren't subclasses of Install (although maybe that's a better way to do it)
<superm1> er no that probably wouldn't work right;  you need access to the direct instance of db and target used by Install
<superm1> i'm open to other approaches though, this was the one that seemed logical to me
<CIA-41> ubiquity: superm1 * r3712 ubiquity/scripts/install.py: whitespace
<bikcmp> I tried wubi, and on reboot I get a screen saying grub:sh or something.  I have a HP mini 110 and Windows XP SP3
<ev> bikcmp: was this after updating?
#ubuntu-installer 2010-01-24
<ev> and now we'll never know
<ubuntu_> I used the usb-creator to make a livecd USB stick. When it boots, USB stick is mounted as /cdrom with permissions 755. I can't seem to change it to 777. Could this be because of the mounted fmask=0022 and dmask=0022? If so, how do I change that?
<BobPaul> It is mouted as rw and I can write to /cdrom when root, but I'd be nice to have write access as the user, since this is where most files I'd be using will be located
<Thwapp> hello everyone..
<Thwapp> I'm hoping there's someone online who may be able to help me figure out a Ubuntu 9.10 installation issue with my desktop PC.
<Thwapp> is there a way to install Ubuntu with a minimal cd or USB drive that downloads all the packages off the internet?  I'd prefer to run 64 bit on my desktop, 32 bit on my notebook,and by some miracle, I managed to get the Netbook remix installed onto my MSI Wind U100-257ca (upgraded to 2gb ram and a 500 gb hd...)  Both my desktop (EVGA 780i SLI MB based) and my notebook (Acer Aspire intel core 2 duo based) have crashed on install..
<persia> !netbook
<persia> Err,
<persia> !netboot
<ubottu> Ubuntu can be installed in lots of ways. Please see https://help.ubuntu.com/community/Installation for documentation. Problems during install? See https://wiki.ubuntu.com/CommonProblemsInstall - Don't want to use a CD? See http://tinyurl.com/3exghs - See also !automate
<persia> Thwapp: Try reading about netboot installs in the install documentation.  You may find this matches your original request, although be warned it's less simple than the other methods.
<Thwapp> persia: I've read through the netboot documentation seems to expect me to have GRUB installed..  which I don't because I can't get the initial installation to go past 22%.  I have 3 versions downloaded..  the 64 bit one (what I wanted to experiment with on my desktop), the 32 bit one (that I figured would be a good experiment on my notebook - the afore mentioned notebook), and the netbook remix (which I managed to successfully inst
<persia> Hrm.  I'm not sure about that then.
<persia> netboot is the only way I know to download packages at install time, rather than preinstall time.
<Thwapp> it keeps claiming an I/O error...
<Thwapp> I've burned prolly 4 or 5 copies of both the x64 and the x86 versions..  get the same issue...
<Thwapp> when I built the desktop, I made sure it was 64 bit capable..  used an em64t cpu, got a solid Mobo for it..
<Thwapp> made sure I have solid, error free ram...
<Thwapp> This isn't  the first time I've ever installed Linux before, nor is it the first time I've ever installed Ubuntu either, however it is the first time I've ever installed Ubuntu on my desktop....
<Thwapp> I have read the documentation on installs, and until I came in here and got the pointer to the page about install difficulties, I hadn't found that one yet..  So I've read it...  All the netboot installs seem to want GRUB installed.  I know how to USE Grub to boot an OS, but I don't know how to Install it yet.  not on it's own, not at all..  if it's part of an install, that's usually not too bad...
<persia> Hrm.  You're sure about your optical drive?
<Thwapp> I have 2 of them...
<Thwapp> both IDE..  and both working just fine in Windoze..
<persia> Hrm.  I'm not sure.
<Thwapp> on my netbook, I have an external Samsung USB slimline DVD burner...  I even tried to boot it off that one!!
<persia> THis channel tends to be quiet on the weekends though.  Have you talked to the folk in #ubuntu about installation?
<Thwapp> actually, no..  that's a good idea...
<Thwapp> I shall take a peek in there shortly!!  thanks!!
<Thwapp> And thanks for your time!  I do appreciate it!!
<persia> Good luck.
<dhillon-v10> cjwatson: can you have a look here: https://bugs.launchpad.net/ubuntu/+source/grub/+bug/215972 possible to close that bug because GRUB doesn't make the menu.lst file anymore
<ubottu> Ubuntu bug 215972 in grub "Grub writes a faulty menu.lst" [Undecided,New]
#ubuntu-installer 2011-01-17
<ralph> Unless I hear different I'll try and raise a bug on the installation guide;  it seems now /dev/sda is the norm only 11 logical partitions are possible.  Please speak up if you think I've got that wrong.
<cjwatson> ralph: there is no intent to impose a maximum partition number beyond that imposed by the kernel, which is much higher than you state.  Any limit is a bug, not something we should enshrine in the installation guide.
<cjwatson> ralph: oh, wait, I'm evidently misremembering and the /dev/sd* limit is indeed 16.  Yes, I suppose that should be documented in the installation guide.
<tjaalton> cjwatson: do you have installer images for lucid built using the backported kernel from 10.10?
<tjaalton> I probably asked about this earlier, but can't remember if they exist
<cjwatson> not yet
<tjaalton> ok. I realise it's just not a simple rebuild ;)
<CIA-4> ubiquity: evand * r4479 trunk/debian/changelog: No change rebuild for new libindicator2.
<CIA-4> ubiquity: evand * r4480 trunk/debian/changelog: releasing version 2.5.10
#ubuntu-installer 2011-01-18
<Isaac-M> cjwatson: Are you online?
<Isaac-M> Is ANYONE online?
 * cjwatson feeds a giant pile of new code imports to Launchpad, now that d-i has converted to git
<cjwatson> will have to spend some quality time with bzr rebase-foreign to convert all our branch history :-/
<ev> yikes
<cjwatson> well, I knew it was coming
<ara> cjwatson, hello
<cjwatson> hi
<ara> cjwatson, from the discussion on the interlock on Friday, I think that we agreed that the first build of 10.04.2 that we can consider candidate will be the build of the 28th Jan
<ara> is that correct?
<cjwatson> that sounds plausible ...
<cjwatson> I don't have notes of the meeting nor a terribly accurate memory; skaet probably does
<ara> cjwatson, cool, thanks. I will double check with her
<cjwatson> so, for the record, I'm using 'bzr rebase-foreign' with lp:~cjwatson/bzr-rewrite/rebase-foreign-merges, lp:~cjwatson/bzr-rewrite/skip-empty-directories, and lp:~cjwatson/bzr-rewrite/merge-file-ids applied on top of the packaged bzr-rewrite in natty
<cjwatson> NOT AT ALL COMPLICATED
<cjwatson> oh, and a local plugin to handle feeding in the right old/new id lists
<cjwatson> maybe I should optionify that while I'm here ...
<ralph> cjwatson: Bug opened.  Thanks for the confirmation.   https://bugs.launchpad.net/ubuntu/+source/installation-guide/+bug/704412
<ubot2> Launchpad bug 704412 in installation-guide (Ubuntu) "/dev/sda has 15 partition hard limit, not 20+ (affects: 1) (heat: 6)" [Undecided,New]
<ralph> (I mean the confirmation on the channel above, not in the bug.)
<cjwatson> I've poked the bug now as well, so confused triagers won't have at it
<cjwatson> anna rebased.  now for the remaining six zillion
<cjwatson> http://paste.ubuntu.com/555386/ - my exceedingly hacky ~/.bazaar/plugins/scratch_import/__init__.py
<soren> What's it like to be so awesome?
<soren> I've always wondered.
<cjwatson> tiring
<soren> I suppose I can see how that works.
<cjwatson> this procedure is complicated by the fact that the d-i git import glued together cvs history from before the svn conversion with svn history
<cjwatson> oh, actually that's not true, it just did a better job of converting across renames than launchpad di
<cjwatson> d
<cjwatson> either way, it means we magically have more history in bzr than we used to have, but it also means that I can't just noninteractively pair up the old and new ids
<cjwatson> and of course every svn commit that only changes svn:ignores and nothing else vanishes from the git history but was (dubiously) in the bzr history
<cjwatson> grr, http://bazaar.launchpad.net/~ubuntu-core-dev/apt-setup/ubuntu/revision/199 is going to be painful to deal with
<cjwatson> file removed then added a few revisions apart upstream; svn->bzr import had different file-ids for each, git->bzr import has the same file-id
 * cjwatson 's head is gently exploding
<cjwatson> I might have to manually edit history for this one :-(
<cjwatson> since the effective situation is that apt-setup/ubuntu r199 has two files with the same file-id, one of which was then cleaned up in r200
<cjwatson> done up to console-setup (though going back and unbreaking the public anna and apt-setup branches at the moment); probably more or less finished with rebasing for the day
<CIA-47> anna: cjwatson * r833 ubuntu/debian/ (po/lo.po po/si.po changelog po/se.po): merge from Debian 1.39
<cjwatson> ^- merge from d-i git
<CIA-47> anna: cjwatson * r834 ubuntu/debian/changelog: releasing version 1.39ubuntu1
<cody-somerville> cjwatson, whats the story with clicfs? Is that what Suse uses?
<CIA-47> partman-partitioning: superm1 * r732 partman-partitioning/ (debian/changelog lib/disk-label.sh):
<CIA-47> partman-partitioning: Support archdetect being anywhere in PATH rather than assuming it to be in
<CIA-47> partman-partitioning: /bin. It's moved locations in archdetect-deb.
<CIA-47> partman-partitioning: superm1 * r733 partman-partitioning/debian/changelog: releasing version 78ubuntu2
<CIA-47> ubiquity: superm1 * r4481 ubiquity/ (d-i/manifest debian/changelog):
<CIA-47> ubiquity: Automatic update of included source packages: partman-partitioning
<CIA-47> ubiquity: 78ubuntu2.
<CIA-47> ubiquity: superm1 * r4482 ubiquity/debian/changelog: releasing version 2.5.11
<cjwatson> cody-somerville: no idea, I vaguely remember we looked at it once and I think it didn't rsync well.  as far as what it actually is, google knows about as much as I do.
#ubuntu-installer 2011-01-19
<CIA-47> debian-installer: cjwatson * r1311 lucid-proposed/ (14 files in 5 dirs):
<CIA-47> debian-installer: Build images with the lts-backport-maverick kernel (2.6.35-23), which
<CIA-47> debian-installer: are themselves configured to install the lts-backport-maverick kernel
<CIA-47> debian-installer: (LP: #607657).
<CIA-47> debian-installer: cjwatson * r1312 lucid-proposed/debian/changelog: clarify that lts-backport-maverick images are only available for amd64 and i386
<CIA-47> debian-installer: cjwatson * r1313 lucid-proposed/ (8 files in 2 dirs): Move to 2.6.32-28 kernels.
<CIA-47> debian-installer: cjwatson * r1314 lucid-proposed/debian/changelog: releasing version 20081029ubuntu102.7
<cjwatson> ev: I've managed to find time to look at bug 591207 again, BTW, so you can disregard that mail of mine if you like
<ubot2> Launchpad bug 591207 in casper (Ubuntu Lucid) (and 1 other project) "Casper's USB update-initramfs shim should look for initrd.img in /boot (affects: 4) (dups: 2) (heat: 46)" [High,Confirmed] https://launchpad.net/bugs/591207
<ev> cjwatson: oh, wow, thanks a bunch
<ev> hadn't we fixed that elsewhere, or was it just my failure to backport it?
<ev> r853, no?
<ev> ah no, I'm looking at the wrong thing entirely.  Sorry
<ev> yay! I think the test farm stumbled on a bug: http://paste.ubuntu.com/555886/
<ev> I'll have to take a closer look tomorrow
<ev> I've got it pulling in the logs as artifacts of the test
#ubuntu-installer 2011-01-20
<svdasein> I'm having a bit of trouble getting 10.04's installer working right with the  serial console on my soekris board here.  Anyone here have any experience w/ that and/or can recommend another group?
<ara> hello!
<ara> I am trying to install ubuntu server (natty daily) in some servers with preseed, but in most of the systems it is stuck because it asks for a partition table to use
<ara> could it be that the prior installation (also natty) corrupted the partition table somehow?
<ara> this is the preseed file that I am using: http://paste.ubuntu.com/556098/
<Jemt> Not sure this is the place to ask, but this channel seems to be the best place to find technical assistance.
<Jemt> I'm remastering Ubuntu. One of my very last steps before creating my new ISO, is upgrading all packages (apt-get upgrade). Unfortunately this results in a lot of errors/warnings from dpkg: "dpkg: error processing gconf2-common (--configure): dependency problems - leaving unconfigured". Another common error is this: "dpkg: dependency problems prevent configuration of compiz-gnome: compiz-gnome depdends on libgconf2-4 (>= 2.31.1); however:
<Jemt> package libgconf2-4 is not configured yet". Are these just warnings, or actual errors which may render my remastered edition of Ubuntu buggy ?
<cjwatson> ara: I'll need to see logs
<cjwatson> Jemt: they're actual errors (unless they got cleaned up later - see whether 'dpkg --configure -a' still produces errors).  are you sure you should be using 'apt-get upgrade' rather than 'apt-get dist-upgrade'?
<ara> cjwatson, let me get them for you, thanks
<Jemt> cjwatson: Nope, not sure. I'm actually trying dist-upgrade now. I'll post the result when it's done
<Jemt> However, apt-get reported an estimated use of additionally 200 MB disk space. If that's true, upgrading the remastered edition is not an option.
<Jemt> But let's see how it goes
<ara> cjwatson, http://paste.ubuntu.com/556126/
<ara> cjwatson, I tried in several servers with the same results
<cjwatson> Jemt: you could remove stale packages afterwards ...
<Jemt> stale ?
<cjwatson> (that might be mostly a new kernel)
<cjwatson> well, do you understand why dist-upgrade might produce different results from upgrade?
<Jemt> Actually apt-get removed kernel-headers after upgrading, so it released almost 95 MB
<Jemt> cjwatson: According to the man it has better conflict resolution. Other then that, I don't know much about it
<cjwatson> Jemt: dist-upgrade is willing to install packages that aren't installed yet, if dependencies require it
<cjwatson> (and also to remove packages if conflicts require it, but that's less important in this case)
<Jemt> I see
<Jemt> Yes
<cjwatson> upgrade will only ever install new versions of packages you already have
<cjwatson> this means that if, say, the linux-image-generic package starts depending on linux-image-2.6.35-23-generic rather than linux-image-2.6.35-22-generic, then dist-upgrade will install linux-image-2.6.35-23-generic
<cjwatson> however, it will generally leave the old packages installed too, unless there's a specific reason to remove them
<Jemt> But I don't see how "apt-get upgrade" can result in dependency problem. I have never experienced anything like that in a normal environment
<cjwatson> that's what I mean by stale packages
<cjwatson> 'apt-get autoremove' may remove some of those
<Jemt> Ah, okay, I see
<Jemt> Well, dist-upgrade is what I want then. Never the less, I still get lots of errors.
<cjwatson> it shouldn't normally; I was suggesting dist-upgrade because it's slightly less likely to run into bugs
<cjwatson> ok, if dist-upgrade does the same, then probably what's happening is that some package's maintainer script is failing
<cjwatson> you haven't given me enough of the output from dpkg for me to be able to tell what that is
<Jemt> I doubt it. I upgraded my host environment without problems
<cjwatson> can I see the full output from 'apt-get upgrade', please?
<Jemt> Hang on, placing it on pastebin :)
<CIA-47> ubiquity: superm1 * r4483 ubiquity/ (bin/oem-config-remove-gtk debian/changelog): Fix oem-config-remove-gtk for changes in AptClient's commit_packages.
<Jemt> Unfortunately I didn't pipe the output to a file, so I don't have the entire output, only what's available in my console buffer: http://pastebin.com/Tz6ysqNr
<Jemt> If you want, I can run the upgrade again on a clean ISO, to produce all the output
<Jemt> And again, I'm performing the upgrade while remastering Ubuntu (I "chrooted" into the squash-fs)
<Jemt> Well, the _extracted_ squash FS
<cjwatson> I can't tell from that log - the initial error is before the start
<cjwatson> what you need to look for is the *first* failure
<cjwatson> did you remember to bind-mount /dev, /proc, and /sys into the chroot?
<cjwatson> I don't know if all of those will be necessary, but I wouldn't generally want to try to upgrade things without that
<cjwatson> ara: thanks, this looks rather odd, I'll investigate
<cjwatson> ara: I might be wrong, but I don't think it can have anything to do with the prior partition table
<cjwatson> ara: can I have /var/log/partman as well, in case that's necessary?
<Jemt> Hm, no, I only bind mount /dev
<ara> cjwatson, sure, do you want me to file a bug against debian-installer?
<Jemt> I'll try bind mounting your suggestions too, and re-run the upgrade. I'll post the result afterwards
<ara> cjwatson, http://paste.ubuntu.com/556135/
<Jemt> I'm away for about 30 minutes. The upgrade should be done then
<cjwatson> ara: sure, this is pretty bizarre
<cjwatson> ara: it should be reproducible without any preseeding, I think?
<ara> cjwatson, I haven't tried
 * ara files a bug against d-i
<CIA-47> ubiquity: evand * r4484 trunk/ (156 files in 3 dirs): Update translations from Launchpad.
<ara> cjwatson, bug https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/705377
<ubot2> Launchpad bug 705377 in debian-installer (Ubuntu) "Debian installer prompts for partition type when installing Ubuntu server (affects: 1) (heat: 6)" [Undecided,New]
<ara> cjwatson, thanks!
<cjwatson> I'll try it interactively and see what happens
<Jemt> cjwatson: Alright, update result is now available at http://pastebin.com/rh51MafV
<Jemt> Initial error seems to be related to dbus
<Jemt> (Line 1615)
<cjwatson> it might be worth bind-mounting /var/lock and /var/run as well then.  however, I don't actually know very much about dbus, and it isn't part of the installer
<cjwatson> all your other problems seem to arise from that
<Jemt> Okay, I was thinking about trying that too. Wasn't sure whether it could cause other problems though.
<cjwatson> I'm not sure about that, I'm afraid
<Jemt> After all, the "guest environment" (into which I "chrooted") share resources with the host environment. But it's not a critical computer, so if something breaks, it can easily be restored
<Jemt> I'll give it a try. Thanks  :)
<cjwatson> ara: broken by superm1's latest change to partman-partitioning
<cjwatson> I'll fix it up
<cjwatson> superm1: perhaps check with me before changing d-i components, sometimes they can be subtle ...
 * cjwatson rebases partman-partitioning onto the git migration first
<cjwatson> (though of course it was my fault that ubiquity broke ...)
<CIA-47> partman-partitioning: cjwatson * r899 ubuntu/ (debian/changelog lib/disk-label.sh):
<CIA-47> partman-partitioning: Use 'type' to check for archdetect on PATH, not 'which', which isn't
<CIA-47> partman-partitioning: available in d-i (LP: #705377).
<CIA-47> partman-partitioning: cjwatson * r900 ubuntu/debian/ (7 files in 2 dirs): merge from Debian 79
<Jemt> cjwatson: Thank you very much for your help. Bind mounting /var/run and /var/lock solved the problem. I took a look at UCK (Ubuntu Customization Kit), which seems to do the same (except mounting /var/lock - probably not necessary). However, UCK doesn't do bind mounts - it mounts the resources without the --bind argument. Not sure why. But using --bind ensure the use of the same mount options, so I'll stick to that
<Jemt> cjwatson: Did you find time to look at the e-mail I sent you ?
<cjwatson> not yet, sorry
<Jemt> No problem. The problem was not as urgent as the one we just solved :-)
<cjwatson> ev: looks like you forgot to push your casper change to lp:ubuntu/casper?
<cjwatson> ev: I've just committed a few other things and got a reject on upload - can you push your branch somewhere and I'll merge and fix it up?
<CIA-47> partman-partitioning: cjwatson * r901 ubuntu/debian/changelog: releasing version 79ubuntu1
<ara> cjwatson, thanks
<Jemt> "mount --bind /dev/ extracted_squash_fs/dev"  <= Wouldn't you guys expect /dev/pts to be mounted in squash fs too ?
<Jemt> INstalling a package gave me this error: "Can not write log, openpty() failed (/dev/pts not mounted?)"
<cjwatson> that's a warning you can ignore
<cjwatson> /dev/pts is a separate filesystem; bind-mounting /dev won't bind-mount it too.  See the documentation for mount --bind.  If you want to bind submounts too then you can use --rbind
<Jemt> Yes, but I'm still confused. Bind mounting /dev should give me everything in dev, right ?
<Jemt> Oh
<Jemt> Thank you
<ev> cjwatson: will do.  Sorry about that.  I normally have the branch bound, but I had to recreate it recently.
<ev> cjwatson: lp:~ev/casper/whoops
<cjwatson> ta
<superm1> cjwatson, oh sorry. i didn't realize something like which wouldn't be available in d-i.
<superm1> i'll make sure to test both d-i and ubiquity in the future if changing something that will affect both rather than just ubiquity
<cjwatson> yeah, tools are often pretty restricted
<cjwatson> thanks
<Jemt> How is /boot/initrd.img-[version]-generic compressed ? The .img extension puzzles me, since .lz is used in LiveCD/Casper
<cjwatson> gzip
<cjwatson> (use the 'file' command)
<cjwatson> the file naming is more or less historical; changing it would have tentacles all over the place so we'd rather not
<Jemt> I see
<Jemt> file didn't reveal the compression though
<Jemt> output:  initrd.lz: data
<cjwatson> it might not work on lzma - it works on /boot/initrd.img-blah
<cjwatson> anyway, .lz is lzma compression
<cjwatson> we recompressed the initrd for the live CD to save space, since the space/time tradeoff is different on live cDs
<cjwatson> CDs
<Jemt> Mmm, okay. The thing is, I just upgraded the remastered edition, which gave me a more recent kernel. I'd better copy that kernel to LiveCD/Casper, to have it boot with the new kernel. But I should probably use the more recent initrd too
<Jemt> I guess I have to decompress the new initrid.img file and recompress it as lzma
<cjwatson> right, although it's certainly possible to copy it to initrd.gz and change isolinux.cfg if you don't want to bother recompressing it
<Jemt> Even better. I can simply copy it to .gz ? Why not keep the .lz extension ?
<Jemt> sorry, .img extension - why not keep that ?
<cjwatson> er, well, it would be pretty confusing to call it .lz if it's gzip-compressed :-)
<Jemt> Yes, sorry. I wanted to keep the .img extension :)
<cjwatson> I wouldn't advise it - I'm not certain that isolinux can cope with filenames outside the 8.3 format in all cases
<Jemt> Okay, I'll use .gz :)
<cjwatson> of course it'll be bigger, I don't know what your space pressures are like
<Jemt> Wow, yes - much much bigger - almost 10 times
<Jemt> lzma sure is effective
<Jemt> Well, I think I can squeeze it to fit on the CD
<Jemt> Hm, an alternative solution would be to hold back the kernel during upgrade, to keep the kernel used on the Live CD
<Jemt> I'll take a moment to think it over
<cjwatson> 10x would be pretty unusual; it's only 1.4 times bigger with gzip versus lzma here
<cjwatson> (real system initrd, not live CD initrd)
<Jemt> Mine is 10.762.373 bytes (initrd.img-2.6.35-22-generic)
<Jemt> Odd
<Jemt> Do you have the same version ?
<cjwatson> what did you do to test that it's 10x smaller when lzma-ing?
<Jemt> "ls -la /boot" on my laptop vs "ls -la /LiveCDMounted/casper" on the mounted ISO
<Jemt> Oh, sorry
<Jemt> I missed a digit in one of them. Sorry, they are almost identical in size
<Jemt> Actually the new .img is a bit smaller
<cjwatson> also they don't contain the same things.
<Jemt> Yes, probably not
<cjwatson> the initrd is built dynamically
<cjwatson> hence why I didn't answer your version question, because it's mostly irrelevant :)
<Jemt> So it would be different on different computers ??
<Jemt> I didn't see any build processes running during upgrade
<cjwatson> yes.  that's what update-initramfs does
<Jemt> Hm, I wonder whether it's a good idea to upgrade the kernel then
<cjwatson> in particular, casper - the component that deals with the special arrangements needed to boot a live CD - lives in the initramfs
<cjwatson> it is not possible to boot a live CD with the same initrd that you use to boot an installed system
<Jemt> Okay, important point :)
<Jemt> I would still like to get the most recent kernel, but will it boot with the "old" initrd.lz on the Live CD ?
<cjwatson> no
<cjwatson> at least not if the ABI (the 2.6.35-22 part) has changed
<Jemt> Upgrading the kernel sounds like a really bad idea then. I'll keep it back while upgrading then
<Jemt> I'm glad we had this conversation. Otherwise I would have shipped a mess to the school waiting for this customized version of Ubuntu :)
<cjwatson> ev: do you have any ideas on what to do about bug 562312?  difficult problem ...
 * ev reads
<ev> I don't suppose we could do something clever with grub2 like get the kernel and initramfs out of the casper-rw ext3 image?  Forgive me if that's nonsensical, I'm running almost entirely off coffee today.
<ev> cjwatson: ^
<cjwatson> ev: yes, but relies on switching to grub2, and we ought to do something about older releases if possible
<cjwatson> it even bit pitti when he was trying to validate a casper SRU
<ev> sure, but we should do both :)
<ev> as in I'm happy to make the UI change as a backport, but want a better solution than handling it in the UI
<cjwatson> actually your suggestion would rely on some kind of union filesystem handling in grub2
<cjwatson> which seems ... likely to be interesting
<cjwatson> I suppose you could just conditionalise it or something
<ev> can you elaborate? My thought was to try to read it from inside casper-rw if it exists, otherwise look in the normal location.
<ev> is that what you mean by conditionalize?
<ev> sorry for the delay, I was trying to play around with aufs, but it just doesn't like me today
<cjwatson> that's what I meant, yes
<ev> are you happy with that? (If so, I can brain dump onto the bug)
<cjwatson> it's ok for whenever we manage to get to grub2 on the live images, just don't bank on that being soon :(
<ev> sure, I just want to make it clear to everyone that it's the end goal, rather than the ugly UI living forever
<cjwatson> yeah
<cjwatson> could we just cap the amount of space you're allowed to use in casper-rw to allow enough space for a kernel and initrd?
<cjwatson> rather than further uglifying the UI
<ev> sure
<cjwatson> I realise the size is not entirely constant but it doesn't vary all that much really
<ev> I've updated the bug
<cjwatson> thank
<cjwatson> s
<ev> sure thing
<Jemt> cjwatson: Hello again. You mentioned that update-initramfs builds an image specific to my box. Do you know where I can find more information about this? I wonder how the initrd.lz was build for the Live CD, which must be some sort of "generic" ram disk.
<cjwatson> I didn't say it was necessarily *very* specific to your box, just that in principle it can be.
<cjwatson> depends on what's in initramfs.conf
<cjwatson> (/etc/initramfs-tools/)
<cjwatson> we generally use MODULES=most which is pretty generic, but some people have particular needs and strip it down or add stuff or whatever
<Jemt> Okay, I will take a look at the configuration file
<Jemt> I see
<cjwatson> the real difference though is that the casper package is installed when building the initramfs for the live CD.
<Jemt> Oh yes, I forgot
<cjwatson> genericness isn't likely to be a problem; I just wanted to steer you away from the incorrect notion that there was just one initramfs for any given kernel version
<Jemt> Yes, I get it now. I'll have my computer compile a new custom Ubuntu edition tomorrow. It takes well over an hour, and I'm on my way to bed. Hopefully holding back the kernel when upgrading works.
<cjwatson> ev: could you update umenu/wubi/whatever for the upcoming 10.04.2 point release, please?
<Jemt> I'm off. Thanks for all your help, watson
<CIA-47> console-setup: cjwatson * r374 ubuntu/debian/ (3 files):
<CIA-47> console-setup: Correct fix for LP: #634402: explicitly check readability of
<CIA-47> console-setup: /etc/default/keyboard and /etc/default/console-setup in initramfs hooks,
<CIA-47> console-setup: rather than trying to guard '.' with '||' which doesn't work
<CIA-47> console-setup: (LP: #701954).
<CIA-47> console-setup: cjwatson * r375 ubuntu/debian/changelog: releasing version 1.57ubuntu3
#ubuntu-installer 2011-01-21
<svdasein> I'm having some trouble seeing past the initrd load when installing via a serial console - does anyone here have experience w/ that or know a better form to ask in?
<svdasein> s/form/forum/
<ara> ev, hey!
<ara> have you guys made any changes to the way we preseed the live cd in natty lately?
<ara> we are getting some issues when running our preseeded installations
<ara> we still need to get the logs to see what's going on
<ara> but I thought I might ask as well to see if there was something new
<cjwatson> ev may be able to, but personally I can't think of any deliberate changes that haven't had compatibility code inserted to preserve old preseed files
<ara> mmm, OK, we will try to get the logs to see what's going on
<ev> ara: nope
<ev> cjwatson: will do now
<cjwatson> ev: I think you said you were going to follow up to bug 691671?
<ubot2> Launchpad bug 691671 in ubiquity "Incomplete sentence during install check" [High,Triaged] https://launchpad.net/bugs/691671
<cjwatson> ev: you said you were going to fix bug 684052 too
<ubot2> Launchpad bug 684052 in ubiquity "live CD does not have reboot on the power menu after install completes" [High,Triaged] https://launchpad.net/bugs/684052
<ev> replied to 691671, looking into 684052 again now
<ev> thanks
<cjwatson> All our d-i branches except for debian-installer itself are now rebased on top of git.  I suggest shelving any changes you have before updating, and you may well find that you need to do something like 'bzr revert; bzr clean-tree --force' after updating.
<cjwatson> If you have any non-trivial branches you care about merging into our current trunk, then let me know and I can supply you with rebased versions.
<ev> nice, thanks for sorting that
<cjwatson> I'm also in the process of pushing up git mirrors of those so that the d-i team can cherry-pick from them
<cjwatson> Obviously you'll need to reget any upstream branches you have; lp:<foo> should work for everything we've imported
<cjwatson> Or you can 'bzr get git://git.debian.org/d-i/<foo>' if you have bzr-git installed
<ev> okay
<CIA-47> wubi: evand * r191 lucid/ (data/isolist.ini debian/changelog): Bump Ubuntu and Kubuntu to 10.04.2.
<ev> phew, wubi 10.04.2 up.  Building a chroot and installing dependencies takes way too long on a t-mobile 3g dongle.
<pmatulis> during a server install (normal mode) is it possible to install grub manually by flipping to a console?  grub-installer is there but not grub-install
<cjwatson> you can bind-mount /dev, /proc, and /sys into /target, chroot to /target, and run grub-install in the chroot
<cjwatson> grub-installer is definitely not what you want
<pmatulis> right, thx
#ubuntu-installer 2011-01-22
<cjwatson> hm, I forgot to rebase netcfg for some reason
<Jemt> Hello again, folks.
<Jemt> A quick question regarding initrd. As mentioned earlier, I use the Live CD to boot Ubuntu installations on USB sticks. The USB stick, however, may be upgraded over the months, resulting in a new Initrd being created. Will Ubuntu always work if I boot it using an older version of Initrd? The kernel is hold back, so that's never upgraded
<Jemt> I fear that packages somehow may depend on new functionality in the newly created initrd. This probably won't be available if the system is booted using an older version of initrd
<cjwatson> packages other than the kernel may cause the initramfs to be regenerated
<Jemt> Yes, I know - e.g. udev
<cjwatson> if you're talking about just a stable release though, and forcibly hold the initramfs back (e.g. by never copying it out to the top level of the USB stick), you should be OKK
<cjwatson> OK
<cjwatson> just don't try to do that across updates between releases
<Jemt> But as you mentioned, any package may force initrd to be re-generated. Don't you think that's because they require changes to initrd to work properly ?
<Jemt> I was also considering holding back changes to initrd somehow, but really, almost any package could have it regenerate. I would probably have to disable the update manager to keep that from happening
<Jemt> cjwatson: Is it possible to have a custom script run after package installations? I need something to trigger my "restore" script which will do "ln -s /boot/old-initrd /initrd.img"
<Jemt> Nonsens... I just realized something. Holding it back on the USB stick is not the solution, since the older initrd on the Live CD is still used to boot the USB stick
<Jemt> What I need, is to make sure the USB stick will always boot with the "old" kernel and initrd on the Live CD, even though the USB stick is up-to-date
<Jemt> cjwatson: I found evidence to support what you said (not that I don't trust you :-)). /etc/initramfs-tools/update-initramfs.conf contains an option to disable updates to initrd. So it is unlikely that packages will break if the "old" initrd is used.
<Jemt> Option is called "update_initramfs={yes/all/no}
#ubuntu-installer 2012-01-16
<superm1> stgraber: regarding the username and hostname setting in scripts/casper (bug 290351), I think this should also update /etc/casper.conf.  there are functions in ubiquity that normally will be fetching from /etc/casper.conf and this information will then be out of sync
<ubot2> Launchpad bug 290351 in casper "live session user and host should be called kubuntu on kubuntu" [High,Fix released] https://launchpad.net/bugs/290351
<stgraber> superm1: yes, there's a bug open for that, bug 904482
<ubot2> Launchpad bug 904482 in livecd-rootfs "Generate /etc/casper.conf when building a livefs instead of having casper guess the product name at boot time" [Undecided,New] https://launchpad.net/bugs/904482
<superm1> stgraber: ah okay good.  do you have a plan for how soon to fix it?  Would I be better off just hardcoding in the mythbuntu ubiquity and casper plugins for now, or fairly soon it will be fixed?
<stgraber> cjwatson: ^
<stgraber> superm1: If we don't get casper.conf to contain the right values at build time, I think it'd be best to just change the casper script to update casper.conf in the overlay so that anything parsing it just works
<superm1> stgraber: yeah that sounds fine by me
<stgraber> superm1: but ideally, we should really have casper.conf contain the right values to start with. I'd think that'd make building custom images a bit easier as you'd just need to change casper.conf instead of having to look at what kind of magic we're doing to get that value :)
<superm1> true
#ubuntu-installer 2012-01-17
<CIA-11> casper: superm1 * r991 casper.precise/ (debian/changelog scripts/casper):
<CIA-11> casper: * Write out a new casper.conf with derivative values if they've been changed.
<CIA-11> casper:  - Fixes applications that parse /etc/casper.conf from breaking.
<CIA-11> casper:  - This can be reverted after the livecd-rootfs task from LP: #904482 is
<CIA-11> casper:  fixed.
<CIA-11> casper: superm1 * r992 casper.precise/debian/changelog: releasing version 1.298
<bdmurray> Is bug 914917 X related?
<ubot2> Launchpad bug 914917 in ubiquity "Precise Ubiquity locks up on clicking continue on the Who are you page" [Undecided,New] https://launchpad.net/bugs/914917
<bdmurray> Jan 11 17:34:25 ubuntu kernel: [  458.046862] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<bdmurray> from the syslog
<bdmurray> cjwatson: bug 916435 has a patch in the comments
<ubot2> Launchpad bug 916435 in grub2 "grub-setup crashed with SEGV in grub_util_biosdisk_is_floppy()" [Undecided,New] https://launchpad.net/bugs/916435
<stgraber> superm1: thanks for the casper changes
#ubuntu-installer 2012-01-18
<antarus> aha I have found cjwatson at last ;)
<cjwatson> antarus: hmm?
<antarus> cjwatson: I am testing a patch to netcfg; I think the precise version has a bug
<antarus> https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/917905, fyi
<ubot2> Launchpad bug 917905 in netcfg "netcfg hang bug in autoconfig.c" [Undecided,Confirmed]
<cjwatson> antarus: it seems odd that it would hang on the fgets call; shouldn't that get EOF instead?
<antarus> cjwatson: dhclient never exits
<antarus> so it wouldn't get SIGPIPE or EOF
<antarus> on my network dhclient just retries forever
<cjwatson> ah, annoying thing that you have to kill, right - there's some discrepancy among the different clients here
<antarus> yeah its a mess :/
<cjwatson> (you wouldn't get SIGPIPE anyway; that's for writes, not reads)
<antarus> my patch basically checks rv, and if we didn't get a lease, doesn't bother reading from the pipe at all
<antarus> although I think it also breaks the 'retry' logic
<cjwatson> I think it exits quickly with stateless autoconfig but not stateful
<cjwatson> I'm a bit worried about that because 0 returned from poll_dhcpv6_client is documented as "not known to have acquired a lease"
<cjwatson> rather than definitely not
<cjwatson> I wonder if it would be better to arrange for dhclient to actually exit
<antarus> dhclient does support a timeout option afaik
<antarus> so we could push the preseed config value down to it?
<cjwatson> I'm concerned that if we don't read from the pipe on failure, there are cases where we'll end up with a stuck client for one reason or another
<cjwatson> passing down the timeout would be fine; it's documented as 300 seconds by default
<cjwatson> I think that would be worth a go
<antarus> bleh, the dhclient binary in the initrd doesn't support -timeout ?
<cjwatson> nor does any ISC dhclient binary that I know of; it goes in the configuration file
<antarus> cjwatson: the timeout only works if I pass -1 to dhclient (to exit if it failed to get a lease)
<antarus> cjwatson: otherwise it will combine timeout + retry + backoff and just retry forever apparently
<cjwatson> which means it will only try once rather than retrying a few times, right?
<antarus> correct
<antarus> well for me I set the timeout to 5s, and it tried 4-5 times and then gave up
<antarus> ahh, it did 3 attempts until it hit my 5s timeout and then quit
<antarus> I'm just unclear because another segment talks about keepign the client alive and having the user request we 'retry'
<antarus> and I'm not clear how the retry logic is supposed to work
<antarus>  * This function will NOT kill the child if time runs out.  This allows
<antarus>  * the user to choose to wait longer for the lease to be acquired.
<antarus> that comment basically
<cjwatson> That may be a dead comment
<cjwatson> I can't see how you'd do that - you'd select "Retry network autoconfiguration" which would start a new client
<antarus> ok, I will go ahead and push the netcfg/dhcpv6_timeout into the dhclient config file and pass it '-1' so it will oneshot attempt. Does that sound reasonable to you?
<cjwatson> (The history of this branch is that one developer did about 90% of the work and then quit, and I picked it up and bodged it into shape with some help from stgraber; so I can't be authoritative on all of it)
<cjwatson> I think it's worth a go.  stgraber has a scary test suite he should be able to run it through
<antarus> excellent
<antarus> I like test suites :)
<stgraber> which reminds me I really need to get the tests running daily on Precise...
<antarus> cjwatson: excellent, my patch works here (after much futzing with initrds)
<antarus> bah
<antarus> my initrd has a different bug now
 * antarus will finish this tomorrow
<superm1> stgraber: sure no problem.
<antarus> cjwatson: is there some way to run netcfg in debug mode?
<cjwatson> DEBCONF_DEBUG=developer on the kernel command line will show a trace of all debconf interaction, and watch syslog
<cjwatson> not really beyond that
<antarus> ok
<antarus> my patch seems to have fixed the ipv6 issue, but not it won't autodetect my hardware
<antarus> and I can't really see how the two are related
<cjwatson> that isn't generally even netcfg's responsibility
<cjwatson> compare the rest of your initrd with the stock one
<antarus> hrm, ptom differs for some reason
<antarus> oh its a symlink to netcfg
<antarus> heh
 * antarus makes a new initrd anyway
<antarus> ahh looks like I had an old copy
<antarus> cjwatson: excellent, works with a new initrd ;)
<cjwatson> good good
#ubuntu-installer 2012-01-19
<bdmurray> Is there enough information in bug 918701 to proceed?
<ubot2> Launchpad bug 918701 in ubiquity "Ubiquity crash if screen reader is running" [Medium,Triaged] https://launchpad.net/bugs/918701
<bdmurray> I've recreated it and have the system running
#ubuntu-installer 2012-01-20
<GrueMaster> cjwatson: (or someone equally knowledgeable in oem-config), is there a way to preseed oem-config for automation testing?  I tried using the same preseed I use for netinstall, but it didn't work.  The system had the user info filled in, but prompted me still for each line.
<ogra_> GrueMaster, iirc ubiquity needs some special switch for that to run fully automated, i guess thats true for oem-config as well
<GrueMaster> ogra_: Needless to say, your preseed mod didn't work.
<ogra_> file a bug please ... jasper.log appreciated
<CIA-11> debian-installer: cjwatson * r1612 ubuntu/ (6 files in 2 dirs): Move to 3.2.0-10 kernels.
<cjwatson> GrueMaster: I have a suspicion that the user is special because it always differs from the one set in ubiquity
<cjwatson> there are definitely some manual hacks around that in oem-config, and I think I've generally said when asked that oem-config preseeding is best-effort at beest
<cjwatson> *best
<GrueMaster> So essentially this is sounding like a lost cause.
<CIA-11> debian-installer: cjwatson * r1613 ubuntu/debian/changelog: releasing version 20101020ubuntu99
<cjwatson> GrueMaster: given that I have no time to work on it for at least a couple of months, the best I can say is "sorry" unless you can find somebody to fix it ...
<GrueMaster> Any other ideas for doing automated image smoke testing?  With all the images we have for armel, I can't do all of them manually daily.
<GrueMaster> s/armel/arm*
<ogra_> GrueMaster, well, with the plan to have oem-config executable in a chroot to be able to run it inside of live-build (as rootstock replacement) either infinity or me will look into that
<ogra_> that should help your case as well
<ogra_> its just not high prio for either of us
<CIA-11> partman-iscsi: cjwatson * r56 lucid-proposed/ (3 files in 3 dirs): Don't fail if debconf questions are preseeded (LP: #810068).
<CIA-11> partman-iscsi: cjwatson * r57 lucid-proposed/debian/changelog: releasing version 14.1
<CIA-11> partman-iscsi: cjwatson * r58 maverick-proposed/ (3 files in 3 dirs): Don't fail if debconf questions are preseeded (LP: #810068).
<CIA-11> partman-iscsi: cjwatson * r59 maverick-proposed/debian/changelog: releasing version 15.1
<CIA-11> partman-iscsi: cjwatson * r60 natty-proposed/ (3 files in 3 dirs): Don't fail if debconf questions are preseeded (LP: #810068).
<CIA-11> partman-iscsi: cjwatson * r61 natty-proposed/debian/changelog: releasing version 16.1
<CIA-11> kickseed: cjwatson * r283 lucid-proposed/ (debian/changelog handlers/iscsi.sh): Fix iSCSI ks_preseed calls to include a type field (LP: #810068).
<CIA-11> kickseed: cjwatson * r284 lucid-proposed/debian/changelog: releasing version 0.54ubuntu1.10.04.2
<CIA-11> kickseed: cjwatson * r283 maverick-proposed/ (debian/changelog handlers/iscsi.sh): Fix iSCSI ks_preseed calls to include a type field (LP: #810068).
<CIA-11> kickseed: cjwatson * r284 maverick-proposed/debian/changelog: releasing version 0.54ubuntu1.10.10.2
<CIA-11> kickseed: cjwatson * r285 natty-proposed/ (debian/changelog handlers/iscsi.sh): Fix iSCSI ks_preseed calls to include a type field (LP: #810068).
<CIA-11> kickseed: cjwatson * r286 natty-proposed/debian/changelog: releasing version 0.55ubuntu1.2
<GrueMaster> cjwatson: Is there a way to tell oem-config-debconf to not go into a curses mode?  If that were possible, I could at least do something via serial-console & expect.
<cjwatson> no
<cjwatson> well, you might try DEBIAN_FRONTEND=readline perhaps
<cjwatson> I suppose you could even try DEBIAN_FRONTEND=noninteractive and see if that helps
<GrueMaster> I'll give those a try.
<ev> bdmurray: what was that about?
<ev> (leaving ~ubuntu-installer)
<bdmurray> ev: colin had added me so I could make bug control bug supervisor for wubi
<ev> ah
<bdmurray> is mpt on holiday?
<GrueMaster> http://thetyee.ca/News/2012/01/19/TyeeCrash/
<GrueMaster> "While we're sympathetic to the SOPA protest, which involved high-profile sites like Wikipedia "going dark" for 24 hours yesterday, we categorically deny blowing anything up in support of the cause."
<GrueMaster> LOL
<GrueMaster> Oops, wrong channel.
<GrueMaster> cjwatson: None of the DEBIAN_FRONTEND=[text readline noninteractive] settings has any effect.  oem-config still comes up with a txt-gui through serial console.
<CIA-11> tasksel: cjwatson * r1476 ubuntu/ (Makefile debian/changelog): Point Ubuntu task update script at precise.
<CIA-11> tasksel: cjwatson * r1477 ubuntu/ (7 files in 2 dirs):
<CIA-11> tasksel: Update Ubuntu tasks from seeds; notably, this adds openstack and
<CIA-11> tasksel: ubuntustudio-dvd-live, and sets ubuntu-usb's Key to inkscape.
<CIA-11> tasksel: cjwatson * r1478 ubuntu/debian/changelog: releasing version 2.88ubuntu9
#ubuntu-installer 2012-01-21
<CIA-11> ubiquity: cjwatson * r5121 python3/ (27 files in 8 dirs):
<CIA-11> ubiquity: * Begin porting to Python 3:
<CIA-11> ubiquity:  - Use Python 3-style print functions.
<CIA-11> ubiquity: cjwatson * r5122 python3/ (22 files in 6 dirs):
<CIA-11> ubiquity: Use "except Exception as e" syntax rather than the old-style "except
<CIA-11> ubiquity: Exception, e".
<CIA-11> ubiquity: cjwatson * r5123 python3/ubiquity/debconffilter.py: rearrange OSError handling a bit to satisfy Python 3
<CIA-11> ubiquity: cjwatson * r5124 python3/ (4 files in 3 dirs): Use reduce from functools rather than relying on the builtin.
<CIA-11> ubiquity: cjwatson * r5125 python3/ (7 files in 5 dirs): Use list comprehensions rather than filter.
<CIA-11> ubiquity: cjwatson * r5126 python3/ (debian/changelog ubiquity/frontend/kde_ui.py ubiquity/tz.py): Use open() rather than file().
<CIA-11> ubiquity: cjwatson * r5127 python3/ (4 files in 3 dirs): Use list comprehensions rather than map.
<CIA-11> ubiquity: cjwatson * r5128 python3/ (debian/changelog ubiquity/frontend/gtk_ui.py): Import configparser rather than ConfigParser if available.
<CIA-11> ubiquity: cjwatson * r5121 trunk/ (7 files in 4 dirs): autogen
<CIA-11> ubiquity: cjwatson * r5122 trunk/ (25 files in 12 dirs):
<CIA-11> ubiquity: Drop backports of saved ID handling functions from os, now that we
<CIA-11> ubiquity: require Python 2.7.
<CIA-11> ubiquity: cjwatson * r5129 python3/ (debian/changelog ubiquity/plugins/ubi-usersetup.py): Use input() rather than raw_input() when running under Python 3.
<CIA-11> ubiquity: cjwatson * r5130 python3/ (debian/changelog scripts/install.py scripts/plugininstall.py): Use set comprehensions.
<CIA-11> ubiquity: cjwatson * r5123 trunk/ (debian/changelog ubiquity/misc.py): Remove an unnecessary use of contextlib.closing.
<CIA-11> ubiquity: cjwatson * r5124 trunk/ (debian/changelog ubiquity/parted_server.py): Simplify PartedServer.disks.
<CIA-11> ubiquity: cjwatson * r5131 python3/ (debian/changelog ubiquity/plugins/ubi-timezone.py): Import quote from urllib.parse rather than urllib if available.
<CIA-11> usb-creator: cjwatson * r365 trunk/ (4 files in 4 dirs): Use Python 3-compatible print functions.
<CIA-11> usb-creator: cjwatson * r366 trunk/ (8 files in 5 dirs):
<CIA-11> usb-creator: Use "except Exception as e" syntax rather than the old-style "except
<CIA-11> usb-creator: Exception, e".
<CIA-11> usb-creator: cjwatson * r367 trunk/ (3 files in 3 dirs):
<CIA-11> usb-creator: Use "raise Exception(value)" syntax rather than the old-style "raise
<CIA-11> usb-creator: Exception, value".
<CIA-11> usb-creator: cjwatson * r368 trunk/ (8 files in 8 dirs): Use absolute imports.
<CIA-11> usb-creator: cjwatson * r369 trunk/usbcreator/backends/base/__init__.py: another absolute import
<bluenemo> hi guys. i'm trying to automate the ubiquity installer. i want to use a preseed file, but i have to boot into a ubuntu live system first as i need a fully working system for pre configuration. where do i have to locate the .seed file when i invoke ubiquity --automatic from the command line on a ubuntu live system?
<cjwatson> ubiquity doesn't parse preseed files itself.  You must either use the file= boot parameter so that casper can process it, or pass the file to the 'debconf-set-selections' tool in the live system before invoking ubiquity if you want to do it by hand.
<CIA-11> ubiquity: cjwatson * r5125 trunk/ (debian/rules tests/build tests/run): Fix up the test suite a bit to account for ubiquity/Makefile no longer existing.
<bluenemo> cjwatson, thank you, so i basicly have to do:   debconf-set-selections /path/to/file.seed && ubiquity --automatic   and ubiquity will use the file.seed?
<bluenemo> (or better said the selections wrote down in the file)?
<cjwatson> right, that should work
<bluenemo> cjwatson, perfect thank you very much :)
#ubuntu-installer 2013-01-14
<melodie> hello
<melodie> I have a question about the Ubiquity installer, is there someone available ? It's about how the background is setup (inside the window)
<cjwatson> ubiquity doesn't care about that itself; it's up to the GTK theme or the window manager or whatever.  I'm afraid I have no idea how it works.  You need somebody who knows about the desktop environment / window manager / toolkit / whatever that you're using.
<melodie> hi cjwatson
<ogra_> hwat do you mean by "inside the window"
<melodie> I have setup an Ubuntu Openbox using the same gtk themes are Lubuntu does, and tried different window themes
<cjwatson> I can't help you further.
<melodie> hi ogra_ I mean inside the ubiquity installer window. I have a pic on the web I show the link
<melodie> I just updated firefox, it's coming...
<cjwatson> And from what I remember about the picture you showed before it's not something that any installer code is responsible for.
<ogra_> the content comes from the $flavour/ubiquity/slideshow packages
<ogra_> bah
<cjwatson> No, this is something different
<melodie> this is what I get : http://meets.free.fr/debian/images/ubiquity-frontend-gtk-look.png
<ogra_> $flavour-ubiquity-slideshow
<cjwatson> ogra_: no
<ogra_> k
<cjwatson> this is not about the slideshow
<melodie> I had tried to install the lubuntu slideshow, this part was still black
<melodie> right cjwatson
<cjwatson> but it's also not about any installer code, *unless* people who know about openbox say that ubiquity-dm needs to run some special openbox-specific command to set up an openbox-using session correctly
<cjwatson> ubiquity-dm sets up a session using entirely its own code, so it's possible it's missing something
<ogra_> the pic simply looks like a theme or theme engine is missing
<cjwatson> it's bin/ubiquity-dm in the ubiquity source package - compare that with the openbox session setup
<melodie> which part of the openbox session setup ?
<cjwatson> I have no idea
<melodie> ogra_, I have all the same themes gtk2 gtk3 and engines as Lubuntu does, I a sure because I added some after I compared the filesystem.manifest files
<cjwatson> This is the responsibility of people porting ubiquity-dm to a new desktop environment to figure out - i.e. you :)
<cjwatson> Before you look at ubiquity-dm, though, check that a normal openbox session started from the same live CD (or whatever) works
<melodie> I will try to look into the openbox configuration files
<cjwatson> If it does then it's reasonable to conclude that ubiquity-dm is missing something
<ogra_> openbox looks fine in the screenshot though
<melodie> cjwatson, it does, I have done about 20 isos which I tested at home so far and a few are online for testing
<ogra_> you have a proper windowframe and theme
<melodie> ogra_, right
<ogra_> the content is gtk
<melodie> here is how the desktop looks
<melodie> http://meets.free.fr/debian/images/BoxBuntu.png
<melodie> and here is one with htop: http://meets.free.fr/debian/images/BoxBuntu-ressources.png
<cjwatson> We don't run the standard Xsession scripts or anything
<cjwatson> htop> not relevant
<melodie> it's just a window... the only one online atm
<cjwatson> Yeah, it just doesn't tell us anything important for this purpose, so skip it :)
<ogra_> you likely need to have some kind of gtkrc (not sure what gtk3 usues nowadays to do such native stuff)
<melodie> I have compared ubiquity-dm files from this spin I did with the one from Madbox, also built on Ubuntu, but found no difference
<cjwatson> Um
<cjwatson> I think you're missing the point
<melodie> however I didn't compare his openbox setup files yet
<cjwatson> ubiquity-dm reimplements all the xsession (etc.) stuff
<cjwatson> if your desktop needs something from that to set up its theme properly, that needs to be reimplemented in ubiquity-dm
<melodie> ogra_, there is a .gtkrc-2.0 file in it
<cjwatson> So you need to understand your desktop environment startup sequence in detail in order to make sure that ubiquity-dm's setup code is sufficient
<melodie> cjwatson, if you were right then Madbox's ubiquity-dm would be different than mine, but it's not
<melodie> and Madbox has a normal ubiquity window
<cjwatson> Well, that's the only special thing that the installer does for this
<melodie> cjwatson, ok I'll compare the Openbox setup from Madbox with mine
<cjwatson> But if you're not sure then you should compare all the files from all the ubiquity packages, not just ubiquity-dm
<melodie> this is something I have not dug yet, so why not.
<melodie> I have a buddy who is keen with python who started to dig the ubiquity files so I hope he can do that
<melodie> ok, I'll dig openbox startup files, thanks !
<cjwatson> Well, you don't need to dig into them in detail; just get the file lists and diff
<melodie> yes, sure
<melodie> I need to look if some are in the home user directory and also the ones at /etc/xdg/openbox, and that should be it. I'll check what is in the login manager too
<melodie> I have another question, while my vbox machines start and restart : is there somewhere at Ubuntu a doc on how to setup isolinux to tweak the theme for Ubuntu boxes ?
<melodie> ie: I have no idea how to produce the init file which contains code for one part of the appearance
<infinity> cjwatson: Remind me of the magic required to jam a test kernel into a d-i build?
<melodie> I'll bbl
<melodie> thanks for all, will try to solve my issue
#ubuntu-installer 2013-01-15
<mfilipe> I'm going to install Ubuntu on my new laptop. So, I wanna now if the Ubuntu Installer automagically aligns the ssd partitions.
<wenchien> hi~
<wenchien> proposed merges for lp:944614
<wenchien> https://code.launchpad.net/~wenchien/ubiquity/ubiquity.lp944614/+merge/143250
<wenchien> https://code.launchpad.net/~wenchien/ubiquity/precise-proposed.lp944614/+merge/143251
<infinity> wenchien: We get mailed notifications for those.
<wenchien> infinity: ok, thanks!
<xnox> wenchien: i looked at it, it's ok. But I am worried how/why are we loosing dbfilter when switching between steps & i'd like stgraber to review those as he did the first fix attempt to fix the experienced problem.
<wenchien> xnox: thanks, i'll wait for stgraber's comment :)
<cjwatson> infinity: build all the udebs and shove them in build/localudebs/
<infinity> cjwatson: Yeah, I remembered that shortly after I asked.
<infinity> cjwatson: Of course, what I neglected to do was include my scsi.udeb in the mini.iso. :P
<infinity> cjwatson: So I now have a machine that booted (progress!), but I miiiight not have any disks until I can either get remote hands for a new CD, or get IS to fix my networking.
<infinity> cjwatson: But, whatever.  It's mostly there.  I'm happy.
<cjwatson> wenchien: I don't think this fix is correct, for much the same reason xnox outlined.  It needs more analysis of *why* that's None.
<cjwatson> infinity: is this for the new powerpc box?
<infinity> cjwatson: *nod*
<infinity> Sweet mother of... I didn't look at cpuinfo until now.
<infinity> Did IBM do something hyperthreading-like on POWER when I wasn't paying attention?
<infinity> My 6 cores report as 24 CPUs.
<StevenK> "PowerPC Server processors have supported Simultaneous Multi-Threading (SMT) ... update; POWER7 processor cores support SMT4"
<StevenK> So, yes. I guess.
<infinity> StevenK: SMT4 seems to have the right integer to back this up. :P
<StevenK> infinity: Right, that I was my thought as well.
<StevenK> s/I //
<infinity> Not gonna complain, if it performs.  As soon as this is up, I'm throwing linux-ppc at it to see how it does.
<StevenK> We have a DAS for it?
<infinity> Hrm?
<StevenK> Or is this by hand?
<infinity> It's powerpc...
<wenchien> cjwatson: humm, ok, i'll do that
<infinity> I'll just copy linux-ppc from raring to my PPA and force it on this machine.  Anything's better than the 13.5h the last build took on adare, but I want to see how MUCH better.
<stgraber> cjwatson, xnox: ok, so the real fix we need here is a check for whether the page is currently active. The proposed fix does that but I'm sure we can check on somehting a bit better than dbfilter.
<stgraber> basically the problem here is that you can trigger on_keyboard_variant_selected and then skip the page before the 600ms timeout hits
<stgraber> and when the timeout hits, it'll try poking at things that no longer exist and will cause ubiqutiy to fail quite badly
<cjwatson> stgraber: got it
<Jasper> ev, how do you feel about putting libtimezonemap on GNOME git?
<xnox> Jasper: I need to make one commit to add original svg sources for the map. I am ok with gnome git. If GNOME will use it than it will be great.
<Jasper> xnox, that's fine. Our current design: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-settings/date-and-time/date-and-time-hi-res.png
<xnox> Jasper: looks nice =) mpt had some proposed design tweaks to date-and-time as well, last time were brainstorming on the installer.
<xnox> Jasper: do wait for ev's reply. I'm just a minion here =)
<Jasper> OK.
#ubuntu-installer 2013-01-16
<antarus> cjwatson: I have a weird question. Canonical is sort of slowish at SRUing stuff for gPrecise, particular once it is aged...What do I have to do to be able to have folks on my team SRU changes ourselves?
<cody-somerville> antarus: Canonical is not responsible for the Stable Release Update process - the community SRU team is. The wikipage at https://wiki.ubuntu.com/StableReleaseUpdates describes the process. The SRU team is tasked with determining if an update meets the SRU criteria but the rest of the process can be handled by any contributor (with support from a Ubuntu developer to handle the upload).
<cody-somerville> Or are you talking about the internal Google version of Ubuntu?
<infinity> antarus: What do you mean by "particular once it is aged"... When SRUs are aged *and tested*, we release them.
<infinity> antarus: If things you care about aren't being tested/verified, the solution is fairly obvious.
<antarus> cody-somerville: I guess my question is then 'how do I join the community SRU team'
<antarus> cody-somerville: I want to avoid forking a bunch of stuff interally because it takes weeks to get an SRU
<antarus> infinity: once a package is in proposed, we are pretty quick to test and get back to you on launchpad
<antarus> We have discussed before about being more involved in the community, process / contribution wise
<antarus> (discussed internally, that is)
<antarus> Hrm although I guess in the bug I am thinking of
<antarus> there is no SRU on launchpad yet
 * antarus tsks
 * antarus should really just join Ubuntu
<antarus> infinity: I guess the end result I am looking for is that we don't actually mind doing an internal fork, as long as we are sure that our fork is the same fork Ubuntu is doing.
<antarus> infinity: so if the answer is 'do an internal fork and post it to the bug so it is SRU'd into Ubuntu'
<antarus> then I'd be happy to do more of the SRU'd work
<antarus> but if Ubuntu doesn't approve the SRU, I'm stuck maintaining the package myself, which has ended badly in the past
<antarus> right now we basically never do forks, and wait for Ubuntu to SRU everything. But particularly as precise gets older and older, the SRUs seem to be..more difficult?
<infinity> antarus: Well, there's no such guarantee, really.  If a sponsor thinks the SRU is worth uploading, if the SRU team thinks the bug fits the SRU criteria, then it'll get into proposed.  Then if it verifies okay, it'll get to updates.
<infinity> antarus: This process doesn't change regardless of whether you're submitting patches to bugs or doing the uploads yourself.
<infinity> antarus: But, absolutely, submit patches to bugs.  A lot of bugs in stable releases go unhandled just due to nobody having the time to fix them.  If you have the fix, don't hold out. :)
<antarus> infinity: thanks for the feedback
<ev> Jasper, xnox: can you explain why it would need to live on GNOME git?
<xnox> ev: in the past, not being in gnome git hindered zeitgeist framework adoption.
<ev> xnox: hindered how?
<xnox> ev: it did not get accepted into the gnome packagesets (the jhbuild xml sets) thus standard gnome app maintainers were not accepting zeitgeist patches, or if they did couldn't enable them by default due to packageset dependency constraints.
<ev> that's silly.
<xnox> =)))) yes, it seemed so to me as well.
<xnox> ev: i'm not sure why Jasper wants it in GNOME git. But it looks like there are mockups/things that gnome-design wants to do with it. https://raw.github.com/gnome-design-team/gnome-mockups/master/system-settings/date-and-time/date-and-time-hi-res.png
<mpt> We're not using those time+date designs, because we already have better designs implemented, ;-) but if we can share the map code at least, all well and good.
<cjwatson> antarus: I think the worst blockage in the SRU process right now is in queue review, which is fairly privileged and hard to help with - but there are definitely other places to help, as infinity said.  Perhaps a Goobuntu engineer or three should be looking at becoming Ubuntu developers?
<ev> I'm all for cooperation, but I think the whole, "this must live in our house for us to help with it" thing is sad.
<ev> xnox: that said, we're just speculating. I'm keen to hear what Jasper has to say.
<FourDollars> Where is the main development branch of ubiquity? Is it lp:ubiquity?
<cjwatson> Yes
<FourDollars> Thx
<FourDollars> I find a problem that 'self.custom_title = self.db.get('ubiquity/custom_title_text')' can not be l10n.
<FourDollars> Are we still able to change ubiquity for Ubuntu 12.04.2 now?
<cjwatson> Unlikely
<cjwatson> Running out of time
<cjwatson> Do send fixes for the development release though; I expect we'll do more ubiquity backports for 12.04.3
<FourDollars> Should I open a bug for this?
<cjwatson> Yes
<cjwatson> Though I have no ideas on how to fix it sensibly without breaking compatibility
<cjwatson> Internationalisation should generally be done by metaget description rather than get, but that's hard to preseed
<cjwatson> Actually I'm not totally sure I understand the requirement; surely for a preseeded install you're typically preseeding the locale too, and for a customised installation image you can just change ubiquity directly
<cjwatson> It kind of seems to me that if you need internationalisation in ubiquity/custom_title_text you're doing something wrong ...
<FourDollars> I am working on a patch based on lp:ubiquity. Maybe you can give me some advice after I come out the patch.
<cjwatson> Requirements before patch
<FourDollars> OK.
<FourDollars> I am going to open a bug first.
<mpt> xnox, hi, are you doing RAID this cycle?
<cjwatson> OK - please include the answer to the question I asked above
<xnox> mpt: in the installer? it's "undecided" priority for now (below low)
<mpt> weird
<mpt> Hi lisettte :-)
<lisettte> hi mpt
<FourDollars> cjwatson: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1100256
<ubot2`> Launchpad bug 1100256 in ubiquity (Ubuntu) "ubiquity/custom_title_text can not be l10n." [Undecided,New]
<cjwatson> And you haven't answered my question, so Incomplete :)
<FourDollars> Err.. >_<
<xnox> FourDollars: i don't understand why, or more importantly how. Where are the translations going to come from? Since you want multiple translations, one should be modifying ubiquity.pot and doing the translations. Or do you want prefix/suffix/substitute string in the title?
<xnox> e.g. "Installing $FOObuntu"
<cjwatson> FourDollars: It's not useful to just say "This is a requirement" - explain why
<FourDollars> xnox: For example, "HP installer".
<cjwatson> Specifically, why it is necessary to be able to preseed more than one translation of your string
<cjwatson> And why that can't be done using a customised ubiquity package, if that's what you're doing.  custom_title_text is not intended to scale up to lots of translations
<FourDollars> We will get prepare the translation for "HP installer".
<cjwatson> Then you should have a customised build of ubiquity for the HP installer
<cjwatson> And you should change the text for ubiquity/text/live_installer
<cjwatson> (And fill in the appropriate translations in .po files)
<cjwatson> ubiquity/custom_title_text is simply not what you need
<cjwatson> change the text> that is, in debian/ubiquity.templates
<FourDollars> http://paste.ubuntu.com/1537520/
<FourDollars> This is my idea.
<cjwatson> That's technically possible, but now you have to get the translated debconf template into the debconf database somehow, which can't be done using preseeding alone in any case.  I don't understand why you can't just build a modified ubiquity package with the text you want.
<cjwatson> Particularly since your patch requires that the template be in the ubiquity/text/ namespace ...
<xnox> FourDollars: you just re-implemented ubiquity/text/live_installer for a second time =)
<FourDollars> xnox: OK. So maybe I can use ubiquity/text/live_installer to achieve my goal. :)
<FourDollars> Thanks. Let me try if ubiquity/text/live_installer works to me.
<FourDollars> ubiquity/text/live_installer doesn't work to me.
<FourDollars> I am working on a fork of dell-recovery.
<FourDollars> dell-recovery is an ubiquity plugin.
<xnox> FourDollars: did you edit the *.pot and *.po files? (e.g. sed s/Installer/Vendor Recovery/) did you rebuild .debs? did you upgrade and run updated debs?
<FourDollars> xnox: no
<FourDollars> Let me try again.
<FourDollars> Can I avoid to maintain a customized ubiquity?
<FourDollars> Can I avoid maintaining a customized ubiquity?
<cjwatson> You have to maintain a customised *something*; you can't do this entirely using preseeding.
<cjwatson> Given that, I don't think it's necessary to incur the code cost in ubiquity of helping you avoid maintaining a customised ubiquity
<xnox> FourDollars: a translation patch is easier than extra code in upstream ubiquity.
<cjwatson> And I don't think it would be appropriate, since branding usually involves more than just changing the window title, sooner or latere
<cjwatson> We are not going to start adding lots of customisation templates that allow you to override each one of our strings individually
<cjwatson> It would get very silly quite quickly :)
<FourDollars> But the plugin will only be run once before any other plugin, and then reboot when it finish. The following will be the general process of oem-config-gtk.
 * FourDollars is trying ubiquity/text/live_installer and hope it to work.
<FourDollars> Is it posiible to change the dialog title in an ubiquity plugin?
<cjwatson> FourDollars: It's slightly sketchy, but the PageGtk part of a plugin can access self.controller._wizard.live_installer which is the dialog object.
<cjwatson> (I think I've got that right.)
<FourDollars> cjwatson: Many thanks. :D
<FourDollars> Can I provide an empty ubiquity/custom_title_text to disable the dialog title?
<cjwatson> Not currently.
<FourDollars> cjwatson: self.controller._wizard.live_installer does work. Thank you.
<cjwatson> That could be done by being a bit more disciplined about how self.custom_title is handled in frontends: the default should be None, not False, and tests for it should be 'if self.custom_title is not None:' rather than 'if self.custom_title:'.
<FourDollars> cjwatson: Yes, that is great.
<Jasper> ev, xnox: it's easier for us to manage
<Jasper> ev, xnox: if we ship a GNOME module, it's nice to have bugs on GNOME, tarballs on GNOME, translations on GNOME, etc.
<ev> Jasper: so is bzr for us, though.
<cjwatson> You're going to hit a part of the stack you don't manage at *some* point
<Jasper> The plan was to have it be a git submodule.
<Jasper> mpt, mind if I see your designs?
<mpt> Jasper, https://wiki.ubuntu.com/TimeAndDate
<Jasper> I don't see much of a distinction.
<Jasper> ev, git submodules allow us to make a static library where consumers don't have to update to new APIs immediately -- they can be on an old commit or branch if they want.,
<Jasper> It's convenient in that way.
<mpt> Jasper, for example, "In the clock, show: (*) 12-hour time  ( ) 24-hour time" is clearer than "24 Hour Format                                      OFF/ON"
<Jasper> OK, I'll relay it on to our design team.
<Jasper> mpt, is this implemented in your g-c-c fork?
<Jasper> It's not substantially different enough that it might make sense to pull it upstream.
<mpt> Jasper, most of the differences are in two categories. That's the first one, where Gnome uses switches at the expense of clarity. The second is extra modality, for example having to go into a separate dialog to actually change the date and time, and a separate dialog to change the time zone.
<mpt> Jasper, as far as I know, our settings panel is in <https://code.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.04>. larsu or charles in #ubuntu-desktop could be more precise.
<Jasper> Thanks!
<xnox> Jasper: it would be great to share apis, the underlying datamap and etc. but i'd be worried if gnome devs go ahead and start breaking ability for us to maintain our design/ui to the point where we'd be forced to fork it again.
<Jasper> OK.
<xnox> Jasper: e.g. we see currently loads of changes in 3.X series which cause us in ubuntu to constantly revert commits (which break a11y in the installer, ability for apps to add pages/settings in system settings and etc.)
<Jasper> xnox, a11y bugs are always bugs. If you have issues with a11y, please, please report them upstream.
<xnox> Jasper: I understand that gnome leads and does amazing work, just give a little thought if there are downstream developers, e.g. collaborate =)
<Jasper> xnox, we don't mean to cause harm.
<Jasper> xnox, a11y regressions are taken very seriously upstream, so if you have issues, please report them. We've probably broken things accidentally.
<Jasper> a11y has been a moving target for 3.6 because we've been trying to turn it on unconditionally, so we've been trying to fix performance regressions, crashes, etc.
<Jasper> memory leaks
<xnox> Jasper: past all feature freezes there was some refactoring done to stop a11y on main-loop quiting, thinking that nobody restart main-loop second time around. Resulting in screen reader stopping in our installer, which happes to restart main-loops.
<xnox> https://bugzilla.gnome.org/show_bug.cgi?id=685453
<ubot2`> Gnome bug 685453 in gtk "If an application quits the main loop, and restarts it again, accessibility is lost." [Normal,Unconfirmed]
<xnox> in ubuntu we reverted that patch. Still unconfirmed upstream.
<xnox> and further indication that gtk wants to completely remove nested mainloops which will further break our software, with no consideration of wider software outside of core gnome.
<Jasper> Yikes.
<xnox> there are further indications of removing painting desktop background picture from g-s-d/nautilus "because it is all now done in gnome-shell" apart from distros that support other gtk based DE which don't have gnome-shell....
<Jasper> xnox, having background rendering in the compositor is the right thing to do.
<xnox> system-settings removed ability to have custom apps add in settings pages to system-settings via desktop files.
<xnox> instead all settings pages must be statically compiled in.
<Jasper> xnox, it's really unfortunate that the way it currently works is to punt a giant chunk of bitmap data over to X, which has to be rebound as a GL pixmap.
<xnox> Jasper: yeah =/ but surely all DEs need to paint a background picture so why not poll the 2-5 devs involved who has to do it anyway. Since making that gnome-shell specific will result in extra implementations using gtk outside of core gnome, which is an overall code debt.
<xnox> removing dynamic settings is silly.
<Jasper> xnox, gnome-settings-daemon is meant to be used with GNOME.
<Jasper> Having it in the compositor allows us to do rendering once, and then when we want to cross-fade, do compositing on the GPU.
<Jasper> xnox, the code for rendering backgrounds won't work for you guys, because we use Clutter.
<xnox> yeah, but on ubuntu/debian we have apps made by independent software developers which want good gnome integration of settings. we simply don't know about all of them at gnome-setttings-daemon compile time.
<Jasper> Er, sorry.
<Jasper> gnome-control-center is the thing that provides System Settings
<xnox> maybe I am wrong.
<Jasper> gnome-settings-daemon is the thing that provides background rendering, etc.
<xnox> which has been commented by gnome-settings-daemon maintainer to be removed and moved into gnome-shell.
<Jasper> It's called "gnome-settings-daemon" for legacy reasons.
<xnox> (as far as i know, it hasn't happened yet)
<Jasper> xnox, there's patches, and they're going to land for the 3.8 cycle.
<xnox> anyway, this cycle we are not using gnome rc, and using the last stable release.
<Jasper> xnox, the reason is that crossfading, etc. should be done on the GPU.
<xnox> because last cycle too many subtle things where getting broken for us with each dev/preview release.
<Jasper> xnox, sure, that makes sense.
<Jasper> xnox, the gnome-control-center story is an unfortunate story, and you can look at it from multiple ways.
<xnox> Jasper: i would welcome to share and use timedate with gnome and have it on gnome infrastructure. It just makes me sad that it may go and become fully "GNOME"....
<Jasper> xnox, in what way?
<Jasper> xnox, user testing showed that when people went to look for app settings, they looked for application menu items, they didn't go to the control center
<Jasper> xnox, so, we decided that applications should provide a menu item to bring up their settings panel, and we'd leave gnome-control-center purely for system settings.
<xnox> committing changes & releasing  gnome 3.X+1 which breaks in ubuntu indicators, ubuntu installer (the top two high profile use cases of that widgets).
<xnox> Jasper: good. our user testing is different, due to different desktop environment and how our indicators work. For us it currently still makes sense to have pluggable system settings, especially for those components that control "our" non-GNOME system components.
<Jasper> If you have non-GNOME system components, I'd make a branch of gnome-control-center which adds those components, not add pluggable modules back.
<Jasper> I don't know much about how your indicators work.
<Jasper> Apologies.
 * xnox is not involved in the desktop side of things. I'm mostly involved with foundations/core components. So my experience is a bit second hand (last minute pre-milestone cd respins with gtk bug fixes).
<xnox> Jasper: jhbuild bzr support is excellent! I wrote patches for it =)
<Jasper> OK.
<xnox> Jasper: but it's not about code/tarball/bugs location - it's about core-review, testing on !fedora and considerate development which has been lacking between ubuntu<->gnome for a while know and seems to only deteriorate.
<Jasper> Right, we have a new system.
<Jasper> cgwalters has been working on a new system called "ostree" which is designed to make full OS builds much easier.
<Jasper> Because he agrees: right now every few months we run a command, upload a tarball, and then wait for something to break.
<Jasper> Integration testing is something he's working hard to achieve.
<xnox> Jasper: we build daily gnome 3.X jhbuild in jenkins in our labs and run automatic as installed package testing to catch stuff. (since we need to be prepared for when 3.8 lands and we do a hop onto it)
<Jasper> Right.
<xnox> actively fixing bugs and creating workaorounds on our side.
<xnox> but it's not enough, currently.
<Jasper> Right, and that's what cgwalters is hoping to achieve.
<xnox> Jasper: in ubuntu projects were we are upstream: each merge proposal goes through code review, unit tests and integration tests (UI testing using xpresser) before being merged in trunk & automatically uploaded into the distribution.
<xnox> Jasper: are you happy willing to do that with timedate?
<Jasper> xnox, do what?
<xnox> for us ubuntu+1 is dogfood and always usable. we had a couple minor brakeges this cycle, but all were quickly resolved.
<xnox> https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog
<xnox> Jasper: smoke-test each commit before pushing to master and/or releasing tarballs.
<Jasper> xnox, of course
<Jasper> That's something we want to achieve.
<Jasper> I'll talk to cgwalters about integration xpresser.
<xnox> on our side, we figured our story out already with launchpad, bzr, jenkins, distro-uploads all working in orchestration. we are currently up on about 30% of our developed software doing this (mostly the desktop & high visible things) and we are ramping it up.
<Jasper> xnox, are all your tests open?
<xnox> the jenkins & testings is VCS agnostic and can work with git, but I am not sure about automatic package generates and uploads.
<Jasper> And can we integrate them back upstream?
<xnox> i need to check which bits are enabled and done. we primary focus on testing our unity/desktop stack. I'm not sure where / how / if at all timedate is being tested already or not.
<xnox> Jasper: most results are public here: https://jenkins.qa.ubuntu.com/
<Jasper> I mean the GNOME parts.
<cjwatson> We don't have a mechanism for closed-source tests
<cjwatson> (AFAIK)
<cjwatson> This is not a problem I'm keen to fix :-)
<Jasper> I don't quite understand Xpresser, but OK.
<Jasper> It seems to use images?
<Jasper> That would be quite annoying for us to rebuild images every time our artists modify the theme, so I'd be curious to hear how you handle it.
<Jasper> Do you force the default theme?
<xnox> Jasper: xpresser - images; autopilot - interspection. Tries to emulate user-activity and verify that correct things are displayed/painted/shown with timeouts on different hardware platforms.
<xnox> we mix in interspection =)
<Jasper> Do you have a page somewhere describing this?
<xnox> e.g. we had embarrassing bug on KDE desktop where "update notification" bubble did not pop-up post-release graphically, while the unit tests were passing fine =)))
<xnox> Jasper: talk to #ubuntu-quality or #ubuntu-unity folks on how it's done.
<Jasper> OK.
<xnox> we are meant to have developer tutorials / school week soon on how to do this.
<xnox> Jasper: dholbach is planning/organising that.
<Jasper> OK.
<xnox> gnome release shedule, ftp tarball / vcs / bug hosting so far doesn't  change nor improve anything for us apart from potentially hindering current qa integration.
<xnox> (release schedules got slightly out of sync nowaways I believe)
<infinity> xnox: Hey, do you know if there's any way to ask d-i nicely to create raid devices with old metadata formats (0.90 or 1.0 instead of 1.2)?
<xnox> you wish
<infinity> I really do.
<xnox> let me double check. I daubt it's possible.
<infinity> I guess I could create them by hand and then install to them?
<xnox> yes you can.
<xnox> mind the --home-hostname parameter name.
<xnox> and please make it match the $hostname
<xnox> --homehost that is
<cjwatson> infinity: why?
<infinity> cjwatson: https://bugs.gentoo.org/show_bug.cgi?id=198529
<ubot2`> bugs.gentoo.org bug 198529 in Core system "sys-boot/yaboot{,-static} mishandles RAID devices with v1.[12] metadata" [Major,Confirmed]
<cjwatson> another reason to use grub :0
<cjwatson> :P
<infinity> cjwatson: (Yes, that would be a non-issue if I used grub, but the inability to boot from a CD is irksome)
<cjwatson> wait, that bug prevents CD booting?
<xnox> infinity: you can use very old installer which had 0.9 metadata by default. (e.g. lucid?!)
<infinity> I mean boot the installed system from a CD's yaboot prompt.
<cjwatson> ah
<cjwatson> should really find a spare week to switch powerpc to grub properly ...
<cjwatson> (ho ho ho)
<infinity> Yeah, or that.  Now's a good chance to debug. :P
<xnox> infinity: you can override default metadata format in mdadm.conf and in udeb that is located in
<infinity> Though, the system under my desk is similar enough that we could debug there.
<xnox> /tmp/mdadm.conf
<infinity> Oh, indeed.
<infinity> ARRAY /dev/md/0 metadata=1.2 UUID=76175fcc:4b805933:48f9fd2c:fead070b name=sagari:0
<xnox> CREATE=0.90
<infinity> The question is, how and when does that get overwritten?
<xnox> that's during install. once the mdadm metadata created it will not be auto-upgraded.
<xnox> and always detected.
<infinity> The Gentoo bug implies I might want 1.0... Though 0.90 seems to work too, despite having "endian issues" (that's not a scary statement when tossed about unvalidated, nooo..)
<xnox> infinity: well yes, choose the one you want =) the higher the better.
<infinity> xnox: No, no.  I know metadata can't be changed post-create.  I mean that /tmp/mdadm.conf file, if I change it, will d-i just overwrite it? :P
<xnox> change it during partman/early-command
<xnox> cause by this time mdadm udebs are unpacked. yet nothing was started / done yet.
<infinity> I'm doing this by hand, not preseeding.
<infinity> Man, I wish I had more than one console...
<xnox> i tinker the stuff after udebs are unpacked but before partman started something like "username" step?!
<xnox> oh, you don't have another tty?! =)
<cjwatson> I usually poke about at the hostname prompt
<infinity> I have a serial console.
<cjwatson> so go back from that to the main menu and exec shell
<infinity> So, I get to exit/return/exit/return.
<infinity> Yeah.
<infinity> Well, except...
<cjwatson> by then everything should be unpacked ... although partman-md is a bit odd
<infinity> That file won't exist until one runs partman and tells it to create something, right?
<cjwatson> worst case, anna-install mdadm-udeb
<infinity> So, there's clearly a short window of opportunity to fool it.
<cjwatson> you could edit the partman script in question
<cjwatson> s'all shell ...
<infinity> Or that, yeah.
<infinity> Yeah, there's no window where I can edit that file in between defining and creating.  But I could just stop it and recreate it by hand, which might be sane.
<infinity>       127734656 blocks super 1.0 [2/2] [UU]
<infinity>       127734656 blocks super 1.0 [2/2] [UU]
<infinity> I win.
<infinity> Twice, apparently.
<infinity> xnox: I might give you a patch for an expert-only partman-md/metadata preseed.  Looks like it'd be trivial to inject it (as I just did with nano :P) into the create commands.
<infinity> Not that most people would ever need to care, but there are reasons other than esoteric bootloaders to prefer 1.0/1.1/1.2 (all the same, except for metadata placement)
<xnox> infinity: sure. i'll push it for jessie & our partman.
<xnox> infinity: should the default of mdadm package on powerpc be 1.0 until this is resolved in the bootloader?
<xnox> or whatever arch you are using.
<xnox> i guess that's too much.
<infinity> xnox: Nah, if you're trying to be magical, this is only required if bootloader=yaboot && array=place_with_kernel (so, /, or /boot)
<infinity> I'm sure there's enough logic hidden in partman to determine that, but it also sounds like a bit of effort to go to.
<xnox> hmm... we create arrays first, then assign mount-points to them. so not always detectable upfront.
<infinity> Oh, right.
<infinity> In fact, it gets really messy if you do array->lvm->ext4->mountpoint.
<infinity> Probably something better left to the mountpoint selector to bitch that its underlying array is the wrong metadata format.
<infinity> All in all, likely better for someone to either fix yaboot, or switch all yaboot-using systems to grub2. :P
<infinity> (not against both happening, really)
<infinity> grub's the obvious answer for the future, mind you, since yaboot has the same general limitations as lilo and others.
<infinity> It can only boot from "raid" if your "raid" happens to look suspiciously just like a normal partition. :P
<infinity> (ie: a mirror with no garbage blocks)
 * xnox is back to pretending to study "Life in the UK - Journey to Citizenship" book for my test.
<infinity> Sounds thrilling.
<xnox> infinity: yeah. Apparently while Britain was busy getting it's imperial swag on, potato crop failed and ireland suffered a famine. and other interesting facts of life that in scotland to buy a house one first goes to a solicitor, while in england to an estate agent.
<infinity> xnox: I fail to understand why a citizen needs to know these things, but good luck. :)
<xnox> it has all sorts of things: uk school education system, how many one gets time off work for holidays, maternity, paternity. how legal system works, how to pay taxes, get married and divorsed. it's a lot of stuff =)
<infinity> Oh sonofa... I forgot to install my custom kernel in the target system.
 * infinity head -> desk.
<stgraber> infinity: bah, who needs network post-install anyway ;)
<infinity> stgraber: No network would be fine.  No console is a bit less useful.
<stgraber> ah, no shiny kvm or usable IPMI console?
<infinity> stgraber: And, to make matters more hilarious, I assume d-i ejected my CD before it rebooted.  And the machine didn't suck it back in for me.  So, I need to sucker some poor DCE in Boston to go push the tray with his finger.
<stgraber> ;)
<cjwatson> infinity: For next time, boot the installer with cdrom-detect/eject=false
<infinity> stgraber: I have a lovely serial console.  But without a custom kernel, it no workie.  Said custom kernel is on the d-i CD that's not in the tray.
<infinity> cjwatson: There shouldn't be a next time past this one, cause I'll remember to install my kernel! :)
<cjwatson> You hope
<infinity> cjwatson: (But, yeah, belt-and-bracers, I'll remember the commandline too... And hopefully, I remember one of those two things)
<infinity> If only the firmware had an obvious "suck the CD tray back in, pleeeeease" option.
<stgraber> that's assuming the drive can physically do that ;)
<infinity> Can any of the ones built in the last decade not?
<infinity> Oh, I guess it might be a slimline laptop-style drive.
<infinity> Those are pretty common in rack machines.
<infinity> Fair point.
#ubuntu-installer 2013-01-17
<infinity> Ubuntu 12.04.1 LTS sagari hvsi0
<infinity> sagari login:
<infinity> Hey, that looks like a success.
<xnox> ev: did you compile resize2fs.exe yourself, or simply fetch the binary and cygwin1.dll  from cygwin.com?
<ev> xnox: I honestly don't remember
<xnox> =) ok.
#ubuntu-installer 2013-01-18
<pmatulis> i have 'finish-install/reboot_in_progress       note' in my preseed file (and no lines containing 'exit') and i find my new machines in a shutdown state.  i want them to reboot upon installation
<cjwatson> I assume you have "d-i " at the start of that line, or it will have no effect
<cjwatson> In any case, that only controls whether a dialog is shown just before exiting the installer
<cjwatson> Rebooting is the default if you haven't preseeded otherwise.  If the installer hasn't rebooted then it must not be able to ...
<cjwatson> As in, it will have been calling the "reboot" command
<pmatulis> yes, i have the d-i part.  i figured reboot is the default.  these are kvm guests so i guess they can't reboot for some reason
<bdmurray> xnox: bug 1100694 is regarding UbuntuKylin and appears to have a patch
<ubot2> Launchpad bug 1100694 in ubiquity (Ubuntu) "display OS in existing partitions" [Undecided,Confirmed] https://launchpad.net/bugs/1100694
<xnox> interesting. let me look.
<cjwatson> if you accept that, please remove the useless start/end comments, and advise them not to include them in future patches ...
<xnox> cjwatson: yeah. I'm not sure what it displays and how... given that one OS can span multiple disks and partitions.
<cjwatson> os-prober results, perhaps?  Or maybe they actually mean partition type?
<cjwatson> OMG what
<xnox> they display strings from misc.grub_options()
<cjwatson> So, uh
<cjwatson> Not quite
<cjwatson> They look up the device name for the partition, and try to match that against misc.grub_options()
<cjwatson> device path I mean, e.g. /dev/sda1
<cjwatson> That AT BEST needs a big comment explaining what it's doing, but I can't see how it makes sense; the described purpose would be better served by something involving os-prober
<cjwatson> But I'll let you figure it out properly and talk to them :-)
<xnox> =))))))
<xnox> yeah, but it will print nothing for "D:/" or like separate "/home", "/var" partitions....
<xnox> "D:\" that is.
<infinity> I don't think trying to say anything useful for non-system partitions is worth the effort.
<infinity> But os-prober -> icon mappings (or something) would be friendly for the normal "This is your Windows boot partition, doofus".
<xnox> infinity: I really don't want ooohhh i have this partition with windows and this one says nothing and i can reuse it, OMG i just formatted by D:\ with all of my Documents&Settings =(((( boo-hoo
<infinity> Well, you already display labels, right?
<infinity> (I'll admit, I haven't looked at this UI in a while)
<infinity> If you didn't give your D:\ an NTFS label of "Data" or "Storage" or "DON'T DELETE ME, ARGH", I'm not sure we can help you.  What's there to detect?
<infinity> "We scanned all the files on your partition and noticed some pretty compelling porn, are you sure you want to delete that?"
<infinity> xnox: In the modern world where Linux installers default to a single partition (not counting swap), and Windows is always on a single partition, anyone who has multiple partitions/disks did it on purpose, so they really should know.
<infinity> xnox: But my parents would probably find "Windows is installed here, no deletey" pretty handy.
<cjwatson> Saying "data" or "NTFS" or something is better than looking like it's empty.
<xnox> oem preinstalls with recovery partitions, excluded.
<xnox> true.
<cjwatson> Yeah, you have recovery partitions, separate Windows boot partitions sometimes, EFI specials, all sorts of little oddities
 * xnox over christmas "Dad, why did you wipe all data from your external hard disk?" "it asked me something & I click ok. There was no "D-E-L-E-T-E" in the prompt. It said something about "F-O-R-M-A-T" which is like defrag, right?!"
<infinity> Heh.
<infinity> Don't recovery partitions have a special type anyway?
<infinity> I vaguely recall they show differently in the Windows partitioner.
<kentb> cjwatson, I tested this morning's raring server iso for that 4k sector problem.  Still crashes in parted_server.   The right dosftstools deb is in the build, but, not the udeb...do I need the udeb, too?  bug 1065281
<ubot2> Launchpad bug 1065281 in partman-basicfilesystems (Ubuntu Quantal) "Installer crashed when trying to partition 4k/4k sector hard disks" [High,Triaged] https://launchpad.net/bugs/1065281
<infinity> Or maybe they just get the hidden flag set, usually.
<xnox> they do have magic files on them for windows to treat them "hidden" (that's what I saw), but it was just a normal NTFS/FAT partitions. But that's from ~XP era.
<cjwatson> kentb: Test this afternoon's, please :)
<kentb> cjwatson, doh! ok. will do :)
<cjwatson> kentb: I rebuilt recently for exactly that problem
<cjwatson> And yes, you need the udeb
<kentb> cjwatson, ok. cool
<infinity> xnox: Are you sure they're not type 17 instead of type 07?
<cjwatson> It went missing due to an LP snafu
<cjwatson> I was going to wait for the respin before asking you to retest ...
<xnox> infinity: that was like more than 8 years ago, I had to deal with that..... i don't have my parted logs handy.
<infinity> Anyhow, this all sounds like stuff that os-prober partially knows and could learn to be much smarter about.
<xnox> treu.
<cjwatson> Anyway, we don't have to do Kylin's work for them - get back to them, lay out the problems and invite them to do better
<infinity> Duplicating the logic elsewhere would be madness.
<xnox> ack.
<cjwatson> kentb: Thanks.  Nearly out of time for today - will probably have to return to it on Monday
<cjwatson> kentb: I think I may need the same trick with a desktop installation in order to get a traceback
<cjwatson> kentb: But you'd need to apply http://paste.ubuntu.com/1546175/ to /lib/partman/commit.d/50format_basicfilesystems by hand first
<kentb> cjwatson, ok. np.
<kentb> cjwatson, thanks for your help and have a good weekend
<cjwatson> Ah, hmm, I thought mkdosfs would autodetect logical sector size but it doesn't look like it
<cjwatson> That might explain it
<cjwatson> http://paste.ubuntu.com/1546203/ would help, but I think I'll leave that for now and just do it with blockdev
<kentb> cjwatson, ok. I'm pulling down the desktop iso now and will apply the basicfilesystems mods and see what I get
<cjwatson> kentb: actually, before that
<cjwatson> kentb: Would you mind trying a repeat of the server installation, but before you get to the partitioner, switch to tty2 and use nano to apply http://paste.ubuntu.com/1546211/ to /lib/partman/commit.d/50format_basicfilesystems?
<cjwatson> then save and exit, return to tty1, and continue
<kentb> cjwatson, ok. I'll try that right now.
<cjwatson> great
 * kentb whistles while the server reboots
<bdmurray> cjwatson: I looked into bug 1093819 and did not find /var/lib/dpkg/arch in the image
<ubot2> Launchpad bug 1093819 in Wubi "Wubi installed 12.10 amd64 without configuring i386" [Undecided,New] https://launchpad.net/bugs/1093819
<cjwatson> how strange, I'll have to look into that (next week)
<infinity> Oh, hrm.  That could be because the dpkg postinst only adds i386 as an arch on fresh installs, but dpkg is never a fresh install.
<infinity> (Since debootstrap unpacks it without running postinsts, then reinstalls it, IIRC)
<infinity> We paper over that in both d-i and ubiquity by explicitly adding the arch, I believe.
<infinity> Assuming my theory about debootstrap is right, I can't think of a sane way to fix that other than having wubi also do the requisite papering over.
<cjwatson> ah, yeah, or have live-build do it
<infinity> Or live-build, sure.
<infinity> live-build probably makes more sense.
<cjwatson> makes the livefs bigger due to the extra Packages files
<infinity> Though, if...
<cjwatson> so probably better not do it across the board
<infinity> Was just going to say that.
<cjwatson> maybe do it in livecd-rootfs just for wubi?
<infinity> Could do it as the step right after the final apt-get update.
<kentb> cjwatson, those modifications didn't make a difference :(
<kentb> cjwatson, so, I'll continue with the desktop iso and get trace
<cjwatson> kentb: can I have the new syslog?
<kentb> cjwatson, sure.
<cjwatson> infinity: right before ...
<cjwatson> infinity: we don't want to do it after for wubi, because then people don't have i386 indexes until they update
<cjwatson> wubi is a special case here due to the ghost-y nature of its installation
<infinity> cjwatson: Oh, I meant in the general case, but sure, could just do it very late for wubi-only.
<infinity> (And the apt-get update again)
<infinity> s/the/then/
<infinity> cjwatson: Conversation above saved in the bug for posterity (and so one of us remembers later :P)
<cjwatson> ta
<kentb> cjwatson, attached to bug
<cjwatson> hmm, I really wasn't expecting that ...
<cjwatson> kentb: do you still have it booted?
<cjwatson> Oh
<cjwatson> I'm an idiot
<cjwatson> partman-efi is the bit that's actually crashing
<cjwatson> kentb: OK, so never mind about the desktop CD, let me just go round and upload some more stuff and you'll get something a bit more sensible in the next build
<kentb> cjwatson, ok sounds good
<cjwatson> kentb: Can you just run two commands for me to confirm ...
<kentb> cjwatson, sure
<cjwatson> cat /var/lib/partman/devices/=dev=sdb/device
<cjwatson> blockdev --getss /dev/sdb
<kentb> cjwatson, first command outputs /dev/sdb~     second command outputs 4096
<cjwatson> excellent
<cjwatson> the ~ there is just an artifact of that file not having a newline at the end
<cjwatson> kentb: Just as well you didn't go through the code path I thought you did.  My previous paste was dangerously incorrect
<kentb> cjwatson,  ah! ok. got it.
<cjwatson> kentb: OK, uploaded another set of changes - though the number of brown-paper-bag uploads I've made just now suggest that I need to call it EOW
<cjwatson> in any case the next server build should be worth testing against
<infinity> cjwatson: We can just get more bags and expense them.
<kentb> cjwatson, ok. thank you!
<xnox> wallpaper "app" is borked in raring, even launching it directry via xinit doesn't paint, yet gnome-settings-daemon (which we are running) can paint the background fine.
<xnox> but gnome-settings-daemon is not available on flavours and may remove desktop painting code in the future.
<xnox> poking lightdm to see if it's possible to fix wallpaper "app"
#ubuntu-installer 2013-01-19
<stgraber> xnox: why lightdm? last I checked we were the "upstream" for wallpaper.c
<xnox> stgraber: note the comment at the top of it "mostly stolen from lightdm"
<xnox> stgraber: yeah, we are upstream. And it's not working with raring, and i'm not sure how or why.
<stgraber> xnox: yeah, then I rewrote half of it and didn't update the comment ;)
<xnox> stgraber: no worries, I was poking plymouth this whole time, as lightdm is still bzr branching.....
 * xnox any minute now "| Fetching revisions:Inserting stream:repacking texts:texts 922333/961583"
<stgraber> xnox: might be worth trying to revert my commit and see if it magically works without it. I had to do some weird tricks to get it working last time it wasn't painting but maybe I just ended up working around a bug that has since been fixed
<xnox> stgraber: hmm... let me try that.
<xnox> on the other hand in raring my networking is broken in the VMs so I am having fun fixing them - well whacking the hammer of purging all *kvm* and reinstalling.
<stgraber> ah yeah, the commit message reminds me of why I had to do it. metacity with compositing enabled (probably compiz too) didn't really like the old version of the tool
<xnox> maybe I should try enabling compositing in compiz then?
<stgraber> xnox: you're probably being hit by the NetworkManager flushes all the interfaces from virbrX bug :)
<stgraber> xnox: which was fixed a couple of hours ago
<xnox> oooh. let me upgrade and check =)
 * xnox didn't load compositing plugin in compiz.
<stgraber> I haven't tested the fix, but broken libvirt and lxc bridges was definitely the symptom ;)
<stgraber> hmm, compiz without compositing, that sounds weird ;)
<xnox> it's quick =) and awesome. I don't even let people move or resize windows.
<xnox> but I guess I will have to enable that =)
<xnox> due to error messages popups and cause users can click on URLs and open them by mistake.
<stgraber> sounds like something you'd expect from a window manager ;)
<xnox> yeah, apperantly it's a non-core plugin in compiz. Clearly rain-drops is a core plugin on the other hand.
 * xnox thinks compiz has their priorities right way around
#ubuntu-installer 2014-01-14
<bdmurray> superm1: bug 1268754 might be of interest to you
<ubot2> Launchpad bug 1268754 in ubiquity (Ubuntu) "crashed during installation" [High,New] https://launchpad.net/bugs/1268754
#ubuntu-installer 2014-01-15
<Ilario> Hi all!
<Ilario> Today I tried to install Trusty daily on my laptop and on my tower pc. On laptop no problem, on tower the boot process of the live usb (made using unetbootin) hangs.
<Ilario> You can see the tower pc specifications here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1266807
<ubot2> Launchpad bug 1266807 in xserver-xorg-video-nouveau (Ubuntu) "[NV44] Glitches in dash with GeForce 6200 SE TurboCache" [Low,Triaged]
<CarlFK> Ilario: did you try the (i forget the exact terms) fail safe boot modes?
<infinity> Ilario: Try to dd the iso to the stick instead of using a fancy tool.
<Ilario> @CarloFK, ok I'm going to try
<Ilario> fancy tool? Unetbootin? Ok...
<infinity> Ilario: "sudo dd if=foo.iso of=/dev/sdd BS=4M"
<infinity> Where sdd is your USB stick...
<infinity> Err, and bs, not BS.
<cjwatson> bs rather than BS, I think ..
<cjwatson> yeah :)
<infinity> My fingers hate me today.
<infinity> We really should do a sweep of all USB media creation tools in the archive and add a simple "if not trying to do fancy things like persistence && image is Ubuntu; then just use dd; fi"
<infinity> (And, of course, actually fix whatever they do wrong some day too, but given that 99% of people just want a dd image anyway...)
<Ilario> lol, btw ok, I'm going to overwrite my usb key with dd, then I'll try again
<Ilario> (btw some days ago the daily + unetbootin worked)
<ogra_> infinity, the one that did exactly that was ripped out last cycle (usb-imagewriter)
<Ilario> In the meanwhile, another question: could the installer install also some ugly but useful package like "linux-firmware-nonfree" when the user checks "Install this third party software" during the installation?
<Ilario> (and also some java plugin for firefox?)
<Ilario> and another question: shouldn't "account-plugin-irc" be installed by default as it is required to ask for help here?
<Ilario> Ok, the usb key made with dd hangs in the same way as did the one made with unetbootin:
<Ilario> [5....] Switching to clocksource tsc
<Ilario> [17...] random: nonblocking pool in initialized
<Ilario> then nothing
#ubuntu-installer 2015-01-13
<bdmurray> Is there somebody who could look at bug 1408495?
#ubuntu-installer 2016-01-18
<gpiccoli> Hellom how are you doing? Sorry to bother. I have a question regarding iSCSI during installer
<gpiccoli> Is it supported, right?
<gpiccoli> How can we set the initiator name of the installer? Is there some automatic configuration?
<gpiccoli> My target refuses to "be recognized" since it's initiator name is not configured on target
<cyphermox> gpiccoli: I suppose the initiator name might be the hostname?
<cyphermox> iscsi should be supported, but you might need to enable it first, and unfortunately I'm not familiar enough with iscsi to know all the details
<cyphermox> ok, looks like when you boot you need to set, on the command-line:  partman-iscsi/login/address
<cyphermox> and
<cyphermox> and it should be asking you for a username, which would be the initiator username...
<cyphermox> xnox: can you help me out? ^ I thought you played with iscsi before?
<gpiccoli> Thanks very much cyphermox!
<cyphermox> sorry I can't be more helpful, but I never touched iSCSI at all
<gpiccoli> I could access iSCSI my manually mounting it on shell, "faking" the initiator name as one already set on target
<cyphermox> ok, good
<gpiccoli> after this, next test was to stop installation at beginning and override the isci-start procedure to force my initiator name to match the one already on target - worked too
<gpiccoli> I think I need more to know if it's expected my target accept any initiator name since Ubuntu installer will generate a random one each install
<gpiccoli> Hope you or xnox can help me figure what is expected!
<cyphermox> cjwatson: do you recall if there's a reason why prep is being dd'ed to only in grub-installer, and not in a commit.d script in partman-prep?
<cjwatson> cyphermox: because it's grub-installer that has the information on the intended disk to boot from; we need that context to work out the right PReP partition in multiple-disk cases
<cyphermox> ok, so can't dd on any other prep, gotcha
<cyphermox> I was asking because we do create a prep partition while partitioning
<cjwatson> indeed
<cyphermox> thanks
#ubuntu-installer 2016-01-19
<xnox> cyphermox, cjwatson: apt-setup/security_host, mirror/http/hostname, time/zone (or tzsetup/geoip_server), clock-setup/ntp-server (on supported arches) are all the things needed for non-stalling installations, when *.ubuntu.com is resolvable, but not routable.
<xnox> thanks a lot for your help! customer is happy =)
<cyphermox> ack, ta
<xnox> cyphermox, "the installation took place at warp speed" =)
<cyphermox> yeah I can imagine
<cyphermox> it helps a lot when things are preseeded anyway
#ubuntu-installer 2016-01-23
<xnox> cyphermox, infinity https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1537289
<xnox> and specifically https://launchpadlibrarian.net/234960187/d-i-kernels.png
<xnox> does that look right?
<cyphermox> xnox: I've seen that on not s390x
<cyphermox> I'm not sure if it means I broke base-installer when I merged it.
<xnox> cyphermox, ok. so it's not arch specific =) is it user-friendly though? do we really want people to shoot themself and install a non-metapackage kernel?
<xnox> hm. i really can't remember if it used to look like that.
<cyphermox> definitely not in all cases, I can't remember when exactly this comes up
<xnox> cyphermox, i somehow thought that e.g. 14.04.x had like "generic, lowlatency, lts-utopic-generic, lts-utopic-lowlatency" options. E.g. all the types of meta packages.
<cyphermox> definitely does not with the typical mini iso though, I installed a few on ppc64el already
<cyphermox> I understand what you mean, the numbered ones may be an error
<xnox> i'll try a trusty point release, cause hopefully that is using an "acient" base-installer et.al. and check how things look there.
<xnox> hm. not sure what i have done, trusty netinst is not offering me a choice of kernels =(
 * xnox really should stop working.
<xnox> good night!
<infinity> xnox: You're not supposed to be offered a choice of kernels.  If you are, someone screwed up a merge.
#ubuntu-installer 2017-01-17
<xnox> infinity, does it mean I can squeeze in a netcfg sru? =)
<dmj_s76> cyphermox: Any progress on the double top panel bug?
<dmj_s76> With 16.04.2 being delayed, this might be a good thing to get into the iso if we can get it fixed soon.
<cyphermox> dmj_s76: good that you ask, I have a fix in my PPA for you to test
<dmj_s76> cyphermox: newer than the broken one from last week, yes?
<cyphermox> well, I had tested it and it was working, but maybe the issue was just how complicated it is to test this kind of stuff
<dmj_s76> I'll test again :)
<infinity> xnox: Depends on how invasive it is.
<cyphermox> dmj_s76: you might want to just rip the panel binary from the ubiquity-frontend-gtk package and insert it on the system
<dmj_s76> infinity: fairly non-invasive assuming it's fixed by the current tweaks.  Two line fix change in one file.
<cyphermox> dmj_s76: oh, that's right, I was uploading you a fixed up iso
<dmj_s76> oh...link?
<infinity> dmj_s76: Hrm?  I was talking about xnox's netcfg...
<dmj_s76> infinity: oh...nvm then
<xnox> infinity, https://launchpad.net/ubuntu/+source/netcfg/1.138ubuntu3 but ignore po updates
<xnox> infinity, and http://launchpadlibrarian.net/301782792/netcfg_1.138ubuntu2_1.138ubuntu3.diff.gz
<xnox> both are cosmetic and nice to haves, just UX and strings presentation (show Ethernet, instead of Unknown interface on all arches; and do not show option "4: ," for wifi on s390x)
<xnox> without breaking any existing translations
<xnox> locations are changed in the tempalate, but no strings changed, nothing fuzzy
<xnox> i'll upload tomorrow and let you check it out =)
<cyphermox> dmj_s76: http://people.canonical.com/~mtrudel/custom.iso
<cyphermox> that's a zesty iso I frankensteined with the right file in the right place, but it should be pretty representative.
<dmj_s76> cyphermox: great, will try it out
<dmj_s76> taking a while to download :P
<cyphermox> yeah, no way around that
<cyphermox> the other option is to take the panel binary from ubiquity-frontend-gtk and injecting it in the right place on the image, using break=bottom
<cyphermox> (and another device to get the file from)
<dmj_s76> meanwhile...3 other hidpi bugs need my attention
<cyphermox> and not mine?
<dmj_s76> #multitasking :P
<dmj_s76> cyphermox: Also, our newest System76er is also working on a different ubiquity bug today.
<cyphermox> ok
<dmj_s76> He's got the suggested fix in his branch as of a few minutes ago.
<dmj_s76> http://bazaar.launchpad.net/~jackpot51/ubiquity/ubiquity/revision/6506
<cyphermox> ping me if there's anything, I'm actually off hacking at networking stuff unrelated to ubiquity, and not paying much attention to IRC
<cyphermox> dmj_s76: now for that test what I'll want to know is: whether the panel is very large, with a big accesibility icon as before, but without the "doubling" effect of the gradient in the panel, or if nothing changed ;)
<dmj_s76> cyphermox: you got it!
<cyphermox> or if the panel is now the right size with icons more or less all looking the same size and the gradient being ok
<cyphermox> and I should see about getting hidpi hardware.
<dmj_s76> cyphermox: So first testing shows that the panel is still double height.
<dmj_s76> The "doubling" effect is gone.
<dmj_s76> Instead of repeating the pattern, the panel now looks normal for the top half and is a solid color for the bottom half (matching the color of the bottom row of pixels from the top half)
<xevious> I've got a hidpi laptop (2013 MacBook Pro Retina 15"). Is there anything I can do to help?
<xevious> Or is 2880x1800 not hi enough? (ie. Are you focused on 4k+?)
<dmj_s76> xevious: Do you use it at 2x scaling factor?
<dmj_s76> (equivalent to 1440x900)
<dmj_s76> xevious: That's not quite the ideal for a hidpi screen, (Apple ought to be choosing 4K for 15" models) but it definitely falls into the hidpi category.
<dmj_s76> xevious: Unity should be setting scaling for you automatically soon.
<xevious> I use the scaling factor that's equivalent to 1680x1050.
<xevious> There are very few things I ever notice pixels in. Unfortunately, Quassel is one of them.
<dmj_s76> I see.  You're not actually getting scaling equivalent to 1680x1050, since GTK3 can only truly scale to integer multiples.
<dmj_s76> If you try scaling between what you have now and integer multiples, you'll notice some funky ways toolkits lay things out.
<xevious> Yes, I've definitely noticed funkiness.
<xevious> I rarely boot Linux on this thing, since macOS is so much better optimized for battery life.
<dmj_s76> How Unity is compensating is to use accessibility features to split the difference.
<dmj_s76> xevious: If you're feeling like testing hidpi, you could see how this is in zesty currently: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1649736
<dmj_s76> or take a look at this bug that cyphermox and I are working on: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1622686
<xevious> The second one seems easier to test, since I can just write the ISO to a stick and boot it.
<xevious> The other one would require me to get a completely out of date Ubuntu (15.10 I think?) partition updated to zesty.
<dmj_s76> cyphermox: I wonder if lack of hidpi support in the humanity icon theme is the reason
<xevious> I'll let you all know what my laptop does when I boot the custom.iso that cyphermox linked to above.
<xevious> ...whenever it decides to finish. It's going pretty slowly.
<cyphermox> dmj_s76: no, it's just code; it ought to be picking the right size for the panel
<cyphermox> now, the color thing is because of the change from REPEAT to PAD, but the height is still wrong
<dmj_s76> cyphermox: yep, that's what my testing shows
<dmj_s76> cyphermox: So, actually it is the humanity icon theme that's causing the double height
<dmj_s76> *however* I think the patch will fix another minor look issue
<dmj_s76> will let you know if so in five minutes
#ubuntu-installer 2017-01-18
<dmj_s76> cyphermox: Your patch actually improves the appearance when the panel is the correct size.
<xevious> Only about 20% of custom.iso has downloaded so far, in case you're wondering why I haven't given any feedback yet.
<cyphermox> that's fine, I knew it would take long, nothing I can do about it
<dmj_s76> cyphermox: I've added my results to the bug report
<dmj_s76> cyphermox: Notice the small little band of incongruous pixels?
<cyphermox> heh, that's PAD; I was afraid that might be a side-effect of trying to fix things that way
<dmj_s76> Afraid?
<dmj_s76> That bright little line has been commented on as a potential bug by a few people here.
<dmj_s76> cyphermox: So PAD isn't perfect (this right thing would be to make the gradient actually match the height of the panel), but it looks better to my eyes than repeat.
<cyphermox> there are only two options, what this means is that there ought to be a different way to fix the height to be correct, but I don't know what it is
<dmj_s76> me neither
<dmj_s76> Also, humanity @2x should fix the double height
<dmj_s76> will get on that tomorrow
<xnox> cyphermox, when launching manual partitioner would you expect to see all LVM volumes that are present on the visible devices or not?
<xnox> at the moment i have a strange mix of in "Configure LVM" i see 4 logical volumes; yet none are present in the "manual partitioning menu" to e.g. pick some existing logical volume to be for example /srv
<xnox> aha
<cyphermox> maybe LVM only probes when you first run into Configure LVM?
<xnox> did "rm /var/lib/partman/lvm" rerun detect disks again, and they appear
<cyphermox> hrm
<cyphermox> that sounds all wrong
<xnox> so it keeps a flag to run "pvscan/vgscan" only ones.
<cyphermox> that is possible, yeah
<xnox> deffinately. Trying to reproduce and troubleshoot this bug: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1570580
<cyphermox> that said, usually if you don't see things you go configure LVM/iSCSI/whatnot and when you get back to the main partitioning menu they show
<xnox> which kind of boils down to: i can see volumes on normal drives; but not on the multipath assembled drives
<xnox> and i think lvm re-detection is not done after multipath is assembled.
<cyphermox> right
<xnox> well that's what i did here, and in that menu they _were_ visible. I even tried to make a change (e.g. remove one volume) and "finish" and yet the other one did not show =(
<cyphermox> look at the hysterical data for partman-multipath, we may have changed that when mauricio did other multipath changes
<cyphermox> I think we removed it because scanning the way it was being done might find LVM first and keep you from activating multipath?
<cyphermox> but that doesn't make sense now that I think of it
<xnox>  /o\
#ubuntu-installer 2017-01-19
<cyphermox> xnox: did you manage to make sense of the lvm thing now?
<xnox> cyphermox, i cooked dinner instead =) but i do have that machine still in d-i for me to return to.
<cyphermox> ack
<xnox> but somehow, I have more improtant things to fix before going to ski on saturday =/ so shelving to february that lvm thing
<jackpot51> Using the OEM installer, immediately after the user finishes configuration, connected WiFi networks are dropped and networking is unavailable until a reboot or a restart of network manager
<jackpot51> I have a patch for wpa_supplicant.service that prevents it from being killed by the systemctl isolate graphical.target that happens after oem configuration
<jackpot51> who should I talk to?
<dmj_s76> cyphermox: So I've uploaded a branch for Humanity with @2x icon support.
<dmj_s76> cyphermox: Here's a fix for the doubler height bar in ubiquity https://code.launchpad.net/~dmj726/humanity/hidpi-2x/+merge/315166
<dmj_s76> for trunk anyway.
<dmj_s76> I've got variations for xenial and yakkety in the system76 daily ppa.
<cyphermox> Won't that just make the icons bigger and keep the weird sized panel
<dmj_s76> cyphermox: Nope!
<dmj_s76> On 16.04 it makes many icons smaller, in particular in Nautilus.
<dmj_s76> It also makes the a11y icon in the top panel smaller in Ubiquity.
<dmj_s76> The @2x tells the toolkit to use the original icon for hidpi, but scale it correctly.
<dmj_s76> I suspect without the fix, Ubiquity's panel is both using the bigger icon and then scaling it up.
<dmj_s76> current humanity: https://launchpadlibrarian.net/302130871/hidpi%20oem%20doubled%20panel%20bug.jpg
<dmj_s76> humanity with @2x support: https://launchpadlibrarian.net/302869844/ubiquity%20panel%20cairo%20extend%20mode%20patch.jpg
<dmj_s76> "patch" in the second image refers to your CAIRO_EXTEND_PAD patch
<dmj_s76> cyphermox: ^^
<cyphermox> alright
<cyphermox> so we do want to PAD fix, but also the changes to the icon set, cool
<cyphermox> for the icons, apparently I'm a member of the right team, but please ask on #ubuntu-desktop to make sure someone can chime in
#ubuntu-installer 2017-01-20
<xevious> cyphermox: I finally got around to booting that custom.iso. Here's what it looks like on my laptop: http://imgur.com/a/16H89
<xevious> It's what I was picturing based on what you and dmj_s76 had described.
<dmj_s76> xevious: Thanks for taking a look at that.
<dmj_s76> xevious: It turns out the double header results from an issue with the Humanity icon set.
#ubuntu-installer 2019-01-15
<acheronuk> cyphermox: haven't been able to dig too deep without getting lost, but at least one big cause og LP: #1810647 seems to some big and dubious looking changes in the generated kbdnames.gz in the 19.04.x onwards builds
<acheronuk> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1810647
#ubuntu-installer 2019-01-20
<ysteins> I translated the Ubuntu installer to Norwegian Nynorsk in August, but many of my translations were not merged into Cosmic. I also see that they have not been merged into Disco (booted a live image and checked). Is there an extra step involved that I have missed? My translations are all set to 'current', see for instance https://translations.launchpad.net/ubuntu/cosmic/+source/ubiquity/+pots/ubiquity-debconf/nn/+translate
