=== robbiew is now known as robbiew_ [10:45] ubiquity: evand * r3676 ubiquity/ubiquity/frontend/gtk_ui.py: Missed one spot that had a bgo 56070 workaround. [10:53] 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 :-) [10:55] 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. [11:13] the other constraint might be that gettext restricts msgids to ASCII-only [11:13] or strongly recommends, anyway [11:14] this is apparently because if gettext doesn't find a translation it returns the msgid unchanged without doing any recoding [11:14] 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 [14:55] grub-installer: cjwatson * r833 no-device-map/ (debian/changelog grub-installer): Use an appropriate OS device name rather than (hd0) if possible. === robbiew_ is now known as robbiew [15:16] perhaps its best solved in en_* then. [16:03] heya anyone alive >.> [16:11] cjwatson, michaelforrest: (bug 414912, bug 336751) thoughts? http://people.canonical.com/~evand/tmp/transitions.html [16:11] Launchpad bug 414912 in ubiquity "Poor progress feedback for Back/Forward on slow machine" [Undecided,New] https://launchpad.net/bugs/414912 [16:11] Launchpad bug 336751 in ubiquity ""Starting up the partitioner" uses separate window misleadingly" [Low,Confirmed] https://launchpad.net/bugs/336751 [16:11] I'm afraid it's even more jarring than the existing version. [16:12] ev: I was hoping we could use a status bar or something [16:12] I agree this is pretty jarring [16:13] I like what you've done with the manual partitioner though! [16:13] thanks [16:13] I think I need to smooth that out a bit [16:13] ev let's talk about this in a bit [16:13] (I am about to go to a meeting ) [16:14] michaelforrest: sure thing [16:14] does it disable the UI when the spinner is up in the manual partitioner? [16:14] yes [16:14] 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 [16:14] Launchpad bug 336751 in ubiquity ""Starting up the partitioner" uses separate window misleadingly" [Low,Confirmed] https://launchpad.net/bugs/336751 [16:14] cjwatson: indeed, that's what I was going off of [16:15] it's a shame he's not around, but perhaps michaelforrest (when he gets back) understands what mpt's reasoning would be [16:15] I'm concerned at that sort of declaration since it seems that the result is things looking much worse :) [16:15] agreed [16:16] 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? [16:16] I don't know what's consistently available ... [16:16] ikt: replied to your mail [16:16] the space between step X of X and back forward next [16:16] err quit back forward [16:16] that's about it :) [16:17] for what it's worth, this is all in ~ev/ubiquity/progress_indicator [16:18] PyGTK 2.17.0-0ubuntu2 just hit the archive with GtkSpinner [16:21] ubiquity: cjwatson * r3677 ubiquity/ (10 files in 4 dirs): [16:21] ubiquity: Add a context manager (raised_privileges) and a function decorator [16:21] ubiquity: (raise_privileges) that are equivalent to a [16:21] ubiquity: regain_privileges/drop_privileges pair, but that wrap up the required [16:21] ubiquity: try/finally logic to make it less likely that we'll end up at the wrong [16:21] ubiquity: privilege level by mistake. [16:24] cjwatson: cheers :) [16:36] ubiquity: cjwatson * r3678 ubiquity/ (debian/changelog ubiquity/auto_update.py): [16:36] ubiquity: When attempting to upgrade the installer, only stop debconf-communicator [16:36] ubiquity: once we've determined that we actually have something to upgrade. [16:59] grub-installer: cjwatson * r834 no-device-map/ (debian/changelog grub-installer): [16:59] grub-installer: When installing from non-CD media, we only need to reset the default [16:59] grub-installer: boot device if we would otherwise end up installing GRUB to the [16:59] grub-installer: installation media. [17:26] ubiquity: cjwatson * r3679 ubiquity/debian/ (changelog control): Require Python 2.6, for the 'with' statement. [18:42] grub-installer: cjwatson * r835 no-device-map/debian/changelog: grammar [18:43] ubiquity: cjwatson * r3680 ubiquity/ (6 files in 4 dirs): [18:43] ubiquity: Move default GRUB target calculation to ubiquity.misc, which is a better [18:43] ubiquity: location for common code than ubiquity.components.summary. Try to avoid [18:43] ubiquity: using (hd0) as the target (prefer the first device from grub-mkdevicemap [18:43] ubiquity: output if possible), and, when installing from a non-CD medium, only [18:43] ubiquity: reset the default boot device if we would otherwise end up installing [18:43] ubiquity: GRUB to the installation medium. [18:59] ubiquity: cjwatson * r3681 ubiquity/debian/changelog: LP: #508725 appears to be fixed by debconf-communicator work === stgraber_ is now known as stgraber [19:14] localechooser: cjwatson * r154 ubuntu/debian/changelog: releasing version 2.12ubuntu3 [19:21] hya - anyone working on patman-iscsi ? [19:22] partman-iscsi, that is [19:25] ubiquity: cjwatson * r3682 ubiquity/debian/changelog: r3678 fixes LP: #495175 [19:26] 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 [19:33] cjwatson: i've managed to launch the Lucid's installer via PXE and installed in iscsi-root (<- it has *really* improved even since Karmic! ;-)) [19:34] cjwatson: but the generated /etc/iscsi.initramfs is wrong.. it has $*USERNAME* ans $*PASSWORD* set to "" which leads to no avail while initramfs-hook starts logging in that target [19:35] it should be left out completly or at leadt set to ="" [19:35] least.. [19:39] (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..) [21:20] Lyaa: hmm. could I see the installer logs? /var/log/installer/syslog and /var/log/installer/partman, particularly [21:21] 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 [21:21] Lyaa: I'd like a copy of iscsi.initramfs as well [21:25] hmm.. is there a reason ubuntu still doesnt support being installed as a domU [21:26] 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 === dmarkey_ is now known as dmarkey [21:27] cjwatson: that does the trick ;-) [21:27] cjwatson: so now my nics get (re)numbered according to udev-rules in the running system [21:29] cjwatson: about the log files: any special sub part of them to nopaste? or complete logs? [21:32] 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.. ) [21:32] cjwatson: however, i have the partman log [21:40] . o 0 ( hmm .. and i've killed the lines from iscsi.initramfs rather than commenting them.. ) [21:41] i guess i'm a louzy bug reporter.. [21:41] :) [21:47] Lyaa: you killed sysklogd in the installer? [21:47] Lyaa: the net-persistent stuff should already be copied, if it isn't that's a bug [21:48] cjwatson: ha! .. found the original : http://paste.ubuntu.com/359236/ [21:48] hmm. indeed it isn't. we should fix that. [21:48] Lyaa: complete logs> always [21:51] btw: kernel cmdline "... blacklist=particular_module..." is not honored either by init-premount/blacklist [21:51] hang on, I can't deal with all this at once :) [21:51] take your time :-) [21:52] Lyaa: can you answer "you killed sysklogd in the installer?" [21:54] 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 [21:54] as i said, it's a diskless machine with only 64MB ram .. [21:55] and tht seems to be too low for current d-i [21:55] drat [21:56] additionally i've unloaded some modules that were autoloaded by the installer (like: filesystems that are not used further on (i.e xfs, jfs, ..) [22:01] 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 ;-) [22:01] yeah, I'm looking into that part of it now [22:01] there is certainly wrong, it's just a matter of detecting that gracefully [22:02] hoping to avoid a simple string comparison [22:02] is that a string/scalar representation of a null-value? [22:03] looks like I may not have a lot of choice [22:03] apparently so [22:04] I don't see a way to distinguish between a username that's genuinely "" and a NULL value. OTOH "" probably isn't allowed by the iSCSI spec anyway so ... [22:05] hmm .. don't try to parse it in the init(ramfs) script but while generating that value ? [22:05] that's what I'm doing. [22:05] no offense :-) [22:05] but the text itself is generated inside the kernel. [22:05] so I can't actually intervene there. [22:07] so actually emit some warning during install: "what?!? no password on the target? that's insecure!" - fix your security and set a password" :-))) [22:08] no [22:08] partman-iscsi: cjwatson * r44 ubuntu/ (debian/changelog init.d/iscsi): [22:08] partman-iscsi: Cope with "" text in username, password, username_in, and [22:08] partman-iscsi: password_in files. [22:08] ^- that [22:09] partman-iscsi: cjwatson * r45 ubuntu/debian/changelog: releasing version 11 [22:10] is that also an issue for backports to 9.10..? [22:11] no, because 9.10 didn't have iSCSI authentication support [22:11] oic [22:11] not that I can effectively change the 9.10 installer anyway [22:11] it is what it was [22:14] so now i still have to dive into initramfs to get early swap on that target - still experiencing OOM there.. [22:14] Lyaa: is http://paste.ubuntu.com/359249/ reasonably close to what you used in your initramfs hook? [22:14] . o 0 ( 64MB is not state of the art .. sigh ) [22:17] 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/ [22:17] I'm hoping that this fixes bug 473036 [22:18] Launchpad bug 473036 in partman-iscsi "iscsi-root install will only use net0 for iscsi-target connectivity" [Undecided,Incomplete] https://launchpad.net/bugs/473036 [22:19] ..but it's been just a quick hack [22:19] near enough equivalent then. [22:19] (except for my inability to spell /etc/udev/rules.d, apparently) [22:20] you're copying to /lib/udev/rules.d/ instead, but udevd should look in both places. [22:20] actually, i've tried to blacklist the other nic-module using /proc/cmdline parsing by blacklist - that failed [22:21] that's outside my area of expertise [22:21] best to file it as an initramfs-tools bug, I think [22:21] but that will obviosly fail if you have two nics using the same driver [22:22] I think I might talk with our udev maintainer about this, rather than going ahead and fixing it right away [22:22] the NFS and NBD paths have essentially the same problem [22:23] and I don't see why 70-persistent-net.rules shouldn't just be universally copied in, really [22:24] 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 ;-) [22:24] it's the real udev but with a cut-down configuration [22:24] the reduced tools are sometimes more trouble than they're worth [22:26] 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.. ;-) [22:27] this category of problem is what the persistent rules files are for [22:28] 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 [22:28] eww. why was that worth it? [22:28] IOW why does the naming matter? [22:29] the machine has two nics - one is on-board.. and that's the (only) one with PXE.. [22:29] as long as they're the same from installer through initramfs to running system, it shouldn't matter? [22:30] and it boots from it - altering the name during boot and run mostly leads to even more fuzz.. [22:30] I'm confused, and want to understand this [22:31] why does it matter whether eth0 is the PXE one? PXE-booting should be before Linux assigns names, and independent of it [22:31] the machine detects the on-board first and does not initialize the PCI-card [22:33] 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 [22:33] 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 [22:33] it's entirely possible for the first device that's detected to be assigned eth1 [22:34] and you know by yourself, it does only probe for iSCI on device "eth0" ;-) [22:35] but that is not true? [22:35] or at any rate it is certainly not supposed to be true! [22:36] it's supposed to try bringing up all interfaces [22:36] and the other nic points in another network which does not reach the iscsi target [22:36] hmm? [22:37] 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 [22:37] thank you, that clarifies things [22:37] it does - but the Kernel bringing the PCI card up as eth0 and tries to get a hold for the Target on that nic [22:38] the kernel does what it's told by userspace, in this regard [22:38] the kernel does not do iSCSI login by itself [22:38] as far as I can see, eth0 is not hardcoded anywhere relevant [22:38] if it is, we should fix that, but I don't believe it is [22:39] right - you may work around this by specifying "ip=all" on Kernel cmdline [22:39] whoa, wait a sec [22:40] OH, I see now [22:40] ./conf/initramfs.conf:65:DEVICE=eth0 [22:40] silly thing [22:40] OK, I take it back that it isn't hardcoded [22:40] then ipconfig probes DHCP on all nics - but then booting takes like ages on timeouts when one nic has no link [22:41] so we need partman-iscsi to remember the network device used [22:41] regrettably, I'm not sure I can find this in /sys ... [22:42] hmm .. some "ip route show | grep $TARGET_SUBNET | grep_for_dev"-magic..? [22:43] 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? [22:43] the installer normally only brings up one network device, IIRC [22:45] at the moment, I'm thinking of remembering the network device selected in netcfg in ISCSI_NETDEVICE in iscsi.initramfs [22:46] i've selected eth0 in d-i .. but that had been after I altered the device names in udev [22:46] but that should work out [22:47] grrr... I seem to be causing Ubiquity to crash somehow. :/ [22:47] Lyaa: eth0 (pre-renaming) was the right device to use for iscsi, then? [22:49] nah - Kernel, d-i, some userspace, whatever would called that nic "eth1".. so i swapped the name right before entering the "Network configuration" item [22:49] then it had been displayed as "eth0" [22:49] 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. [22:49] OK. So all we need to do is lose that renaming and remember that we should use eth1 at initramfs time. [22:50] cjwatson: think so [22:50] cody-somerville: only if user-setup/allow-password-empty is set to tru [22:50] true [22:51] cjwatson, I have that. And d-i passwd/user-password{,-again} password [22:52] * cody-somerville takes a peak at ubiquity's source. [22:54] It looks like I might want to use the ubiquity in karmic-updates before moving forward. [22:57] I'm not convinced ... [22:57] I suggest using ubiquity --debug in the first instance [22:58] getting a full debconf trace is usually the quickest way to attack these problems [22:58] then show the full log [22:58] (/var/log/installer/debug - use a non-valuable password!) [23:00] /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. [23:00] I'll try running ubiquity with --debug [23:02] you don't have any other odd backports of things like shadow or pam, do you? [23:02] Nope. Just pointing at karmic. [23:02] I'm at a loss just now, then [23:03] I don't see any interesting changes in user-setup [23:03] 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. [23:06] 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 [23:30] user-setup: superm1 * r77 user-setup/ (debian/changelog user-setup-apply): [23:30] user-setup: Fix automatic login on situations where custom.conf didn't exist [23:30] user-setup: already on the target. [23:31] user-setup: superm1 * r78 user-setup/debian/changelog: releasing version 1.28ubuntu3