[00:48] <giosue_c> so i made my own installer with cdimage but it is complaining that it can't find an installable kernel on the cd.
[00:49] <giosue_c> when i drop out to a shell in the installer i am running an i686 kernel
[00:49] <giosue_c> but there are only i386 kernels in the pool
[00:49] <giosue_c> does anyone have any ideas?
[00:50] <giosue_c> perhaps the mirror i created my installer from is missing some stuff...
[00:58] <giosue_c> does anyone know why the linux-generic metapackage is in the restricted part of the pool instead of main?
[01:21] <giosue_c> from a shell i can chroot /target and sure enough apt doesn't find linux-generic
[01:23] <giosue_c> on a normal system i can go to /var/lib/apt/lists and see what apt has found in the Packages files on the repo... but that doesn't work at install time.
[01:23] <giosue_c> any way i can find out what packages apt knows about?
[01:46] <giosue_c> evand, are you there?
[02:46] <giosue_c> when the installer says it can't find an installable kernel in the apt sources.... does that mean there isn't a kernel in the sources or there is one, but it isn't installable?
[02:47] <giosue_c> can anyone offer any suggestion on how to go about troubleshooting this?
[02:56] <giosue_c> hey guys!  this rocks!!!  you can totally look at the syslog on the system that is trying to install
[02:56] <giosue_c> and it tells me my gpg keys are shit
[02:58] <giosue_c> so i guess that could be my problem.  The CDs I created aren't signed or some such...  and so apt can't use the pool on the cd... could that be?
[03:19] <giosue_c> can anyone tell me how to setup cdimage to properly sign the ISO?
[03:20] <giosue_c> I get errors from debian-cd when it tries to sign stuff.
[03:21] <giosue_c> GNUPG_DIR is set
[03:21] <giosue_c> so is SIGNING_KEYID
[11:49] <ganes> cjwatson, i checked the uuid file under .disk as well as on conf .. its there but not booting
[11:49] <ganes> cjwatson, i feel the problem is somewhere
[11:50] <cjwatson> I'm afraid I can only suggest that you compare your images very carefully to normal Ubuntu images and ensure that you have accounted for all differences
[11:51] <cjwatson> point 1: Ubuntu images boot. point 2: yours don't. point 3: there are some differences between Ubuntu images and yours. the conclusion would be to examine the differences one by one
[11:51] <ganes> cjwatson, tell me suggestion
[11:51] <cjwatson> not having your images to hand, I cannot help
[11:52] <ganes> is anything modify in casper script
[11:52] <ganes> is anything need to modify in casper script
[11:54] <cjwatson> not having your images to hand, I cannot help
[11:54] <CIA-1> cdrom-checker: cjwatson * r240 cdrom-checker/ (64 files in 3 dirs): merge from Debian 1.14
[11:54] <cjwatson> (oops, misnamed branch)
[12:11] <CIA-1> cdrom-checker: cjwatson * r241 ubuntu/debian/changelog: releasing version 1.14ubuntu1
[14:59] <xivulon> evand, couple of thinsg
[15:00] <evand> ok
[15:00] <xivulon> you need to do a clean build with rev 502, i.e. remove src, bzr revert and make prerequisites
[15:00] <xivulon> also the self extracting version creates an issue
[15:01] <xivulon> many users know that they can download the ISO manually and place it in the same folder as wubi.exe to avoid the download
[15:01] <xivulon> this does not work anymore, since the selfextracting version runs off temp and I do not know where the original exe was located
[15:01] <xivulon> I would probably think that it is better to use the selfextracting exe only within the CD
[15:03] <xivulon> the selfextracting exe was in turn required by the vista bug that froze the installer on CD eject
[15:04] <evand> I don't see a major problem with using the self-extracting exe only on the CD, though I thought you said it wasn't working in all cases?
[15:05] <xivulon> that works, only caveat is the above
[15:05] <xivulon> the makefile now only generates a selfextracting ISO, I will have to change it to produce both
[15:06] <xivulon> you can still use a pre-downloaded ISO but you have to place it in your desktop
[15:07] <evand> ok
[16:44] <cr3> cjwatson: I would like to make a request so that information about the ISO image used to install a system, such as provided under .disk/info, be stored under /var/log/installer during the installation. what would be the proper way to make such a request?
[16:45] <cjwatson> cr3: it already lands in the syslog
[16:45] <cjwatson> e.g. from my system:
[16:45] <cjwatson> Sep 11 14:30:31 cdrom-detect: Detected CD 'Ubuntu 7.10 "Gutsy Gibbon" - Alpha i3
[16:45] <cjwatson> 86 (20070911)'
[16:46] <cjwatson> should be the same from the alternate CD
[16:46] <cr3> cjwatson: is it possible to determine whether a system was installed from live or alternate?
[16:47] <cr3> cjwatson: also, could we do something similar for netinstalls and provide: initrd-detected: some identifier
[16:47] <cjwatson> err, actually the above is from the alternate CD
[16:48] <cjwatson> desktop CD installs have something similar though
[16:48] <cr3> cjwatson: ok, I don't mind having to search for this information in different locations for alternate and desktop installs, at least that implicitly addresses my concern of distinguishing the two types of install :)
[16:49] <cjwatson> I don't think the initrd actually has its own build version embedded right now, but you could file a bug on debian-installer for that
[16:49] <cjwatson> however, searching for kernel versions in there should be close enough for most purposes, even though I acknowledge it isn't perfect
[16:50] <cjwatson> the desktop installer also writes /var/log/installer/version with ubiquity's version number
[16:50] <cr3> cjwatson: if there was something installed on the system which was guaranteed to change for each daily iso, I could probably have heuristics to map this information to an ISO release
[16:51] <stgraber> the idea is to have a way of knowing the exact ISO images the user used to install his computer
[16:52] <cjwatson> the ISO version is definitely going to be in the syslog, either way
[16:52] <cjwatson> I'm nearly certain it's there for ubiquity, but if it isn't, file a bug on ubiquity for it
[16:52] <cr3> for example, if a package version was consistently updated for every daily iso image, I'd be set!
[16:52] <cjwatson> that is not the case
[16:53] <stgraber> cr3: with the ISO build number and a way of detecting if it's Desktop or Alternate I think we're good
[16:53] <cjwatson> of course, note also that the initial list of installed packages and versions is saved in /var/log/installer/initial-status.gz
[16:53] <cjwatson> which may also be useful depending on exactly what you're trying to do
[16:53] <cr3> I'm not surprised, I can't imagine a use case other than my own twisted one which would make sense to consistently update a package version :)
[16:54] <cr3> cjwatson: dude, that might be just what I'm looking for!
[16:54] <cr3> cjwatson: I could md5sum that and map it to known ISO images in my database, and voila!
[16:54] <cjwatson> sounds a whole lot harder than just picking it out of the syslog
[16:55] <cjwatson> don't md5sum it, that'll be sensitive to different installation options
[16:55] <cr3> cjwatson: works with netinstalls though
[16:55] <cjwatson> making guesses based on the kernel version will be a lot more reliable for netboot installations
[16:55] <cjwatson> yes, it'll only give you a range, but still
[16:55] <cr3> cjwatson: ok, no md5sum, but effectively searching the database for a matching set... which might not work because of updates being downloaded during install :(
[16:56] <cjwatson> it really depends on what question you're actually trying to answer in the case of a netboot installation
[16:56] <stgraber> cr3: we should just : check in syslog for the cdrom-detect line, if not found check for the ubiquity equivalent, if not found either check for the kernel version and guess what netboot image was used
[16:57] <cjwatson> I doubt that there is a single parameter that will help you answer all questions
[16:57] <cr3> cjwatson: I see, very good point
[16:57] <cjwatson> the precise netboot image version is unlikely to matter a whole lot, in any case
[16:57] <stgraber> cr3: with the kernel version we can now what mini.iso was used and with the .gz you'll know the package version if necessary (as netboot just downloads everything from archive)
[16:58] <cjwatson> after all, it only contains the bits of the installer necessary to retrieve the rest of the installer
[16:58] <cr3> yep, I think we have enough information to make a best effort guess and provide relevant data
[16:58] <cjwatson> /var/log/installer/status can be useful in netboot cases too - versions of installer components
[16:58] <cr3> stgraber: in order to test netboot effectively, the archive should be an iso image. if you just test from archive.ubuntu.com, you're not testing an iso image
[16:59] <cjwatson> if you test with an ISO image, you're also not performing a very realistic test
[17:00] <cjwatson> rather few people actually use that kind of setup
[17:00] <stgraber> cr3: that's why we only test netboot when archive is frozen, so all netboot installs are done with the same packages
[17:01] <cr3> cjwatson: if all necessary packages are provided on the ISO, it is nonetheless relevant to know that a netboot installation worked at a specific point in time, ie the time the image was built
[17:01] <cjwatson> is this for the purpose of attaching information to qa.ubuntu.com reports, or is it for the purpose of supporting customers, or is it for the purpose of filing bug reports about specific problems?
[17:01] <cr3> cjwatson: 1 and 3
[17:01] <cjwatson> cr3: sure, but I don't want our tests to be entirely reliant on that
[17:02] <cjwatson> cr3: the information that's important for 3 is completely different to the information that's important for 1 ...
[17:02] <cr3> cjwatson: other than not being very realistic, I don't quite understand how netinstalling from a mounted iso image fails to be relevant in some cases
[17:02] <cjwatson> for bug reports, we absolutely don't want just an image version, and in some cases that may even be misleading
[17:03] <cjwatson> cr3: there are certain classes of bugs that *only* show up in that environment, and others that will never show up in that environment
[17:03] <cr3> cjwatson: for bug reports, we need a lot more information such as syslog and problem-specific information, granted
[17:03] <cjwatson> so I don't want to get to the point where we're releasing and the only netboot testing that's been done is off a mounted ISO image
[17:04] <cr3> cjwatson: ok, I'm taking a note of that
[17:04] <cjwatson> since the bugs that only show up in that environment typically also only show up post-release, if anything I'd rather that netboot testing generally be done from the real archive
[17:04] <cjwatson> but I don't mind if it's both, for convenience
[17:05] <cr3> cjwatson: is there any point in testing against the archive on each computer or only on each architecture?
[17:06] <cjwatson> it should be the default for netboot tests, if reasonable
[17:06] <cjwatson> e.g. by using a local mirror
[17:06] <cr3> cjwatson: right, but I could additionally test once for each architecture against the archive, eg remote mirror
[17:06] <cjwatson> a test on each architecture would probably be fine
[17:07] <cjwatson> any archive mirror with a reasonably default setup would be fine
[17:07] <cjwatson> I don't expect significantly different bugs from ca.archive.ubuntu.com and archive.ubuntu.com, for example
[17:07] <cjwatson> assuming ca.archive.ubuntu.com basically works
[17:07] <cjwatson> no point in loading up archive.ubuntu.com further
[17:07] <cr3> cjwatson: what about defaulting to a remote archive, archive.ubuntu.com for example, and use a squid proxy?
[17:07] <cjwatson> sure, you could do that
[17:08] <cr3> cjwatson: ie, are there other types of significant bugs I could encounter with this proxy?
[17:08] <cjwatson> not so much that I'd be worried
[17:08] <cjwatson> it would be best if it were a real proxy rather than a "transparent" proxy
[17:08] <cjwatson> see lifeless for lessons if you want to know why ;-)
[17:09] <cjwatson> the thing that looks like an archive on an ISO image is actually set up somewhat differently than any normal mirror, though; it's that distinction I think is most likely to make a difference
[21:10] <CIA-1> partman-target: cjwatson * r724 ubuntu/debian/ (8 files in 2 dirs): merge from Debian 55
[21:13] <CIA-1> partman-target: cjwatson * r725 ubuntu/debian/changelog: releasing version 55ubuntu1