=== xivulon [n=ago@87-194-85-156.bethere.co.uk] has left #ubuntu-installer [] === mpt [n=mpt@121-72-130-17.dsl.telstraclear.net] has joined #ubuntu-installer === xivulon [n=ago@87-194-85-156.bethere.co.uk] has joined #ubuntu-installer === jetsaredi1 [n=jgreenwa@pool-141-149-173-208.bos.east.verizon.net] has joined #ubuntu-installer === jetsaredi1 [n=jgreenwa@pool-141-149-173-208.bos.east.verizon.net] has left #ubuntu-installer [] === xivulon [n=ago@87-194-85-156.bethere.co.uk] has left #ubuntu-installer [] [09:24] ubiquity: superm1 * r2162 mythbuntu-ubiquity/ubiquity/frontend/mythbuntu_ui.py: activate tv-out controls for all nvidia drivers [09:47] ubiquity: superm1 * r2163 mythbuntu-ubiquity/ (5 files in 4 dirs): allow adding/removing mythstream [09:55] evand, in my experiments this evening, i've been getting a lot of transient issues regarding getting stuck in install_extras. Will literally work one boot and fail the next. You guys been encountering anything similar when using install_extras to install language packages lately? [09:56] i narrowed it down to that function with a whole lot of print's around all the function calls of install.py [10:04] the odd thing is that all the extras get installed, and /sys, /proc get umounted. just sits aimlessly otherwise === xivulon [i=c2325681@gateway/web/cgi-irc/ircatwork.com/x-bae4ba2ea22ff9a4] has joined #ubuntu-installer [12:06] evand: did you know about http://www.groklaw.net/comment.php?mode=display&sid=20070921112733615&title=There%20is%20more%20to%20Linux%20than%20Ubuntu&type=article&order=&hideanonymous=0&pid=625102#c625432 ? (Mandriva to ship migration-assistant) === xivulon [i=c2325681@gateway/web/cgi-irc/ircatwork.com/x-5b0119f11552ad2b] has joined #ubuntu-installer [01:35] cjwatson, is netboot a desirable add-on for wubi? [01:38] I can't really imagine it ... [01:38] same as the debian one [01:38] the only case where that would make sense would be with a broken CD drive, and surely booting from an ISO on the hard disk covers that [01:38] does Debian win32-loader support netboot? [01:38] if so, I don't know what the rationale is [01:38] perhaps it can't boot from an ISO on the hard disk [01:38] netboot is all win32 loader does [01:38] exactly [01:40] I strongly prefer the ISO approach since 1) you download from windows and do not expose the user to sorting out networking in a text envirnoment [01:40] 2) you use ubiquity interface [01:41] but... if you want to do a dedicated partition installation, using the iso you have to deal with one of the partitions being mounted [01:42] at some point, you should just use the normal installer :) [01:42] wubi doesn't have to support everything [01:42] of course [01:42] it does... [01:42] we are running the normal installer [01:42] I mean just use the normal installer launched normally, not through wubi [01:43] If people are familiar with ISOs and partitions, sure [01:44] when you start getting into more and more complicated scenarios, ultimately yes, people have to learn [01:44] I always suggest people to do a normal installation if after using wubi they want something extra (usually more disk space or suspend) [01:44] the more options wubi has, the more complicated it is itself, and the harder it gets to use ... [01:44] I agree there [01:45] I don't think netboot is particularly desirable for it [01:46] I just mentioned because if you wanted netboot at a later stage we'd need to add lupin find_* and autopartition-loop to the alternate ISO [01:46] I understand, but we can cross that bridge if and when we come to it [01:47] sure [01:48] (autopartition-loop is already on the alternate image; the lupin stuff will require changing the option name and probably significantly different code) [01:48] cjwatson, as mentioned in the casper bug report I was thinking about a rewrite anyway [01:49] that wouldn't help here [01:49] this is one area where d-i and casper are likely to need separate code [01:49] the environments are too different to be able to share code at this point [01:50] makes sense [02:00] On a different topic, is it worth the trouble to support amd64? [03:09] cjwatson: I found out through OSNews. I'm kind of surprised that they didn't try to contact me. I would've been very willing to explain things and help where possible. [03:09] I can't complain though, I really wanted other distros to pick it up and this is a step in that direction. [03:10] I wonder if they're keeping the debconf use [03:10] I didn't know Mandriva supported that [03:11] I image they're just using the m-a binaries (ma-search-users, ma-search-items, and ma-import) [03:11] I'll investigate that tonight though as I'm curious if they modified the code at all. [03:12] If they're keeping the debconf code, I hope they're following my branch closely, given the recent security issue. [03:17] superm1: What function name? [03:32] evand, under self.install_extras(), self.do_install(self.query_recorded_installed()) [03:32] everything is getting installed, but it appears to be hanging through there [03:34] Hrm, I haven't noticed any issues installing language packs. [03:34] So it's not crashing, just taking a long time? [03:35] well i left it overnight in the VM [03:35] when i went to bed [03:35] and its still there [03:35] so yeah [03:35] wow [03:35] so i'm at a bit of a loss of how to debug it now [03:36] Python needs a set -x. The rough equivalent in pdb is poor. [03:38] superm1: I generally use a lot of print statements and --debug. [03:38] yeah i tried --debug and got nowhere regarding that. [03:38] hrm [03:39] perhaps i'll have to keep tracing further into do_install then with the print statements [03:40] okay well my time this morning for debugging before class is already up, i'll try to continue later on then, thx :) [03:40] that's what I ended up doing when working on the lang pack issue [03:40] superm1 python logging is more convenient for that sort of tasks [03:41] no problem, let me know if you need any help and I'll try to reproduce the bug [03:41] xivulon: python logging? [03:41] the logging module in python [03:42] far better then using print statements [03:42] only if you want to leave them in place afterwards, which can clutter the code a lot for random debugging stuff and make it hard to read [03:43] yeah, it seems like overkill for debugging [03:43] cjwatson, let's say that if you "forget" them it's half damage most of the time... [03:44] evand, once you define a proper debug level, then it's as easy as using print statements [03:44] a matter of taste I suppose === evand [n=evand@ubuntu/member/evand] has joined #ubuntu-installer === evand [n=evand@ubuntu/member/evand] has joined #ubuntu-installer === cr3 [n=cr3@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-installer === xivulon [n=ago@87-194-85-156.bethere.co.uk] has joined #ubuntu-installer === avoine [n=avoine@58-194-0-72-ppp.3menatwork.com] has joined #ubuntu-installer === superm1_ [n=malimonc@ubuntu/member/superm1] has joined #ubuntu-installer [05:45] evand, I narrowed it down to the command that is causing issues in do_install [05:45] cache.open(None) [05:45] around line 1418 or so [05:45] of install.py [05:46] hrm === evand investigates [05:46] what is that supposed to be doing exactly? [05:46] it reopens the cache to take account of the stuff that was just committed [05:48] cjwatson, can you think of any reasons that would not be getting along then? [05:48] perhaps related to bug 131294 [05:48] I'd have to look at current python-apt code [05:49] the temporary workaround for 131294 ought to cover this too, if it's the same thing [05:51] perhaps mvo can shed light on why that might hang [05:51] ohh, it completely slipped my mind that mythbuntu uses its own install.py [05:51] evand, well but it inherits from install.py [05:51] and uses install.py's functions then for things like this === mode/#ubuntu-installer [+o cjwatson] by ChanServ === cjwatson /invites mvo === mode/#ubuntu-installer [-o cjwatson] by cjwatson [05:52] i'll be back in about 10 min, gotta run to my next building [05:54] uhhh, shouldn't mythbuntu_install.py call Install.__init__()? [05:54] it doesn't define its own __init__ - does it need to call the superclass constructor explicitly? [05:54] I thought that was implicit [05:55] I'm not sure, actually. [05:55] "If a base class has an __init__() method, the derived class's __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: "BaseClass.__init__(self, [args...] )"." [05:55] I'm from a C++ background where this kind of thing is simple ;) [05:56] I interpret "if any" as meaning that it's OK if the derived class doesn't have an __init__ [05:56] ahh [05:56] ok [05:58] indeed it does work that way === superm1_ [n=malimonc@ubuntu/member/superm1] has joined #ubuntu-installer [06:07] speaking of apt_cache, the debconf python module should really throw a meaningful exception when the database is locked. If no one beats me to that, I'll take care of it for Hardy. [06:09] i'm surprised it doesnt already [06:10] it's tricky because it's not the confmodule that errors, it's the frontend [06:11] so it needs to spot the frontend failing and do something useful === trimmer [n=alien@12-207-39-128.client.mchsi.com] has joined #ubuntu-installer === xivulon [n=ago@87-194-85-156.bethere.co.uk] has left #ubuntu-installer [] === superm1__ [n=malimonc@waluigi.student.iastate.edu] has joined #ubuntu-installer [07:10] well i narrowed it down inside python-apt. it is hanging on self._cache = apt_pkg.GetCache(progress) [07:12] need mvo really [07:12] yeah === xivulon [n=ago@87-194-85-156.bethere.co.uk] has joined #ubuntu-installer === mathiaz [n=mathiaz@ubuntu/member/mathiaz] has joined #ubuntu-installer [10:22] Hi. I'm trying to install an lvm system with the preseed using the ubuntu-server cd. [10:22] I've set the following line in the preseed : d-i partman-auto-lvm/disk string /dev/sda [10:22] and commented #d-i partman-auto/disk string /dev/sda [10:23] but I still end up with a system that is not lvm. [10:25] should I set something else in the preseed file ? [10:26] d-i partman-auto/method string lvm [10:26] partman-auto-lvm/disk doesn't exist; put that back to partman-auto/disk === avoine [n=avoine@58-194-0-72-ppp.3menatwork.com] has left #ubuntu-installer [] [10:27] you might want to set "d-i partman-auto-lvm/new_vg_name string " too [10:27] (it'll default to the hostname) [10:27] (I think) [10:27] cjwatson: ok. I'll try that. [10:32] cjwatson: great ! it works. Thanks. [10:33] Where should I file a bug for this issue ? [10:33] I think it's in the installer guide. [10:34] the current version of the installation guide I have doesn't mention partman-auto-lvm/disk [10:35] it says: [10:35] # Alternatively, you can specify a disk to partition. The device name [10:35] # must be given in traditional non-devfs format. [10:35] # For example, to use the first SCSI hard disk: [10:35] d-i partman-auto/disk string /dev/sda [10:35] # In addition, you'll need to specify the method to use. [10:35] # The presently available methods are: "regular", "lvm" and "crypto" [10:35] d-i partman-auto/method string lvm [10:35] hum... I was looking at https://help.ubuntu.com/7.04/installation-guide/amd64/preseed-contents.html [10:35] https://help.ubuntu.com/7.04/installation-guide/i386/preseed-contents.html#preseed-partman does [10:35] whoops, beat me to it [10:36] it also asked me another question about writing the lvm data to the disk. [10:37] ah, the 7.04 documentation was out of date there [10:37] the 7.10 documentation will be correct in this regard [10:37] I guess I'll be able to find the write preseed configuration line with debconf-get-selections ? [10:37] bugs on the installation guide go on the installation-guide package [10:39] # If one of the disks that are going to be automatically partitioned [10:39] # contains an old LVM configuration, the user will normally receive a [10:39] # warning. This can be preseeded away... [10:39] d-i partman-auto/purge_lvm_from_device boolean true [10:39] # And the same goes for the confirmation to write the lvm partitions. [10:39] d-i partman-lvm/confirm boolean true [10:39] that? [10:39] I should get mdke to publish the 7.10 docs [10:39] cjwatson: great - thanks. [10:42] cjwatson: I think they're online at http://doc.ubuntu.com [10:43] mathiaz: I don't see the installation guide there [10:43] the doc team tend to conveniently forget things they didn't write :P [10:44] cjwatson: agreed. And I'm not sure it's gutsy documenation. [10:44] cjwatson: it says feisty in different places. [11:04] hmm I am testing wubi and am stacked at creating ext3, even using full device zeroing [11:04] everything is frozen solid [11:05] I had top running and that looks fine [11:08] yeah, that sounds like where we got stuck [11:08] if it's anything like what I was experiencing you have a very short window where you could potentially get in there and strace mkfs.ext3 [11:12] weird [11:12] can it be a unionfs thing? I still get weird messages when shutting down [11:13] not that unionfs should be directly involved but... === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-installer [11:20] sorry about that [11:20] most program crashes are boring, compiz at least makes things interesting [11:21] with pretty flashing colors to keep you entertained while you hold down the power button [11:23] it could be a unionfs issue, though I'm not sure. There are apparently still isolated issues with unionfs as was reported in our team meeting this morning [11:24] it could also be a ntfs-3g issue, I think, which I believe Colin suggested as a possibility [11:27] is the 6.06.2 release still estimated for the beginning of october? [11:28] mid-october, afaik [11:28] :-| [11:28] but best to ask in #ubuntu-devel [11:28] as I am by no means an authority on such subjects [11:29] okay, then I guess I'll try to hack the old initrd instead. [11:30] 6.06.1 can't pxe boot on bnx2, and 6.06.2 will fix the issue. I was hoping I didn't have to mess with it on my own.