| CIA-32 | ubiquity: cjwatson * r5380 trunk/ (5 files in 3 dirs): Update translations from Launchpad. | 10:41 |
|---|---|---|
| cjwatson | ev,stgraber: any ideas on bug 982883? It's obviously that panel.png no longer exists in the theme, and I've been trying to replace it with something like http://paste.ubuntu.com/933841/, but can't get it to work | 11:39 |
| ubot2 | Launchpad bug 982883 in ubiquity "Wrong color of top panel in ubiquity-dm" [High,Triaged] https://launchpad.net/bugs/982883 | 11:39 |
| cjwatson | jibel: bug 979350 - is that any better now? | 11:42 |
| ubot2 | Launchpad bug 979350 in ubiquity "install with encrypted home failed near the end: OSError: [Errno 12] Cannot allocate memory" [High,Confirmed] https://launchpad.net/bugs/979350 | 11:42 |
| cjwatson | following my webkit cache tweak | 11:43 |
| stgraber | cjwatson: hmm, that looks good ... only difference I see with some code I have around is that I've been using GTK_STYLE_PROVIDER_PRIORITY_APPLICATION which is IIRC higher priority than _THEME | 11:43 |
| stgraber | but in panel.c's case we shouldn't have an higher priority override of these bits so _THEME should work fine... | 11:43 |
| cjwatson | _APPLICATION doesn't help, anyway | 11:47 |
| stgraber | cjwatson: do you get the same result if you just add the class to the panel and copy/paste the .unity-panel class to the hardcoded css in panel.c? at least we know that this bit of css gets loaded (took quite a few tries to find the right incantation to have it load, all the others silently failing) | 11:48 |
| cjwatson | yes | 11:51 |
| cjwatson | curious | 11:51 |
| * cjwatson tries shoving it straight into the GtkMenuBar bit | 11:51 | |
| cjwatson | even that makes no difference, WTF | 11:52 |
| cjwatson | oh, it relies on definitions in gtk.css, maybe I need to load the whole thing | 11:53 |
| cjwatson | copied the entire thing in (http://paste.ubuntu.com/933863/) and it still doesn't work; I'm stumped | 11:57 |
| cjwatson | maybe we should just copy the old panel.png into our package :-P | 12:01 |
| stgraber | cjwatson: that sounds like the easiest for now ;) that gtk3 css stuff is really weird... | 12:08 |
| CIA-32 | ubiquity: cjwatson * r5381 trunk/ (4 files in 3 dirs): | 12:24 |
| CIA-32 | ubiquity: Copy the panel gradient from light-themes 0.1.8.25 (Ubuntu 11.10) and | 12:24 |
| CIA-32 | ubiquity: use it as a fallback in case other panel images cannot be found. The | 12:24 |
| CIA-32 | ubiquity: correct fix would be to use CSS instead, but I can't seem to make this | 12:24 |
| CIA-32 | ubiquity: work at the moment (LP: #982883). | 12:24 |
| jibel | cjwatson, it still fails on Precise. It passes on oneiric with the same setup, the system uses slightly less memory (~130MB) | 12:43 |
| cjwatson | hmph | 12:43 |
| jibel | during an installation of Precise without encrypted home, the system happily uses up to 390MB of swap and 720MB of physical memory | 12:43 |
| jibel | *precise amd64 | 12:44 |
| cjwatson | minus buffers/caches? | 12:44 |
| jibel | yes | 12:44 |
| jibel | during an installation with an encrypted home swap is off, hence the memory allocation failure. | 12:44 |
| cjwatson | that's odd in itself | 12:44 |
| jibel | swap is wiped and turned off in user-setup when encrypt-home is set | 12:45 |
| cjwatson | hm, well, we have to wipe the swap, it's kind of crappy that it's done so late though, rather than immediately after the swap is created | 12:45 |
| cjwatson | but not sure it can sanely be moved around at this point ... | 12:45 |
| jibel | I also compared with i386 and the average physical memory usage is 28.4% higher on amd64 | 12:45 |
| cjwatson | that's certainly not much of a surprise | 12:46 |
| cjwatson | other thing that's odd: user-setup-apply never turns swap back on | 12:47 |
| jibel | this is how memory usage looks like during an installation of precise amd64 with encrypted home with 1GB of RAM http://people.canonical.com/~j-lallement/installation_memusage/mem_precise_amd64_1024_encrypted.png | 12:52 |
| cjwatson | ev: so why exactly do we have to zero out swap in the ecryptfs case? | 12:54 |
| cjwatson | ev: oh, maybe because there was unencrypted data there? | 12:59 |
| cjwatson | hmm | 13:02 |
| jibel | is /target/etc cleared when a user upgrades from previous release with ubiquity ? | 13:03 |
| jibel | or is bug 983931 cosmic rays again ? ;) | 13:04 |
| ubot2 | Launchpad bug 983931 in ubiquity "package ubiquity 2.10.12 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/983931 | 13:04 |
| cjwatson | it's supposed to be cleard | 13:07 |
| cjwatson | +e | 13:07 |
| cjwatson | for x in bin dev etc lib lib32 lib64 proc sbin sys; do | 13:07 |
| cjwatson | [ -e "$tmp/$x" ] && (rm -rf "$tmp/$x" && | 13:07 |
| cjwatson | logger -t clear_partitions "Removing $x from / ($path)." || | 13:07 |
| cjwatson | failed) | 13:07 |
| cjwatson | done | 13:08 |
| cjwatson | I have no idea what's going on in that bug. The ubiquity logs attached are from lucid, and ubiquity shouldn't be on installed systems anyway | 13:09 |
| cjwatson | furthermore I don't see how it's connected to clearing of /etc anyway | 13:10 |
| cjwatson | E: /usr/share/initramfs-tools/hooks/casper failed with return 1. | 13:11 |
| cjwatson | looks more like the root cause | 13:11 |
| cjwatson | so this is either an attempt to upgrade a live USB stick from lucid to precise (probably doomed to failure) or a thoroughly broken installation | 13:11 |
| ev | cjwatson: yes, exactly that | 13:37 |
| ev | (zeroing swap) | 13:37 |
| cjwatson | ev: I think the only right answer is to move that code to a partman hook, but I'm not yet sure whether that can be done safely at this point | 14:47 |
| bdmurray | wubi.exe no longer appears on the cd's correct? | 14:47 |
| cjwatson | it should still be on the CDs, but doesn't offer Wubi installation | 14:49 |
| cjwatson | (it also serves for the other autorun stuff) | 14:49 |
| cjwatson | ev,stgraber: do you think we could get an updated slide for bug 983833? I wonder if that was accidental or deliberate | 14:50 |
| ubot2 | Launchpad bug 983833 in ubiquity-slideshow-ubuntu "Time in slideshow is set to 11:10 but should be 12:04" [Undecided,New] https://launchpad.net/bugs/983833 | 14:50 |
| stgraber | cjwatson: I'm actually preparing an ubiquity-slideshow-ubuntu upload now. The current screenshots are 11.10, the new upload will have 12.04 | 14:52 |
| cjwatson | ah good, thanks | 14:53 |
| cjwatson | stgraber: did you see https://lists.ubuntu.com/archives/ubuntu-doc/2012-April/016546.html ? | 14:59 |
| cjwatson | "Actually, in this case, the installer slideshow is affected by this: it has | 14:59 |
| cjwatson | a blackish band at the top that is meant to mimic Ubiquity. Whatever is | 14:59 |
| cjwatson | changed there should be changed in the slideshow as well." | 14:59 |
| stgraber | I somehow fail to parse Dylan's reply :) | 15:05 |
| stgraber | the installer slideshow (just checked with the one I'm about to upload) has a dark header (same colour as the panel) containing the slide title (white text), AFAIK it's been like that for quite a while | 15:07 |
| stgraber | and the colour matches that of the window border and the panel | 15:07 |
| cjwatson | ok, if you're happy I'm happy | 15:11 |
| cjwatson | just wanted to make sure it'd been checked | 15:11 |
| cjwatson | ev: did you get anywhere with the whoopsie-daisy build failure, or do you need help? | 15:35 |
| cjwatson | jibel: what is the X axis on http://people.canonical.com/~j-lallement/installation_memusage/mem_precise_amd64_1024_encrypted.png ? | 15:47 |
| cjwatson | seconds? | 15:47 |
| jibel | seconds | 15:47 |
| ev | cjwatson: still working on it. Got caught up in some other stuff for webops. | 15:48 |
| GrueMaster | cjwatson: We are seeing an issue on Panda using "Guided Partitioning - Full Disk" in netboot. It is creating a /boot as ext4, but trying to mount it as ext2. | 15:57 |
| GrueMaster | This is on a usb drive. | 15:57 |
| ogra_ | GrueMaster, partman-uboot should fix that, but i'm not sure it'll make it for precise (i had way to many distractions due to compiz/unity GLES issues the last week) | 15:59 |
| GrueMaster | does partman-uboot run on panda? I thought it was only triggered for dove? | 16:00 |
| ogra_ | no, thats the issue i'm working on :) | 16:00 |
| ogra_ | it also doesnt know about vfat | 16:01 |
| GrueMaster | On dove/armadaxp it shouldn't care about vfat. | 16:02 |
| GrueMaster | Only omap/omap4. | 16:02 |
| cjwatson | GrueMaster: can I see the preseed file and logs? | 16:02 |
| ogra_ | GrueMaster, yes, indeed | 16:03 |
| GrueMaster | No preseed. This is manual install. | 16:03 |
| GrueMaster | I'll have to rerun with debugging enabled to get meaningful logs. | 16:03 |
| bdmurray | in bug 946663 somebody added a patch of sorts | 16:03 |
| ubot2 | Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Confirmed] https://launchpad.net/bugs/946663 | 16:03 |
| cjwatson | err. not adding random sleeps, no :- | 16:04 |
| cjwatson | ) | 16:04 |
| cjwatson | that's bogus, we need a better solution | 16:04 |
| cjwatson | who's to say any given sleep time is enough | 16:05 |
| bdmurray | right, of course | 16:05 |
| cjwatson | made a suggestion in the bug | 16:05 |
| GrueMaster | cjwatson: syslog is at :http://paste.ubuntu.com/934193/ partman log is at: http://paste.ubuntu.com/934195/ | 16:19 |
| cjwatson | GrueMaster: I'm not entirely sure from this that mounting as ext4 is the problem. That part seems to succeed, and there isn't actually anything intrinsically wrong with letting the kernel automatically choose which filesystem to use and it choosing ext4 | 16:48 |
| cjwatson | Apr 17 16:15:23 main-menu[246]: (process:6570): mount: mounting /dev/sda2 on /tmp/tmp.8afcc0 failed: Invalid argument | 16:49 |
| cjwatson | Apr 17 16:15:23 main-menu[246]: (process:6570): umount: can't forcibly umount /tmp/tmp.8afcc0: Invalid argument | 16:49 |
| cjwatson | Apr 17 16:15:23 main-menu[246]: (process:6570): mount: mounting /dev/sda2 on /tmp/tmp.smcexb failed: Invalid argument | 16:49 |
| cjwatson | Apr 17 16:15:23 main-menu[246]: (process:6570): umount: can't forcibly umount /tmp/tmp.smcexb: Invalid argument | 16:49 |
| cjwatson | Apr 17 16:15:23 main-menu[246]: (process:6570): mount: mounting /dev/sda1 on /target/boot failed: No such device | 16:49 |
| cjwatson | Apr 17 16:15:23 main-menu[246]: (process:6570): mount: mounting /dev/sda1 on /target/boot failed: No such device | 16:49 |
| cjwatson | seems to be the errors here, but I'm having difficulty unpicking that | 16:49 |
| GrueMaster | cjwatson: When I went into the shell and mucked with it manually, I was able to reproduce those errors with "mount /dev/sda1 /target/boot -t ext2". Without "-t ext2" it mounts fine. | 16:50 |
| cjwatson | GrueMaster: this could be something to do with bug 946663 | 16:51 |
| ubot2 | Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Triaged] https://launchpad.net/bugs/946663 | 16:51 |
| cjwatson | GrueMaster: which exact error did you get from "mount /dev/sda1 /target/boot -t ext2"? | 16:52 |
| GrueMaster | mounting /dev/sda1 on /target/boot failed: No such device | 16:52 |
| cjwatson | WTF | 16:52 |
| cjwatson | what does archdetect say? | 16:53 |
| GrueMaster | The filesystem is ext4. | 16:53 |
| GrueMaster | One sec. | 16:53 |
| cjwatson | How did you tell that the filesystem is ext4? | 16:53 |
| GrueMaster | ~ # archdetect | 16:53 |
| GrueMaster | armhf/omap4 | 16:53 |
| GrueMaster | When I mounted it, mount lists it as ext4. | 16:54 |
| cjwatson | That just means that ext4 could mount it. | 16:54 |
| GrueMaster | ~ # mount /dev/sda1 /target/boot/ -t ext2 | 16:54 |
| GrueMaster | mount: mounting /dev/sda1 on /target/boot/ failed: No such device | 16:54 |
| GrueMaster | ~ # mount /dev/sda1 /target/boot/ -t ext4 | 16:54 |
| GrueMaster | ~ # | 16:54 |
| cjwatson | Yeah, but that's something weird. | 16:55 |
| cjwatson | tune2fs -l /dev/sda1 | grep 'Filesystem features:' | 16:55 |
| GrueMaster | Filesystem features: filetype sparse_super | 16:55 |
| cjwatson | That's an ext2 filesystem. | 16:56 |
| cjwatson | The problem isn't that the filesystem is ext4; the problem is that for some reason ext2 is busted | 16:56 |
| cjwatson | It's using ext4 because that isn't busted | 16:56 |
| GrueMaster | I'm not even seeing ext2 in /proc/filesystems. Weird. | 16:57 |
| cjwatson | I suspect that the kernel config is wrong | 16:57 |
| cjwatson | Just trying to verify that | 16:57 |
| GrueMaster | But on both armada & panda? | 16:58 |
| cjwatson | Certainly quite possible | 16:58 |
| cjwatson | Right, so the problem is that ext2 is a module, but your kernel maintainers haven't arranged to deliver the ext2 module in a udeb so that d-i can use it | 17:00 |
| cjwatson | I don't know why it's a module; it's built-in on x86 | 17:00 |
| GrueMaster | Looking at a panda I imaged last week, "CONFIG_EXT2_FS=m", but I am not seeing it in the netboot image. | 17:00 |
| cjwatson | This is a kernel bug and I can't fix it in the installer | 17:00 |
| cjwatson | It's arguably an RC one | 17:01 |
| GrueMaster | I gave up trying to understand the kernel team's logic a long time ago. | 17:01 |
| cjwatson | Please file a bug about this on linux-ti-omap4; I'll be happy to fill in the details | 17:01 |
| GrueMaster | Are you sure ext2 is built-in on x86? | 17:03 |
| cjwatson | Yes | 17:03 |
| cjwatson | wait, I was | 17:03 |
| GrueMaster | Looks like a module on my systems. | 17:03 |
| cjwatson | Ah, they might have changed that since oneiric | 17:03 |
| cjwatson | my local kernel checkout is a bit confused | 17:04 |
| GrueMaster | iirc, there is a qrt kernel test script that specifically looks for this as a module. | 17:04 |
| GrueMaster | And I have been running that on SRU kernels since Maverick. | 17:04 |
| cjwatson | But on x86, ext2 is delivered in the fs-core-modules udeb. | 17:04 |
| cjwatson | This isn't true in linux-ti-omap4. | 17:04 |
| GrueMaster | So the bug is in the udeb part. | 17:05 |
| cjwatson | Yes. That's what they need to fix. | 17:05 |
| GrueMaster | Ok. Working on a bug report now. | 17:06 |
| cjwatson | (precise)cjwatson@osageorange:~/linux-ti-omap4-3.2.0$ diff -u debian.master/d-i/modules/fs-core-modules debian.ti-omap4/d-i/modules/fs-core-modules | 17:09 |
| cjwatson | --- debian.master/d-i/modules/fs-core-modules 2012-01-13 10:30:32.000000000 +0000 | 17:09 |
| cjwatson | +++ debian.ti-omap4/d-i/modules/fs-core-modules 2012-04-11 21:52:55.000000000 +0000 | 17:09 |
| cjwatson | @@ -1,4 +1,3 @@ | 17:09 |
| cjwatson | -ext2 ? | 17:09 |
| cjwatson | jfs ? | 17:09 |
| cjwatson | reiserfs ? | 17:10 |
| cjwatson | xfs ? | 17:10 |
| cjwatson | ^- smoking gun | 17:10 |
| GrueMaster | yep, that would do it. | 17:11 |
| bdmurray | could someone look at bug 980676? | 17:14 |
| ubot2 | Launchpad bug 980676 in ubiquity "migration-assistant causes an install failure when encountering another OS with multiple users" [Undecided,Confirmed] https://launchpad.net/bugs/980676 | 17:14 |
| cjwatson | GrueMaster: BTW, just double-checked, ext2 was definitely built-in on i386 in oneiric, qrt script or no :) | 17:14 |
| cjwatson | GrueMaster: did you say you were seeing this on armadaxp too? ext2 is built-in in the armadaxp config, so it shouldn't have the same bug | 17:16 |
| GrueMaster | Figures. I think I was the only one running the qrt scripts on SRU kernels then. | 17:16 |
| GrueMaster | Is it? I thought they were seeing the same issue. | 17:17 |
| cjwatson | Can't be. Must be something else ... | 17:17 |
| GrueMaster | (I don't have one anymore, so can't easily verify). | 17:17 |
| cjwatson | bdmurray: migration-assistant needs ev, I think | 17:26 |
| infinity | GrueMaster: Where did yours run off to? | 17:28 |
| infinity | (And why didn't it land on my desk?) :P | 17:28 |
| GrueMaster | My...what? Armadaxp? It went to Lexington. | 17:28 |
| ev | looking | 17:34 |
| ev | updated | 17:38 |
| CIA-32 | ubiquity: cjwatson * r5382 trunk/debian/changelog: releasing version 2.10.13 | 19:26 |
| cjwatson | ev: if [ -z "$uuid"]; then | 19:29 |
| cjwatson | ev: in ma-script-utils - could be a cause of "missing ]" | 19:30 |
| infinity | cjwatson: Hrm. I had a user ping me about https://bugs.launchpad.net/ubuntu/+source/casper/+bug/958839 | 19:43 |
| ubot2 | Launchpad bug 958839 in casper "Initrd/vmlinux symbloic links not in /boot directory on PowerPC" [Medium,New] | 19:43 |
| infinity | cjwatson: If the default yaboot looks in /boot, that seems problematic if kernel-img.conf is wrong. :P | 19:44 |
| infinity | Oh, probably more fallout from the livecd-rootfs -> live-build upgrade, I bet. | 19:45 |
| bdmurray | I find bug 974402 worrisome but wasn't able to recreate it | 20:57 |
| ubot2 | Launchpad bug 974402 in ubiquity "No user home directory created on clean install using btrfs" [Undecided,Confirmed] https://launchpad.net/bugs/974402 | 20:57 |
| mfisch | I came across this bug while doing live builds locally and finally realized it wasn't due to my changes. If you need more info, I'm glad to help: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/984442 | 23:07 |
| ubot2 | Launchpad bug 984442 in ubiquity "the April17 build of the ISO has a white bar along the top in the install screen" [Undecided,New] | 23:07 |
| mfisch | The screencap in there explains more than I can with text | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
