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