[04:36] <svdasein> I'm having a bit of trouble getting 10.04's installer working right with the  serial console on my soekris board here.  Anyone here have any experience w/ that and/or can recommend another group?
[09:20] <ara> hello!
[09:21] <ara> I am trying to install ubuntu server (natty daily) in some servers with preseed, but in most of the systems it is stuck because it asks for a partition table to use
[09:22] <ara> could it be that the prior installation (also natty) corrupted the partition table somehow?
[09:24] <ara> this is the preseed file that I am using: http://paste.ubuntu.com/556098/
[11:10] <Jemt> Not sure this is the place to ask, but this channel seems to be the best place to find technical assistance.
[11:13] <Jemt> I'm remastering Ubuntu. One of my very last steps before creating my new ISO, is upgrading all packages (apt-get upgrade). Unfortunately this results in a lot of errors/warnings from dpkg: "dpkg: error processing gconf2-common (--configure): dependency problems - leaving unconfigured". Another common error is this: "dpkg: dependency problems prevent configuration of compiz-gnome: compiz-gnome depdends on libgconf2-4 (>= 2.31.1); however:
[11:13] <Jemt> package libgconf2-4 is not configured yet". Are these just warnings, or actual errors which may render my remastered edition of Ubuntu buggy ?
[11:38] <cjwatson> ara: I'll need to see logs
[11:39] <cjwatson> Jemt: they're actual errors (unless they got cleaned up later - see whether 'dpkg --configure -a' still produces errors).  are you sure you should be using 'apt-get upgrade' rather than 'apt-get dist-upgrade'?
[11:39] <ara> cjwatson, let me get them for you, thanks
[11:40] <Jemt> cjwatson: Nope, not sure. I'm actually trying dist-upgrade now. I'll post the result when it's done
[11:41] <Jemt> However, apt-get reported an estimated use of additionally 200 MB disk space. If that's true, upgrading the remastered edition is not an option.
[11:41] <Jemt> But let's see how it goes
[11:44] <ara> cjwatson, http://paste.ubuntu.com/556126/
[11:44] <ara> cjwatson, I tried in several servers with the same results
[11:48] <cjwatson> Jemt: you could remove stale packages afterwards ...
[11:48] <Jemt> stale ?
[11:48] <cjwatson> (that might be mostly a new kernel)
[11:48] <cjwatson> well, do you understand why dist-upgrade might produce different results from upgrade?
[11:48] <Jemt> Actually apt-get removed kernel-headers after upgrading, so it released almost 95 MB
[11:49] <Jemt> cjwatson: According to the man it has better conflict resolution. Other then that, I don't know much about it
[11:50] <cjwatson> Jemt: dist-upgrade is willing to install packages that aren't installed yet, if dependencies require it
[11:50] <cjwatson> (and also to remove packages if conflicts require it, but that's less important in this case)
[11:50] <Jemt> I see
[11:50] <Jemt> Yes
[11:50] <cjwatson> upgrade will only ever install new versions of packages you already have
[11:51] <cjwatson> this means that if, say, the linux-image-generic package starts depending on linux-image-2.6.35-23-generic rather than linux-image-2.6.35-22-generic, then dist-upgrade will install linux-image-2.6.35-23-generic
[11:51] <cjwatson> however, it will generally leave the old packages installed too, unless there's a specific reason to remove them
[11:51] <Jemt> But I don't see how "apt-get upgrade" can result in dependency problem. I have never experienced anything like that in a normal environment
[11:51] <cjwatson> that's what I mean by stale packages
[11:51] <cjwatson> 'apt-get autoremove' may remove some of those
[11:52] <Jemt> Ah, okay, I see
[11:52] <Jemt> Well, dist-upgrade is what I want then. Never the less, I still get lots of errors.
[11:52] <cjwatson> it shouldn't normally; I was suggesting dist-upgrade because it's slightly less likely to run into bugs
[11:52] <cjwatson> ok, if dist-upgrade does the same, then probably what's happening is that some package's maintainer script is failing
[11:52] <cjwatson> you haven't given me enough of the output from dpkg for me to be able to tell what that is
[11:52] <Jemt> I doubt it. I upgraded my host environment without problems
[11:53] <cjwatson> can I see the full output from 'apt-get upgrade', please?
[11:53] <Jemt> Hang on, placing it on pastebin :)
[11:54] <CIA-47> ubiquity: superm1 * r4483 ubiquity/ (bin/oem-config-remove-gtk debian/changelog): Fix oem-config-remove-gtk for changes in AptClient's commit_packages.
[11:55] <Jemt> Unfortunately I didn't pipe the output to a file, so I don't have the entire output, only what's available in my console buffer: http://pastebin.com/Tz6ysqNr
[11:55] <Jemt> If you want, I can run the upgrade again on a clean ISO, to produce all the output
[11:56] <Jemt> And again, I'm performing the upgrade while remastering Ubuntu (I "chrooted" into the squash-fs)
[11:57] <Jemt> Well, the _extracted_ squash FS
[11:57] <cjwatson> I can't tell from that log - the initial error is before the start
[11:58] <cjwatson> what you need to look for is the *first* failure
[11:58] <cjwatson> did you remember to bind-mount /dev, /proc, and /sys into the chroot?
[11:58] <cjwatson> I don't know if all of those will be necessary, but I wouldn't generally want to try to upgrade things without that
[11:58] <cjwatson> ara: thanks, this looks rather odd, I'll investigate
[11:59] <cjwatson> ara: I might be wrong, but I don't think it can have anything to do with the prior partition table
[11:59] <cjwatson> ara: can I have /var/log/partman as well, in case that's necessary?
[11:59] <Jemt> Hm, no, I only bind mount /dev
[11:59] <ara> cjwatson, sure, do you want me to file a bug against debian-installer?
[11:59] <Jemt> I'll try bind mounting your suggestions too, and re-run the upgrade. I'll post the result afterwards
[12:03] <ara> cjwatson, http://paste.ubuntu.com/556135/
[12:03] <Jemt> I'm away for about 30 minutes. The upgrade should be done then
[12:08] <cjwatson> ara: sure, this is pretty bizarre
[12:08] <cjwatson> ara: it should be reproducible without any preseeding, I think?
[12:08] <ara> cjwatson, I haven't tried
[12:08]  * ara files a bug against d-i
[12:11] <CIA-47> ubiquity: evand * r4484 trunk/ (156 files in 3 dirs): Update translations from Launchpad.
[12:15] <ara> cjwatson, bug https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/705377
[12:15] <ubot2> Launchpad bug 705377 in debian-installer (Ubuntu) "Debian installer prompts for partition type when installing Ubuntu server (affects: 1) (heat: 6)" [Undecided,New]
[12:15] <ara> cjwatson, thanks!
[12:16] <cjwatson> I'll try it interactively and see what happens
[12:39] <Jemt> cjwatson: Alright, update result is now available at http://pastebin.com/rh51MafV
[12:40] <Jemt> Initial error seems to be related to dbus
[12:40] <Jemt> (Line 1615)
[12:41] <cjwatson> it might be worth bind-mounting /var/lock and /var/run as well then.  however, I don't actually know very much about dbus, and it isn't part of the installer
[12:42] <cjwatson> all your other problems seem to arise from that
[12:42] <Jemt> Okay, I was thinking about trying that too. Wasn't sure whether it could cause other problems though.
[12:43] <cjwatson> I'm not sure about that, I'm afraid
[12:43] <Jemt> After all, the "guest environment" (into which I "chrooted") share resources with the host environment. But it's not a critical computer, so if something breaks, it can easily be restored
[12:44] <Jemt> I'll give it a try. Thanks  :)
[12:59] <cjwatson> ara: broken by superm1's latest change to partman-partitioning
[12:59] <cjwatson> I'll fix it up
[13:02] <cjwatson> superm1: perhaps check with me before changing d-i components, sometimes they can be subtle ...
[13:03]  * cjwatson rebases partman-partitioning onto the git migration first
[13:07] <cjwatson> (though of course it was my fault that ubiquity broke ...)
[13:09] <CIA-47> partman-partitioning: cjwatson * r899 ubuntu/ (debian/changelog lib/disk-label.sh):
[13:09] <CIA-47> partman-partitioning: Use 'type' to check for archdetect on PATH, not 'which', which isn't
[13:09] <CIA-47> partman-partitioning: available in d-i (LP: #705377).
[13:10] <CIA-47> partman-partitioning: cjwatson * r900 ubuntu/debian/ (7 files in 2 dirs): merge from Debian 79
[13:12] <Jemt> cjwatson: Thank you very much for your help. Bind mounting /var/run and /var/lock solved the problem. I took a look at UCK (Ubuntu Customization Kit), which seems to do the same (except mounting /var/lock - probably not necessary). However, UCK doesn't do bind mounts - it mounts the resources without the --bind argument. Not sure why. But using --bind ensure the use of the same mount options, so I'll stick to that
[13:14] <Jemt> cjwatson: Did you find time to look at the e-mail I sent you ?
[13:15] <cjwatson> not yet, sorry
[13:16] <Jemt> No problem. The problem was not as urgent as the one we just solved :-)
[13:18] <cjwatson> ev: looks like you forgot to push your casper change to lp:ubuntu/casper?
[13:18] <cjwatson> ev: I've just committed a few other things and got a reject on upload - can you push your branch somewhere and I'll merge and fix it up?
[13:18] <CIA-47> partman-partitioning: cjwatson * r901 ubuntu/debian/changelog: releasing version 79ubuntu1
[13:30] <ara> cjwatson, thanks
[13:54] <Jemt> "mount --bind /dev/ extracted_squash_fs/dev"  <= Wouldn't you guys expect /dev/pts to be mounted in squash fs too ?
[13:54] <Jemt> INstalling a package gave me this error: "Can not write log, openpty() failed (/dev/pts not mounted?)"
[13:56] <cjwatson> that's a warning you can ignore
[13:56] <cjwatson> /dev/pts is a separate filesystem; bind-mounting /dev won't bind-mount it too.  See the documentation for mount --bind.  If you want to bind submounts too then you can use --rbind
[13:56] <Jemt> Yes, but I'm still confused. Bind mounting /dev should give me everything in dev, right ?
[13:56] <Jemt> Oh
[13:56] <Jemt> Thank you
[13:57] <ev> cjwatson: will do.  Sorry about that.  I normally have the branch bound, but I had to recreate it recently.
[13:58] <ev> cjwatson: lp:~ev/casper/whoops
[13:58] <cjwatson> ta
[14:00] <superm1> cjwatson, oh sorry. i didn't realize something like which wouldn't be available in d-i.
[14:00] <superm1> i'll make sure to test both d-i and ubiquity in the future if changing something that will affect both rather than just ubiquity
[14:00] <cjwatson> yeah, tools are often pretty restricted
[14:00] <cjwatson> thanks
[15:39] <Jemt> How is /boot/initrd.img-[version]-generic compressed ? The .img extension puzzles me, since .lz is used in LiveCD/Casper
[15:40] <cjwatson> gzip
[15:40] <cjwatson> (use the 'file' command)
[15:40] <cjwatson> the file naming is more or less historical; changing it would have tentacles all over the place so we'd rather not
[15:42] <Jemt> I see
[15:43] <Jemt> file didn't reveal the compression though
[15:43] <Jemt> output:  initrd.lz: data
[15:45] <cjwatson> it might not work on lzma - it works on /boot/initrd.img-blah
[15:45] <cjwatson> anyway, .lz is lzma compression
[15:46] <cjwatson> we recompressed the initrd for the live CD to save space, since the space/time tradeoff is different on live cDs
[15:46] <cjwatson> CDs
[15:47] <Jemt> Mmm, okay. The thing is, I just upgraded the remastered edition, which gave me a more recent kernel. I'd better copy that kernel to LiveCD/Casper, to have it boot with the new kernel. But I should probably use the more recent initrd too
[15:48] <Jemt> I guess I have to decompress the new initrid.img file and recompress it as lzma
[15:49] <cjwatson> right, although it's certainly possible to copy it to initrd.gz and change isolinux.cfg if you don't want to bother recompressing it
[15:49] <Jemt> Even better. I can simply copy it to .gz ? Why not keep the .lz extension ?
[15:50] <Jemt> sorry, .img extension - why not keep that ?
[15:50] <cjwatson> er, well, it would be pretty confusing to call it .lz if it's gzip-compressed :-)
[15:50] <Jemt> Yes, sorry. I wanted to keep the .img extension :)
[15:51] <cjwatson> I wouldn't advise it - I'm not certain that isolinux can cope with filenames outside the 8.3 format in all cases
[15:51] <Jemt> Okay, I'll use .gz :)
[15:51] <cjwatson> of course it'll be bigger, I don't know what your space pressures are like
[15:52] <Jemt> Wow, yes - much much bigger - almost 10 times
[15:52] <Jemt> lzma sure is effective
[15:53] <Jemt> Well, I think I can squeeze it to fit on the CD
[15:54] <Jemt> Hm, an alternative solution would be to hold back the kernel during upgrade, to keep the kernel used on the Live CD
[15:54] <Jemt> I'll take a moment to think it over
[15:55] <cjwatson> 10x would be pretty unusual; it's only 1.4 times bigger with gzip versus lzma here
[15:55] <cjwatson> (real system initrd, not live CD initrd)
[15:56] <Jemt> Mine is 10.762.373 bytes (initrd.img-2.6.35-22-generic)
[15:56] <Jemt> Odd
[15:57] <Jemt> Do you have the same version ?
[15:58] <cjwatson> what did you do to test that it's 10x smaller when lzma-ing?
[15:59] <Jemt> "ls -la /boot" on my laptop vs "ls -la /LiveCDMounted/casper" on the mounted ISO
[15:59] <Jemt> Oh, sorry
[16:00] <Jemt> I missed a digit in one of them. Sorry, they are almost identical in size
[16:00] <Jemt> Actually the new .img is a bit smaller
[16:02] <cjwatson> also they don't contain the same things.
[16:02] <Jemt> Yes, probably not
[16:02] <cjwatson> the initrd is built dynamically
[16:02] <cjwatson> hence why I didn't answer your version question, because it's mostly irrelevant :)
[16:02] <Jemt> So it would be different on different computers ??
[16:03] <Jemt> I didn't see any build processes running during upgrade
[16:10] <cjwatson> yes.  that's what update-initramfs does
[16:10] <Jemt> Hm, I wonder whether it's a good idea to upgrade the kernel then
[16:10] <cjwatson> in particular, casper - the component that deals with the special arrangements needed to boot a live CD - lives in the initramfs
[16:11] <cjwatson> it is not possible to boot a live CD with the same initrd that you use to boot an installed system
[16:11] <Jemt> Okay, important point :)
[16:11] <Jemt> I would still like to get the most recent kernel, but will it boot with the "old" initrd.lz on the Live CD ?
[16:12] <cjwatson> no
[16:12] <cjwatson> at least not if the ABI (the 2.6.35-22 part) has changed
[16:12] <Jemt> Upgrading the kernel sounds like a really bad idea then. I'll keep it back while upgrading then
[16:13] <Jemt> I'm glad we had this conversation. Otherwise I would have shipped a mess to the school waiting for this customized version of Ubuntu :)
[16:59] <cjwatson> ev: do you have any ideas on what to do about bug 562312?  difficult problem ...
[17:02]  * ev reads
[17:05] <ev> I don't suppose we could do something clever with grub2 like get the kernel and initramfs out of the casper-rw ext3 image?  Forgive me if that's nonsensical, I'm running almost entirely off coffee today.
[17:06] <ev> cjwatson: ^
[17:06] <cjwatson> ev: yes, but relies on switching to grub2, and we ought to do something about older releases if possible
[17:07] <cjwatson> it even bit pitti when he was trying to validate a casper SRU
[17:07] <ev> sure, but we should do both :)
[17:07] <ev> as in I'm happy to make the UI change as a backport, but want a better solution than handling it in the UI
[17:08] <cjwatson> actually your suggestion would rely on some kind of union filesystem handling in grub2
[17:08] <cjwatson> which seems ... likely to be interesting
[17:08] <cjwatson> I suppose you could just conditionalise it or something
[17:43] <ev> can you elaborate? My thought was to try to read it from inside casper-rw if it exists, otherwise look in the normal location.
[17:43] <ev> is that what you mean by conditionalize?
[17:43] <ev> sorry for the delay, I was trying to play around with aufs, but it just doesn't like me today
[17:44] <cjwatson> that's what I meant, yes
[17:44] <ev> are you happy with that? (If so, I can brain dump onto the bug)
[17:44] <cjwatson> it's ok for whenever we manage to get to grub2 on the live images, just don't bank on that being soon :(
[17:45] <ev> sure, I just want to make it clear to everyone that it's the end goal, rather than the ugly UI living forever
[17:45] <cjwatson> yeah
[17:46] <cjwatson> could we just cap the amount of space you're allowed to use in casper-rw to allow enough space for a kernel and initrd?
[17:46] <cjwatson> rather than further uglifying the UI
[17:46] <ev> sure
[17:46] <cjwatson> I realise the size is not entirely constant but it doesn't vary all that much really
[17:48] <ev> I've updated the bug
[17:48] <cjwatson> thank
[17:48] <cjwatson> s
[17:48] <ev> sure thing
=== charlie-tca is now known as charlie-tca__
=== charlie-tca__ is now known as charlie-tca
[20:35] <Jemt> cjwatson: Hello again. You mentioned that update-initramfs builds an image specific to my box. Do you know where I can find more information about this? I wonder how the initrd.lz was build for the Live CD, which must be some sort of "generic" ram disk.
[20:37] <cjwatson> I didn't say it was necessarily *very* specific to your box, just that in principle it can be.
[20:37] <cjwatson> depends on what's in initramfs.conf
[20:37] <cjwatson> (/etc/initramfs-tools/)
[20:37] <cjwatson> we generally use MODULES=most which is pretty generic, but some people have particular needs and strip it down or add stuff or whatever
[20:38] <Jemt> Okay, I will take a look at the configuration file
[20:38] <Jemt> I see
[20:38] <cjwatson> the real difference though is that the casper package is installed when building the initramfs for the live CD.
[20:38] <Jemt> Oh yes, I forgot
[20:38] <cjwatson> genericness isn't likely to be a problem; I just wanted to steer you away from the incorrect notion that there was just one initramfs for any given kernel version
[20:40] <Jemt> Yes, I get it now. I'll have my computer compile a new custom Ubuntu edition tomorrow. It takes well over an hour, and I'm on my way to bed. Hopefully holding back the kernel when upgrading works.
[20:41] <cjwatson> ev: could you update umenu/wubi/whatever for the upcoming 10.04.2 point release, please?
[20:53] <Jemt> I'm off. Thanks for all your help, watson
[20:55] <CIA-47> console-setup: cjwatson * r374 ubuntu/debian/ (3 files):
[20:55] <CIA-47> console-setup: Correct fix for LP: #634402: explicitly check readability of
[20:55] <CIA-47> console-setup: /etc/default/keyboard and /etc/default/console-setup in initramfs hooks,
[20:55] <CIA-47> console-setup: rather than trying to guard '.' with '||' which doesn't work
[20:55] <CIA-47> console-setup: (LP: #701954).
[20:56] <CIA-47> console-setup: cjwatson * r375 ubuntu/debian/changelog: releasing version 1.57ubuntu3