[01:20] partman-base: cjwatson * r83 ubuntu/ (debian/changelog partman): [01:20] partman-base: * Backport from trunk: [01:20] partman-base: - Don't emit confusing log messages if partman-lvm or partman-crypto are [01:20] partman-base: already loaded. [01:22] partman-base: cjwatson * r84 ubuntu/ (commit.d/parted debian/changelog lib/base.sh): [01:22] partman-base: - Allow disable_swap to take a device argument, in which case it only [01:22] partman-base: disables swap on that device rather than on all devices. [01:22] partman-base: - Only disable swap on devices that are being changed (LP: #199048). [01:28] partman-partitioning: cjwatson * r670 ubuntu/ (debian/changelog lib/disk-label.sh lib/resize.sh): [01:28] partman-partitioning: * Backport from trunk: [01:28] partman-partitioning: - Only disable swap on devices that are being changed (LP: #199048). [01:28] partman-partitioning: Requires partman-base (>= 114ubuntu4). === superm1 is now known as Daviey_ === Daviey_ is now known as superm1 [09:05] when i install the ubiquity in my system , the error follows WARNING: Undefined kernel key code for 214 [09:38] cjwatson, i am getting when i install from live cd to my harddisk [09:40] that is not a fatal error [09:40] you can just ignore that [10:00] cjwatson, i ignored then also the error is coming [10:00] I can't understand that sentence, I'm afraid [10:00] cjwatson, i am not able to fix the root partitioon [10:00] we need a bug report with full logs [10:01] cjwatson, it is giving the error like ???? [10:01] http://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs; we need /var/log/syslog and /var/log/partman [10:02] cjwatson, ok i will send [10:02] (if you've already installed the system and rebooted, those files will be /var/log/installer/syslog and /var/log/installer/partman instead) [10:03] cjwatson, see the link http://pastebin.com/m7bcb2875 syslog file [10:04] please file a bug report [10:04] I can't look at it right now [10:04] that looks just hosed though. Check your CD integrity and that your CD drive is clean [10:04] "# [10:04] Mar 20 15:06:03 boss ubiquity: /lib/partman/definitions.sh: line 355: /var/lib/partman/outfifo: No such file or directory" [10:04] err, not that one [10:04] "Mar 20 15:06:10 boss ubiquity: /lib/partman/definitions.sh: line 155: /lib/partman/choose_partition/ : No such file or directory" [10:05] don't see how that could happen with a correct CD [10:06] ok , then what to do [10:06] also, you appear to be using some derived distribution, not Ubuntu proper [10:06] please ask them for help [10:06] I don't know what strange things they might have done to their live CD [10:07] cjwatson, actually this ubuntu cd , but i customised [10:08] cjwatson, actually this is ubuntu cd , but i customised with doc how to create a live cd [10:08] it would have been polite to say that up-front ;-) [10:09] I don't really see how you could get the error above from a line of code that reads (in the standard version) "$dir/${RET%__________*}/do_option ${RET#*__________} "$@" || return $?" [10:09] unless $RET contains a space, which it shouldn't there [10:09] you'll need to run the installer with 'ubiquity --debug' to get useful debugging on why it's gone mad [10:10] cjwatson, shall i run & send you the output [10:11] sure, I guess [10:11] if you have any installer customisations, now is the time to reveal them [10:15] cjwatson, yeah i ran but i didnt get any error msg on the console , but still i am not able to fix the root file system [10:16] the debug output will be in /var/log/installer/debug [10:16] I'm going to be on the phone for the next hour or so [10:21] casper: cjwatson * r483 casper/ (2 files in 2 dirs): [10:21] casper: * Stop quoting Exec arguments in .desktop files. Apparently this used to [10:21] casper: work but now the system conforms more strictly to the desktop entry [10:21] casper: specification (LP: #204185). [10:23] gan_: please don't attempt to DCC send it to me [10:23] it won't work, and your DCC request appears to be broken anyway according to my client [10:24] cjwatson, now the patebin is also not working what to do, how to send [10:24] I'm pretty sure that "0.0.0.199 port 0" is not a valid source [10:24] paste.ubuntu.com [10:24] k [10:28] cjwatson, http://paste.ubuntu.com/5919/ see this debug link [10:38] cjwatson, are you there [11:58] I told you I was going to be on the phone [11:58] and I was :-) [12:03] ok [12:03] cjwatson, no problem [12:06] gan_: ok, so partman threw an exception somewhere, after which ubiquity got very confused. Could you put /var/log/partman on paste.ubuntu.com as well? It should indicate why [12:06] seems to be while you were creating a new partition [12:06] ok just a min [12:07] now, it's also a bug that ubiquity got confused ... [12:13] cjwatson, see this link http://paste.ubuntu.com/5923/ /var/log/partman [12:21] looking [12:22] ok [12:28] ok, the reason you're encountering this is that you're using bash as your default /bin/sh [12:29] Ubuntu's default is dash, and it appears that dash and bash behave slightly differently on particular shell code in the middle of the installer [12:29] I produced a test case to confirm this [12:31] so what i have to do [12:31] this appears to be a customisation you've applied yourself [12:31] can i change my bash to dash [12:31] so you ought to be able to undo it [12:31] cjwatson, yeah [12:32] technically, I think it is a bug in partman-partitioning [12:32] cjwatson, then whats the solution for this [12:33] changing the default shell to dash is the safest approach; I can't guarantee that there aren't other areas of the partitioner that depend on the same difference [12:33] how to do it [12:33] you must have done it in the first place [12:34] assuming you started from an Ubuntu 6.10 live CD or later [12:34] you could also apply a patch something like http://paste.ubuntu.com/5925/ to /lib/partman/free_space/50new/do_option [12:35] (might not apply directly with the patch command, but it's just a matter of switching the order of two lines [12:35] ) [12:36] which two lines [12:36] read the patch [12:37] it means you are asking me to do manually. [12:38] cjwatson, better i change my bash to dash [12:38] sure, that should work [12:38] I assumed you had changed it for a reason [12:38] what was that reason? [12:39] I'll fix the code so that this shouldn't happen in 8.04, at least in that particular case [12:39] cjwatson, why cant you do it for bash [12:40] cjwatson, i always work with bash that is the reason [12:40] the patch I gave you should fix it [12:40] for bash [12:41] if you write shell scripts that make use of special bash facilities, you should put '#! /bin/bash' at the top of them, not '#! /bin/sh'. That way, it doesn't matter what the system default shell is. [12:41] Interactive shells are bash anyway, regardless of what /bin/sh points to. [12:42] the reason for the difference here is that if you say 'local VARIABLE' in dash (for some value of VARIABLE) and VARIABLE already has a value, then dash uses that as the initial value of the local variable; while bash always initialises VARIABLE to the empty string [12:43] cjwatson, i have to paste this patch under /var/log/partman am i correct [12:43] local isn't standardised, so differences are to be expected [12:43] uh, no, that's completely wrong [12:43] you need to edit the file /lib/partman/free_space/50new/do_option, as I told you [12:43] kk [12:43] read the patch - lines beginning with "-" are to be removed, lines beginning with "+" are to be added [12:44] k [12:45] i like to be in bash only, i am getting confuse with dash [12:47] cjwatson, ok thanks i do the thing & i will reply you surely , now i have to go out [12:47] but you're confusing the system [12:48] you can perfectly well use bash for your own scripts, just by putting /bin/bash at the top [12:48] cjwatson, yeah [12:48] the system default doesn't change that at all [12:48] k [12:48] this was a fun little installer bug, though, so thanks for reporting it! [12:48] how the dash starts [12:50] ok thanks for your patience [12:50] "how the dash starts" -> I don't understand the question [12:51] bash starts /bin/sh like that for dash [12:52] I still don't understand. Are you talking about the first line of scripts? [12:52] yeah [12:53] If you use bash-specific features, say /bin/bash. If you use dash-specific features (this is very rare - this installer bug is one of the very few cases I've encountered), say /bin/dash. If your script is written to the POSIX shell standard and will work with either, say /bin/sh. [12:54] ok === cjwatson_ is now known as cjwatson [15:43] ubiquity: evand * r2578 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): * Remove dead code for the old resize widget. [15:44] ubiquity: evand * r2579 ubiquity/ (debian/changelog ubiquity/frontend/noninteractive.py): * Fix printing of non-latin text in the noninteractive frontend. [17:22] evand: you asked about bug 204133. do you want to work on debugging it? [17:22] Launchpad bug 204133 in wubi "wubi install unusable - Buffer I/O error on device loop0" [Undecided,New] https://launchpad.net/bugs/204133 [17:27] bdmurray: do you still have the image? [17:27] evand: yes, I do [17:29] can you try running a chkdsk C: /f /r ? [17:29] on the host Windows install [17:29] then try booting Ubuntu again and see if that fixes it [17:30] Do you just use chkdsk in a command prompt or does it require booting into something special? [17:31] just in a command prompt [17:31] it will say that it cannot run chkdsk at this time because the disk is mounted [17:31] and ask you if you want to do it on next boot [17:31] say yes, then reboot Windows [17:31] okay, I'm on it [17:31] thanks, much appreciated [17:35] evand: my windows vista foo is really bad. How do I get in an "elevated mode"? [17:37] right click on the application and select run as administrator [17:38] you can drag a shortcut on the desktop and right click on that if you don't want to dig for the actual program location [17:38] UAC is a mess. [17:39] makes me love Ubuntu even more. ;) [17:40] hahaha, indeed [18:02] evand: still seeing the same "Buffer I/O error on device loop0" [18:04] argh, hrm. [18:05] I don't suppose you have a serial port and cable from which you can get a full log of whats happeneing? [18:06] my laptop has no serial port but I have a usb to serial adapter if that is any help [18:07] bdmurray, you have a null modem cable to go with that? [18:07] you should be able to dump to it then [18:08] mario_limonciell: somewhere I'm sure [18:08] on your kernel command line, you can add it as a console output, or you can just redirect the app causing that [18:08] if you find it and could set that up and attach a full log to the bug whenever you have some free time, I'd appreciate it [18:10] evand: how much of a priority do you think it is? [18:11] bdmurray: not too high, I believe. I haven't seen this bug anywhere else yet. [18:11] I'm so special [18:11] I asked Agostino if he has, but he's away for the weekend [18:11] haha [18:12] how widespread has testing been going on wubi aside from evand bdmurray and TheMuso? [18:12] the Wubi forum on ubuntuforums.org [18:12] so a fairly sizable number of folks then? [18:12] I've seen a handful of people there test it, but those are only the ones who replied [18:13] ah [18:17] okay, I think I've found the cable is there some documentation you point me at for doing this? [18:18] well so where are those errors coming from, kernel log? [18:18] syslog or similar? [18:19] if that's the case, something like this is what you want: http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/configure-kernel.html [18:19] kernel, I can boot into single user mode but see those messages [18:20] depending on how early they pop up you should be able to use that as listed above. if they are really early (like before usb is loaded ;)), you'll miss them [18:21] okay, and what is the best app on the non-broken system to use to catch the messages? [18:22] i use cutecom/minicom [18:22] cutecom is for X [18:22] minicom for a terminal [18:22] cutecom is a lot easier to configure imo [18:22] I've used minicom before just wanted to be sure [18:23] thanks! [18:23] np, best of luck :) [19:11] evand ping [19:11] xivulon: pong [19:12] so this loop0 thing, I haven't seen that [19:12] there was something similar when vfat was used [19:12] since the fs was ro to begin with [19:13] not sure if that's the case [19:14] bdmurray is using Vista, so it's definitely not vfat, but he's working on getting a full log using a serial port. [19:15] or at least trying to :) [19:15] is that reproducible? [19:16] I see bdmurray is here too, hi [19:17] getting the full log is proving challenging [19:17] might it be that 204133 is related to 20080320? [19:17] That was a typo on my part it really was 20080319 - I'll update the bug [19:17] I did get some pictures of call traces [19:17] 204128 <-> 204133 that is [19:18] bdmurray, did you try reinstalling? [19:18] No, I was thinking about that next [19:19] Do I need to remove the existing install first? [19:20] it will force you to, though I'd suggest moving it out of the way in case reinstalling makes the bug disappear. [19:20] You could move root.disk to a different dir [19:20] so we could get that back in case the new one works well [19:21] evand, did you get a chance to look over that other noninteractive thing I ran into yesterday? [19:22] xivulon: where will I find root.disk? [19:23] found it [19:24] mario_limonciell: I've been looking at it as I work on other things today. I fixed the immediate problem, but uncovered others when I did, so I'm working on those now. [19:26] ah i see === ago is now known as xivulon_ [19:30] back, battery power meter wasn't too reliable... [19:31] heh [19:32] so bdmurray, if you backup your previous file, I'd suggest to try a reinstallation [19:32] at the first reboot, press esc, and select verbose mode, that runs ubiquity with debug flag [19:34] evand the other bug you mentioned was about reconnection, was that running off a physical CD [19:35] xivulon_: the bug where Wubi cannot install without being connected to the Internet? [19:36] I there is a log.. [19:36] * xivulon_ reading log [19:36] Yes, that was running off of the Beta candidate. [19:38] apparently the issue is that the md5 check of squashfs failed [19:38] md5=b5b8b1f15d1f45797c1f57ba8d0f30d6 [19:38] indeed, I caught that while pasting the log [19:38] if that failed then it is normal that a connection is required [19:38] though I believe this was with two different images [19:38] I'll verify the CD image and try again though [19:39] that should be the md5 of squashfs file only [19:40] when using a physical CD and without internet connection the md5 for the individual file is used [19:41] taken from md5sum.txt === xivulon_ is now known as xivulon [19:46] * xivulon at dinner [20:05] xivulon: I checked the md5sum of the squashfs in Ubuntu and it matches the line in md5sum.txt [20:07] xivulon: I've updated bug 204128 [20:07] Launchpad bug 204128 in wubi "After install completed bar wasn't all green" [Undecided,New] https://launchpad.net/bugs/204128 [20:09] heh, at least we know the CD-ROM drive is ejecting for sure now. [20:09] evand: my "Ubuntu Setup" window in not responding in Vista. any ideas? [20:10] hrm [20:11] attach %TEMP%\Wubi-8.04-alpha-rev449.log to that bug report? [20:11] s/?/. [20:12] xivulon: have you had reports of successful Vista installs? [20:18] outside of VMWare that is, as I tested that successfully. [20:19] hmph, I had some information about it not responding and then the window disappeared on me [20:19] hrm, though that reminds me that TheMuso had issues with Vista as well, though they disappeared. [20:19] odd [20:23] I just saw "checking the installation" go past 100% for whatever that is worth [20:26] yeah :/, that's my fault [20:27] I still need to fix it, it's a long standing bug when using --automatic [20:28] okay, at least its known ;) [20:28] heh, indeed [20:29] I added some pictures to bug 204133 from the first disk image [20:29] Launchpad bug 204133 in wubi "wubi install unusable - Buffer I/O error on device loop0" [Undecided,New] https://launchpad.net/bugs/204133 [20:36] iz kernel bug :) [20:37] doesn't appear to be the same issue I ran into with VMWare and 64-bit, but we had already assumed that. [20:37] hrm, still no luck with the serial console? [20:41] not yet [20:41] I'm at the same place after a reinstall too [22:06] Hey All...has luks/cryptsetup made it's way into ubiquity for HH? Can't see it mentioned in launchpad or ubiquity.. [22:06] evand, just run a successful installation on vista [22:07] using wubi 449 and ISO 20080318.1 [22:07] amd64 [22:08] bdmurray, re progressbar, I can confirm it finishes when the bar is not 100%, but that does not have any implication [22:08] xivulon: I've put up some pictures of the crash at http://people.ubuntu.com/~brian/tmp/ [22:08] the bar progress is calculated by nsis, their algorithm is likely wrong [22:09] the ones starting off 20080320-* [22:10] bdmurray, did you experienced crashes only with today's ISO? [22:10] It would take me ages to download that... [22:10] I was using 20080319 and that is the only one I've tried wubi on [22:15] you used amd64 correct? [22:17] well I started downloading the 19 ISO. [22:25] evand: possible hint for you in bug 197887 [22:25] Launchpad bug 197887 in ubiquity "Accessibility non-functional in only-ubiquity mode." [High,Confirmed] https://launchpad.net/bugs/197887 [22:26] bdmurray, I suspect that the nsis algorithm estimates the progress by counting the number of "calls" within the installation function at compile time, but it does not take into account parts of code that are not executed at runtime because of logical conditions. [22:27] will test that assumption in coming days, I do not think it is very important unless the actual installation is affected [22:28] which does not seem to be the case [22:28] mario_limonciell: amd64 alt seems fine [22:28] xivulon: yes, I used amd64 [22:31] ah, thanks cjwatson [22:31] xivulon: ack'ed [22:31] I'll toy with that tonight [22:33] Daviey, let slangasek know [22:33] oh you did [22:33] okay good :) [22:34] bdmurray did you try booting with init=/bin/sh [22:36] xivulon: no, I did not [22:36] might be worth a go [22:37] you could then try the rcS scripts manually [22:37] first maybe check that the fs is r/w [22:47] bootlaces: No, it was a low priority specification for Hardy that was deferred. [22:47] evand, thanks for the update [22:47] looks like I'll be using the alternative installer :) [22:48] evand, I'd need to reboot to test the reconnecting issue, but I'd have to interrupt the download then, that would be a post beta fix anyway correct? [22:49] yes, the beta is going to be released today, only a very serious issue would postpone it. [22:49] Well, today EST. [22:52] I'd thought so [22:54] I can push a new rev with an extra debugging line, if you send me the log that should be enough for me [22:56] ok [22:56] dinner, back in a bit [22:57] rev 456 [23:58] evand, I can confirm #203998 [23:58] no need to send me the log [23:58] I will fix that in the coming days, you might want to add a caveat [23:59] I'll do that...