[09:20] cjwatson: should it be safe to test lvm got lots to test and not much time? [09:26] davmor2: wouldn't mind a coherent idea of its current state [09:27] it seemed to be working for me [09:27] cjwatson: wilko I'll run a quick test now [09:28] cjwatson: did you test on 32 or 64 bit? [09:28] i386 [09:29] right I'll try a 64bit then :) [09:29] shouldn't think that alone will matter [09:29] I know of the general problem that the LVM tools don't operate atomically, so quick successive operations may fail for one reason or another [09:30] therefore, the difference between kvm and real hardware is more likely to be significant than the difference between i386 and amd64, IMO [09:31] cjwatson: I was thinking more along the lines of if i368 works for you and amd64 works for me then both are likely to work and be safe to test :) [09:34] davmor2: sure, just saying that I wouldn't expect the architecture difference to be significant here. If i386 works for me but amd64 fails for you then the difference is much more likely to be due to some other factor, not the difference in architecture [09:38] cjwatson: fscking partitioner. Error informing the kernel about modifications to partition /dev/sda2 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sda2 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. Ignore or Cancel [09:39] please don't reboot yet [09:39] what was the previous state of this disk? [09:39] I'm not [09:39] (your goal here is to show me how to reproduce this) [09:39] it had a standard whole drive install on [09:40] ok, and what did you do in this installation pass? [09:40] encrypted LVM [09:40] so all guided partitioning? [09:40] yes [09:41] cjwatson: last page was the one about setting up lvm yes or no [09:41] click on yes and then got the warning [09:42] click? [09:42] well hit tab [09:42] I'm guessing you don't actually mean mouse-click in ubiquity since it doesn't have encrypted LVM support :) [09:43] cjwatson: It's twirly [09:43] the failure's on the BLKPG_ADD_PARTITION ioctl, but I'm guessing that it's actually because a previous BLKPG_DEL_PARTITION failed [09:43] can I get /var/log/partman quickly? [09:44] what was the ssh command to save some time [09:44] hmm, would be nice to know what the error code from the ioctl was but libparted probably doesn't show that [09:44] anna-install openssh-client-udeb [09:44] scp /var/log/partman user@host:target-file-name [09:45] exit code's probably EBUSY which would indicate another active overlapping partition [09:45] I wonder if there's any way I can get a list of active partitions [09:45] um, 'ls /sys/block/sda' maybe? [09:45] only the sda* ones [09:46] was this server or alternate? [09:46] (it probably doesn't matter ...) [09:47] cjwatson: should be at http://www.davmor2.co.uk/partman1 [09:49] sorry it's not it's http://www.davmor2.co.uk/partman need to clean up my server again [09:49] infact give me 2 ticks I'll wipe them both and reupload to be sure [09:50] arr. unique ids :) [09:50] right it's definately the last link now [09:52] It's cause I'm always dropping them on my server and forget to clean up after :) [09:52] oh, /dev/sda2 is the extended partition, ok [09:53] (I was wondering why there were two primaries) [09:53] is this definitely with the most current images? [09:55] davmor2: if you can reproduce this on demand, one piece of information that would be amazingly useful, if a bit fiddly to set up, would be the output from a run of 'udevadm monitor' from the point just before you press enter on the final LVM setup question to a point after the failure [09:56] davmor2: the reason I'm saying this is that it seems to me that the most likely cause for this bug is that we delete the partition and then sometimes udev is opening the disk to have a quick look at it before we add partitions [09:56] let me see if I can reproduce it here ... [09:57] give me 5 mins and I'll re-run I'm just doing oem install on live on my other machine [09:58] OEM GTK/KDE frontends are known broken in user-setup [09:58] so you could skip that [09:59] D'oh [09:59] I thought that got fixed in a4 [10:00] or was I just dreaming [10:04] this problem was introduced after alpha 4 [10:05] yes I remember now doesn't it say username invalid before you put one in [10:05] yes [10:05] Evan fixed it in bzr but didn't upload ;-) [10:06] didn't notice until it was a bit too late [10:06] I saw the bug on it [10:06] well you could always respin before I start testing :) [10:08] I already checked with Steve, we decided to put this one in the errata [10:13] looks like that lvm bug is the same as mine [10:14] which lvm bug? [10:14] bug 334278 [10:14] I'd really prefer to consider each one separately, anyway [10:14] Launchpad bug 334278 in debian-installer "lvm: in-memory partition table not updated" [Undecided,New] https://launchpad.net/bugs/334278 [10:15] that *is* your bug. which one are you saying is the same? [10:15] ah :) [10:15] the one davmor2 reported [10:15] here [10:15] so I agree that it looks similar but there are some differences: davmor2 started out with /dev/sda1 and /dev/sda5 whereas you started out with /dev/sda1 and /dev/sda2 [10:16] it could be that the same kind of change needs to be made in different places, or it could all be due to the one core bug [10:16] it only depends on what you had on the disk [10:16] until I've investigated further I simply won't know [10:16] I get the same(ish) error when I try to install lvm on top of an old regular installation, or vice versa [10:17] IMO it is best to understand and diagnose the bug, and *then* deal with duplicates :) [10:17] sure [10:17] but yes, there is definitely a pattern here [10:17] it's my top thing to look at now [10:17] probably not something for this alpha? [10:17] not sure yet [10:17] ok [10:18] I'm inclined to say not provided that installations are at least sometimes possible ... [10:18] though it's not going to make for a pretty release note [10:19] heh :) [10:19] hopefully I can reproduce it here; if not it's a race condition and I'm going to have to bang my head against a few walls [10:21] Meh cjwatson I just did the udevadm monitor hit yes and it's gone straight through to encryption password [10:22] I guess the pattern is; regular -> lvm FAIL, lvm -> regular FAIL, regular -> regular OK [10:22] davmor2: do you have the output of udevadm monitor, though? [10:22] that confirms that it is a race condition [10:22] but the last case might be successfull only because the layout is exactly the same [10:22] the monitor output may still be useful [10:22] cjwatson: yes goes off the screen [10:22] argh [10:22] davmor2: redirect it to a file :-) [10:23] udevadm monitor >monitor-output 2>&1 [10:23] cjwatson: I was about to ask :) I'll re-run it [10:23] sorry, suppose I should have said [10:23] cjwatson: so not preseeding partman-auto/method, and running udevmonitor right before choosing the option? [10:24] tjaalton: regular->LVM works for me; this is a race condition [10:24] tjaalton: udevadm monitor, but yes [10:24] hmm, interesting, the default answer for the guided size question fails for me [10:25] cjwatson: but does the partition layout change for you when doing regular -> lvm? [10:26] cjwatson: I think I just got the same thing doing whole drive over the whole drive oem on the live system [10:26] tjaalton: I'm reproducing davmor2's setup here, so I would imagine so [10:26] cjwatson: ok [10:26] tjaalton: I can't check because I just ran into bug 327348 AGAIN [10:26] Launchpad bug 327348 in kvm "keep losing ability to type in guest" [Undecided,New] https://launchpad.net/bugs/327348 [10:27] ugh [10:30] cjwatson: how do I get access to the output from udevadm now? I'm used to just piping it to a file :) [10:34] ah got it:) [10:36] cjwatson: http://www.davmor2.co.uk/monitor-output [10:47] cjwatson: I'm carrying on with the install now and I'll see if I can reproduce on the next install [10:50] hmm. blast. longint2human's rounding is not quite what I wanted [11:02] cjwatson: I saw an issue with longint2human's display today, too [11:03] cjwatson: Lemme get the photo somewhere more accessable than an SD card and I'll throw you a URL [11:08] cjwatson: http://wedontsleep.org/~steven/IMG_2471.JPG [11:09] oh, that's different [11:10] partman-auto-lvm: cjwatson * r216 ubuntu/ (debian/changelog perform_recipe_by_lvm): [11:10] partman-auto-lvm: Cope with rounding errors in guided_size; if the value we convert back [11:10] partman-auto-lvm: from human-readable notation is in the round-off range at either end, [11:10] partman-auto-lvm: just use the appropriate extreme (LP: #334648). [11:10] Sure, but it's still a fun problem. :-) [11:10] evand: ^- StevenK's bug seems like more your field, I'm not quite sure how ubiquity does that stuff these days [11:10] cjwatson: Oh, right. Unrelated to longint2human then, sorry. I guessed. [11:10] Yikes. I'll look into that. [11:10] evand: Prod me if you want a proper bug filed. [11:11] StevenK: well, could be related, who knows :) [11:11] StevenK: please do, just so I have something to track it with. [11:11] though it seems more like some kind of order-of-magnitude bug; human2longint and longint2human have a small test suite now so I'm reasonably sure they don't have order-of-magnitude bugs [11:12] evand: Oh, there's a neat bug with the timezone selector, too. The cities don't line up with the picture, at least on my Q1 and Jax10. [11:12] Indeed, I suspect this is as the result of some change I've made to segmented_bar recently. [11:12] cities> yes, AOL, I think somebody filed that ... [11:13] I didn't think Sydney was out to sea, but I'm not sure ... [11:13] reproducible in kvm [11:14] indeed, very well aware of that one [11:14] bug 334284 [11:14] Launchpad bug 334284 in ubiquity "ubuiqity OEM installer - TZ selection: London is not located in the UK but in mainland europe" [Medium,Confirmed] https://launchpad.net/bugs/334284 [11:15] * StevenK subscribes himself to it [11:17] davmor2: thanks, summoning Keybuk ... [11:17] evand: Bug filed. [11:18] cjwatson: Will this be a show stopper or just a testing stopper? [11:18] I don't know [11:21] thanks [11:24] evand: remind me, did you have a patch for bug 287635 (which I think is basically a dup of bug 34974, btw)? if so now would be a good time for me to commit it upstream and then we won't have to worry about translations [11:24] Launchpad bug 287635 in partman-partitioning "Poor wording on errors" [Low,Confirmed] https://launchpad.net/bugs/287635 [11:24] Launchpad bug 34974 in partman-partitioning ""Too large size" message a little terse" [Low,Triaged] https://launchpad.net/bugs/34974 [11:26] I might, let me dig through my branches quickly [11:28] cjwatson: Apparently not. Want me to write something up? [11:30] evand: if you have time, sure [11:31] ok, will do. I'll also dup to 34974 and attach it there. [11:40] cjwatson: I can confirm it works the other way too so with the lvm install in place you can't then do a whole drive install over the top of it :( [11:45] partman-partitioning: cjwatson * r697 ubuntu/ (debian/changelog lib/resize.sh): [11:45] partman-partitioning: Cope with rounding errors while asking for the new partition size; if [11:45] partman-partitioning: the value we convert back from human-readable notation is in the [11:45] partman-partitioning: round-off range at either end, just use the appropriate extreme. [11:46] davmor2: ok, will need to wait for Keybuk to notice my /msg I think [11:46] I can't reproduce it myself (although I believe it) and this is getting outside my expertise ... [11:51] it sort of feels like a udev rule missing ACTION=="add|change" to me [11:52] cjwatson: I'm well out of my depth :) [12:20] cjwatson: patch attached to 34974 [12:33] * davmor2 lunch for a bit can't do much else [12:34] evand: multi-line Description: fields don't work that way [12:34] evand: the first line is semantically separate from the short description; generally the first line should be thought of as a heading, not a sentence that might wrap [12:34] evand: so the first line should typically be limited to 65 characters, and not usually end with a full stop [12:34] ah, indeed. That completely slipped my mind [12:43] cjwatson: http://pastebin.ubuntu.com/123280/ - better? [12:48] definitely better, might make some minor rewordings but I'll need to look at the surrounding text for that; please do attach that to the bug [12:49] sure thing [12:59] ubiquity: evand * r3066 ubiquity/ (debian/changelog ubiquity/segmented_bar.py): [12:59] ubiquity: Always return an integer from get_size as the calcuation could produce a [12:59] ubiquity: float, and functions using the return value expect a number of bytes [12:59] ubiquity: (LP: #334677). [13:00] hooray for poorly worded changelog descriptions [13:03] slightly confused, I though implicit conversion occurred there. === cjwatson changed the topic of #ubuntu-installer to: http://wiki.ubuntu.com/Installer/FAQ | Development of d-i and ubiquity in Ubuntu | http://wiki.ubuntu.com/InstallerDevelopment | If nobody answers, try ubuntu-installer@lists.ubuntu.com [15:56] Installer/FAQ> new page, feel free to add stuff [16:10] oo, very cool [16:17] cjwatson: hmm, booting degraded raid seems to have regressed [16:17] cjwatson: this is the first time i've tested it in jaunty [16:18] cjwatson: http://people.ubuntu.com/~kirkland/Screenshot.png [16:44] kirkland: ... OK - are you going to fix it? :-) [16:44] cjwatson: i'm looking at it now [16:44] it probably shouldn't be trying to resolve user/group names in the initramfs, to start with [16:45] cjwatson: keybuk suggested that it might be a kernel issue with the md driver [16:45] cjwatson: i was curious if anything changed with user/group in initramfs between intrepid/jaunty [16:46] cjwatson: okay, confirmed, kernel bug [16:47] cjwatson: this is fixed by using 2.6.29rc6 vanilla kernel [16:48] cjwatson: i'll binary search to find the kernel that fixes it [16:50] cjwatson: regarding your kvm keypress issue, is there a chance that the keys are registering in the vm, but just not being reflect to screen? [16:51] cjwatson: there's a couple of screen garbling issues that upstream is trying to fix; i'm going to backport those as soon as they have them figured out [16:51] kirkland: no chance at all [16:51] kirkland: did you see my comment about it being clearly like a modifier key being held down? [16:51] cjwatson: yes i did [16:51] tty changes do register and the screen updates as normal [16:52] and if I press Enter at the "would you like to start a busybox shell" prompt, that works [16:52] cjwatson: i've been working in vm's all morning and haven't reproduced this yet [16:52] none of the symptoms suggest screen garbling in any way [16:52] cjwatson: is there a path i can use that will trigger this every time? [16:53] I don't have anything consistent; it happens for me when detaching focus with Ctrl+Alt [16:53] but only sometimes [16:53] note that I also change virtual desktops with ctrl+alt+left, but (due to another problem) I generally move the mouse out of the kvm window before doing so [16:53] (well, ctrl+alt+cursors) [16:53] cjwatson: sure [16:54] cjwatson: compiz on? (just curious) [16:54] (mine's off) [16:54] off [16:55] this is one of those things that I can reproduce as long as I'm not paying attention to it ... [16:56] could it be related to I/O? usually what seems to happen is that the installer's doing something time-consuming, so I switch away to check IRC or something, and then switch back and it's hung [16:56] I notice, anecdotally, that it never happens unless I grab focus [16:57] but sometimes I have to in order to press alt-f without some bit of desktop furniture grabbing that keystroke [16:57] cjwatson: okay, where "hung" = pressing keys, keys not registering, must drop to a virtual console, and back to reset and have good keyboard io again? [16:58] *some* keys not registering, as I said before [16:58] okay, i'll keep an eye on it [16:59] I may not have mentioned that in at least one context I saw ^] or something like that displayed after I pressed a key [16:59] obviously only when the vt in use is in raw mode or whatever so that it does that rather than trying to interpret the key sequence [17:00] the only way I know of to fix keyboard I/O is to kill the kvm and start again [17:23] cjwatson: out of curiosity, have you tested raid5 in jaunty? [17:23] cjwatson: mathiaz reported really slow performance in a kvm; that's not wholly unexpected to me (parity + triple disk io) [17:24] cjwatson: but i was checking if anyone else has tried it (i'm doing it now) [17:24] no, I haven't [17:25] k [17:28] cjwatson: can i put /boot on ext4? does grub have the smarts? [17:28] yes [17:39] davmor2,tjaalton: can you try http://cdimage.ubuntu.com/tmp/20090226/jaunty-server-i386.iso? it should rsync reasonably well against the current server image [17:39] err, hmm, let me push that to mirrors first [17:41] cjwatson: fyi, raid5 install clean on jaunty ;-) [17:41] davmor2,tjaalton: ok, that image is up now [17:41] kirkland: cool. It's not something I test very often myself ... [17:41] cjwatson: agreed. it takes 537 clicks in partman :-) [17:45] cjwatson: seems to be syncing nicely :) [17:54] cjwatson: doing a whole install now if all goes well I'll try an lvm after [17:55] cjwatson: first thing in the morning ;) [17:57] tjaalton: I'm going to be working for a bit anyway if it works for me you can confirm in the morning :) [17:58] davmor2: great :) [18:58] cjwatson: first one worked starting second install now [19:16] kirkland: I know this isn't the place but is there any plan in the server team to switch off the ability to hit alt-ctrl-delete to reboot the machine by default? [19:17] I recommend not changing that by default [19:18] it's a very useful facility [19:18] and the server has a much lower idiot factor than the desktop :-) [19:18] (I include myself in the idiots who occasionally hit ctrl-alt-backspace on the desktop) [19:19] anyway, you can configure it really easily in /etc/event.d/control-alt-delet [19:20] e [19:24] cjwatson: I knew there would be a way, it's just I know some server installs do it by default and wondered if Ubuntu would be going down that path to :) [19:32] davmor2: not that i know of [19:33] davmor2: ie, i know of no initiative to change that default [19:34] kirkland: Ta just wondered as I'd done it to restart my test machine :) [21:15] hello! I have installed ubuntu 8.04 on my sata drive (partition sda2) and the boot loader on a USB pen (sdb) but when i try to boot from the grub on the pendrive it says: GRUB and doesn't load the system on the SATA HDD. can you help me? [21:27] I need to create a GRUB to load my sda2 from my sdb (usb pen) please help me [21:41] Hi all, i'm not sure to be in the correct room in order to ask my question... i can try... i hope U help me to redirect to the correct room ;) [21:41] i'm using ubuntu 8.10 distro and i want to install kdiff [21:41] yes [21:42] i've searched the application in my repository... but i didn't found them... :( [21:42] do U know which is the correct repository? [21:42] thx in advance ;) [21:44] hmm [21:48] sergiobi: I would try on #ubuntu or #kubuntu to be honest it looks like it should be in universe [21:49] ok! i'll try! thank U davmor2! [22:01] sergiobi: indeed, this channel is more for initial installation of Ubuntu than for installation of further packages once you have Ubuntu installed [22:02] hi [22:02] what is the easiest fix if, in the installer, both grub and lilo report that there is no matching bios drive for the startup drive(s)? [22:07] mark: what's the Linux device name? [22:07] /dev/sdy and /dev/sdac [22:07] the easiest workaround is probably to edit /target/boot/grub/device.map and then try again [22:08] ok, I will try that [22:08] that sounds /* The rest is SCSI disks. */ [22:08] for (i = 0; i < 16; i++) [22:08] * cjwatson kicks grub [22:09] haha [22:09] you know how much fun doing partitioning in the ubuntu installer is on a box with 48 disks, over a 9600bps serial connection? [22:09] ;) [22:09] I'm going to bet "not much" [22:10] I had to write a script to manage all the software raid partitions and lvm on top [22:10] it gets really confusing otherwise ;) [22:10] wow, lilo has the exact same limitation, 16 disks [22:10] anyway, lilo also didn't inst... [22:10] ah that would be why :) [22:11] should I... open a launchpad bug for this? :) [22:11] I guess the expansion to 256 disks is more recent than either [22:11] definitely! [22:11] this shouldn't be hard [22:12] I guess yesterday I was lucky with a slightly different model server, which used /dev/sda and /dev/sdi [22:12] I'm going to bed now, but will be happy to sort this out [22:12] thanks :) [22:12] sleep well [22:12] "Ubuntu now supports installation on machines with up to 256 disks" [22:12] i'll file a bug [22:12] I can get that past management I'm sure ;) [22:13] it sounds like it ;) [22:13] cjwatson: tell them google need it :D [22:13] wikimedia needs it too [22:13] and I think canonical was quite happy with that too ;) [22:13] oh yes [22:14] I think partman supports this OK, but would want to check for random limitations there [22:14] it certainly supports above sdz [22:14] yes it does [22:15] these boxes have 48 disks, and with different boot drives it works fine [22:15] but this is the sort of thing where you might find a random limit somewhere just because hardly anyone needs this [22:15] indeed [22:15] I was just trying to remove all traces of solaris on these boxes... [22:16] looks like libparted is agnostic about this. good [22:17] hmm what package should I report the bug on? [22:18] well, it has stupid code that looks at hd[a-h] and sd[a-f]; but that's ok because it looks through /sys/block/ anyway [22:18] mark: I'd recommend one bug with three tasks, one on each of lilo, grub, and grub2 [22:18] mark: i.e. pick one of those for the initial bug report, then "Also affects distribution" and select each of the others in turn [22:18] ok [22:21] please also assign it to me so that it doesn't fall off [22:21] and to deter bug triagers from doing the wrong thing overnight :-) [22:21] perhaps say that I asked you to file the bug [22:21] ok [23:45] cjwatson: bug 328097 [23:45] Launchpad bug 328097 in partman-auto "preseeding partitionning isn't working anymore hardy 8.04.2" [Undecided,Incomplete] https://launchpad.net/bugs/328097