/srv/irclogs.ubuntu.com/2008/06/13/#ubuntu-installer.txt

giosue_cso i made my own installer with cdimage but it is complaining that it can't find an installable kernel on the cd.00:48
giosue_cwhen i drop out to a shell in the installer i am running an i686 kernel00:49
giosue_cbut there are only i386 kernels in the pool00:49
giosue_cdoes anyone have any ideas?00:49
giosue_cperhaps the mirror i created my installer from is missing some stuff...00:50
giosue_cdoes anyone know why the linux-generic metapackage is in the restricted part of the pool instead of main?00:58
giosue_cfrom a shell i can chroot /target and sure enough apt doesn't find linux-generic01:21
giosue_con 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_cany way i can find out what packages apt knows about?01:23
giosue_cevand, are you there?01:46
giosue_cwhen 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:46
giosue_ccan anyone offer any suggestion on how to go about troubleshooting this?02:47
giosue_chey guys!  this rocks!!!  you can totally look at the syslog on the system that is trying to install02:56
giosue_cand it tells me my gpg keys are shit02:56
giosue_cso 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?02:58
giosue_ccan anyone tell me how to setup cdimage to properly sign the ISO?03:19
giosue_cI get errors from debian-cd when it tries to sign stuff.03:20
giosue_cGNUPG_DIR is set03:21
giosue_cso is SIGNING_KEYID03:21
ganescjwatson, i checked the uuid file under .disk as well as on conf .. its there but not booting11:49
ganescjwatson, i feel the problem is somewhere11:49
cjwatsonI'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 differences11:50
cjwatsonpoint 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 one11:51
ganescjwatson, tell me suggestion11:51
cjwatsonnot having your images to hand, I cannot help11:51
ganesis anything modify in casper script11:52
ganesis anything need to modify in casper script11:52
cjwatsonnot having your images to hand, I cannot help11:54
CIA-1cdrom-checker: cjwatson * r240 cdrom-checker/ (64 files in 3 dirs): merge from Debian 1.1411:54
cjwatson(oops, misnamed branch)11:54
CIA-1cdrom-checker: cjwatson * r241 ubuntu/debian/changelog: releasing version 1.14ubuntu112:11
xivulonevand, couple of thinsg14:59
evandok15:00
xivulonyou need to do a clean build with rev 502, i.e. remove src, bzr revert and make prerequisites15:00
xivulonalso the self extracting version creates an issue15:00
xivulonmany users know that they can download the ISO manually and place it in the same folder as wubi.exe to avoid the download15:01
xivulonthis does not work anymore, since the selfextracting version runs off temp and I do not know where the original exe was located15:01
xivulonI would probably think that it is better to use the selfextracting exe only within the CD15:01
xivulonthe selfextracting exe was in turn required by the vista bug that froze the installer on CD eject15:03
evandI 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:04
xivulonthat works, only caveat is the above15:05
xivulonthe makefile now only generates a selfextracting ISO, I will have to change it to produce both15:05
xivulonyou can still use a pre-downloaded ISO but you have to place it in your desktop15:06
evandok15:07
cr3cjwatson: 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:44
cjwatsoncr3: it already lands in the syslog16:45
cjwatsone.g. from my system:16:45
cjwatsonSep 11 14:30:31 cdrom-detect: Detected CD 'Ubuntu 7.10 "Gutsy Gibbon" - Alpha i316:45
cjwatson86 (20070911)'16:45
cjwatsonshould be the same from the alternate CD16:46
cr3cjwatson: is it possible to determine whether a system was installed from live or alternate?16:46
cr3cjwatson: also, could we do something similar for netinstalls and provide: initrd-detected: some identifier16:47
cjwatsonerr, actually the above is from the alternate CD16:47
cjwatsondesktop CD installs have something similar though16:48
cr3cjwatson: 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:48
cjwatsonI don't think the initrd actually has its own build version embedded right now, but you could file a bug on debian-installer for that16:49
cjwatsonhowever, searching for kernel versions in there should be close enough for most purposes, even though I acknowledge it isn't perfect16:49
cjwatsonthe desktop installer also writes /var/log/installer/version with ubiquity's version number16:50
cr3cjwatson: 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 release16:50
stgraberthe idea is to have a way of knowing the exact ISO images the user used to install his computer16:51
cjwatsonthe ISO version is definitely going to be in the syslog, either way16:52
cjwatsonI'm nearly certain it's there for ubiquity, but if it isn't, file a bug on ubiquity for it16:52
cr3for example, if a package version was consistently updated for every daily iso image, I'd be set!16:52
cjwatsonthat is not the case16:52
stgrabercr3: with the ISO build number and a way of detecting if it's Desktop or Alternate I think we're good16:53
cjwatsonof course, note also that the initial list of installed packages and versions is saved in /var/log/installer/initial-status.gz16:53
cjwatsonwhich may also be useful depending on exactly what you're trying to do16:53
cr3I'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:53
cr3cjwatson: dude, that might be just what I'm looking for!16:54
cr3cjwatson: I could md5sum that and map it to known ISO images in my database, and voila!16:54
cjwatsonsounds a whole lot harder than just picking it out of the syslog16:54
cjwatsondon't md5sum it, that'll be sensitive to different installation options16:55
cr3cjwatson: works with netinstalls though16:55
cjwatsonmaking guesses based on the kernel version will be a lot more reliable for netboot installations16:55
cjwatsonyes, it'll only give you a range, but still16:55
cr3cjwatson: ok, no md5sum, but effectively searching the database for a matching set... which might not work because of updates being downloaded during install :(16:55
cjwatsonit really depends on what question you're actually trying to answer in the case of a netboot installation16:56
stgrabercr3: 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 used16:56
cjwatsonI doubt that there is a single parameter that will help you answer all questions16:57
cr3cjwatson: I see, very good point16:57
cjwatsonthe precise netboot image version is unlikely to matter a whole lot, in any case16:57
stgrabercr3: 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:57
cjwatsonafter all, it only contains the bits of the installer necessary to retrieve the rest of the installer16:58
cr3yep, I think we have enough information to make a best effort guess and provide relevant data16:58
cjwatson/var/log/installer/status can be useful in netboot cases too - versions of installer components16:58
cr3stgraber: 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 image16:58
cjwatsonif you test with an ISO image, you're also not performing a very realistic test16:59
cjwatsonrather few people actually use that kind of setup17:00
stgrabercr3: that's why we only test netboot when archive is frozen, so all netboot installs are done with the same packages17:00
cr3cjwatson: 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 built17:01
cjwatsonis 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
cr3cjwatson: 1 and 317:01
cjwatsoncr3: sure, but I don't want our tests to be entirely reliant on that17:01
cjwatsoncr3: the information that's important for 3 is completely different to the information that's important for 1 ...17:02
cr3cjwatson: other than not being very realistic, I don't quite understand how netinstalling from a mounted iso image fails to be relevant in some cases17:02
cjwatsonfor bug reports, we absolutely don't want just an image version, and in some cases that may even be misleading17:02
cjwatsoncr3: there are certain classes of bugs that *only* show up in that environment, and others that will never show up in that environment17:03
cr3cjwatson: for bug reports, we need a lot more information such as syslog and problem-specific information, granted17:03
cjwatsonso 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 image17:03
cr3cjwatson: ok, I'm taking a note of that17:04
cjwatsonsince 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 archive17:04
cjwatsonbut I don't mind if it's both, for convenience17:04
cr3cjwatson: is there any point in testing against the archive on each computer or only on each architecture?17:05
cjwatsonit should be the default for netboot tests, if reasonable17:06
cjwatsone.g. by using a local mirror17:06
cr3cjwatson: right, but I could additionally test once for each architecture against the archive, eg remote mirror17:06
cjwatsona test on each architecture would probably be fine17:06
cjwatsonany archive mirror with a reasonably default setup would be fine17:07
cjwatsonI don't expect significantly different bugs from ca.archive.ubuntu.com and archive.ubuntu.com, for example17:07
cjwatsonassuming ca.archive.ubuntu.com basically works17:07
cjwatsonno point in loading up archive.ubuntu.com further17:07
cr3cjwatson: what about defaulting to a remote archive, archive.ubuntu.com for example, and use a squid proxy?17:07
cjwatsonsure, you could do that17:07
cr3cjwatson: ie, are there other types of significant bugs I could encounter with this proxy?17:08
cjwatsonnot so much that I'd be worried17:08
cjwatsonit would be best if it were a real proxy rather than a "transparent" proxy17:08
cjwatsonsee lifeless for lessons if you want to know why ;-)17:08
cjwatsonthe 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 difference17:09
CIA-1partman-target: cjwatson * r724 ubuntu/debian/ (8 files in 2 dirs): merge from Debian 5521:10
CIA-1partman-target: cjwatson * r725 ubuntu/debian/changelog: releasing version 55ubuntu121:13

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!