[12:30] <CIA-18> ubiquity: evand * r2226 ubiquity/ (configure configure.ac): bump to 1.5.15
[12:31] <evand> bzr shelve is awesome!
[12:37] <xivulon> what's that?
[12:37] <evand> http://bazaar-vcs.org/BzrShelveExample
[12:50] <xivulon> hmm I see
[03:04] <evand> cjwatson: As it stands in code that's about to be checked in, it's not possible to have a back button in automatic mode as any page we move over will answer all its questions, so there's nothing to go back to.
[03:04] <evand> Is this acceptable, or would you prefer I made the code that checks for the seen flag backup aware?
[04:28] <CIA-18> ubiquity: evand * r2227 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): * Fixed backup in the UI wrt the new page turning code.
[09:51] <cjwatson> evand: I think that's OK by me
[09:51] <cjwatson> bzr shelve does indeed rock
[12:09] <tepsipakki> hi, tried to netboot gutsy, but grub-installer failed due to missing fdisk/sfdisk
[12:10] <tepsipakki> although they are there
[12:10] <cjwatson> I had another report of that ...
[12:11] <tepsipakki> oh
[12:11] <cjwatson> it's weird
[12:12] <tepsipakki> yep, bug 138040
[12:13] <tepsipakki> but should fdisk/sfdisk be present on the busybox side?
[12:13] <tepsipakki> they are in /target
[12:17] <cjwatson> yes, fdisk-udeb should provide them
[12:17] <cjwatson> I'm just syncing the code over from the old laptop
[12:18] <cjwatson> oh
[12:19] <cjwatson> lamont broke fdisk-udeb
[12:19] <tepsipakki> heh
[12:26] <cjwatson> tepsipakki: can you look in /var/lib/dpkg/status for me in the running installer, and check if fdisk-udeb is installed?
[12:31] <tepsipakki> yep, it is
[12:31] <cjwatson> ok, good
[12:31] <cjwatson> I reassigned the bug to util-linux
[12:31] <cjwatson> and prodded lamont about it on IRC
[12:31] <tepsipakki> Installed-Size: 16
[12:32] <cjwatson> it has /usr and /usr/sbin, nothing else
[12:32] <tepsipakki> right..
[01:08] <pj_og> Hi! I installed the ubuntu-server, but the base system doesn't boot. I have no idea why. I can boot memtest86+, but trying one of the kernels results only in a "reset". What now? The installation itself went absolutely smooth no error or so. But then rebooting doesn't work. I even have no idea how to debug such a thing since there are no messages. Any ideas anybody?
[01:12] <pj_og> or if this is not the correct channel for this question, where would it be?
[01:13] <cjwatson> #ubuntu-kernel is probably better if the server kernel isn't managing to boot
[01:13] <cjwatson> sounds like the generic kernel used in the installer is working fine, but the server kernel used after boot isn't
[01:14] <cjwatson> (normally the two kernels are the same, but in the server install they aren't necessarily)
[01:14] <pj_og> ok. thank you.
[01:31] <cjwatson> xivulon: if you already had a wubi entry in the grub4dos configuration, running wubi again adds another one
[01:32] <cjwatson> xivulon: maybe it should make sure that there's just one
[01:34] <xivulon> cjwatson, I noticed that yesterday night, but it was too late for me to fix that. Also the menu name should be changed to "Ubuntu Linux" in the vista case.
[01:36] <xivulon> If you complete the installation (disk images are created), that is not an issue (since you cannot just reinstall, you have to uninstall first)
[01:38] <xivulon> Forcing to uninstall anytime is the quickest way to fix that
[01:41] <cjwatson> yeah, I actually just removed the ubuntu folder :-)
[01:41] <cjwatson> (wasn't sure if uninstall would work)
[01:41] <xivulon> I cannot upload code, but it should be a one line fix: wubi/installer/installer.nsh -> remove the {if} block around InstallCompleted
[01:41] <cjwatson> I found another bug in the automatic-ubiquity handling, which I'll fix after lunchh
[01:41] <cjwatson> lunch
[01:41] <cjwatson> unfortunately unionfs is too broken in gutsy at the moment for me to get any further
[01:45] <xivulon>  ${IF} $InstallCompleted == true
[01:45] <xivulon> cjwatson, simpler fix for uninstallation: in pages/main.nsh remove the above if statement
[01:45] <xivulon> leave the stuff in between
[01:47] <xivulon> That will force you to uninstall if a previous installation is detected even if it wasn't completed.
[01:48] <pj_og> Hi, I'm back. I did not resolve yet my boot problem, but now I think there might be an installer problem.
[01:49] <pj_og> Maybe sbd is interested?
[01:49] <cjwatson> pj_og: sure, but I'm about to go to lunch, so mention it and I'll get to it after I get back
[01:49] <CIA-18> ubiquity: cjwatson@chiark.greenend.org.uk * rcjwatson@chiark.greenend.org.uk-20070912114801-ec22h8ue8sy9tpdh ubiquity/debian/ (changelog rules ubiquity.postinst): * Start ubiquity init script at 29; don't bother stopping it.
[01:49] <pj_og> ok. I managed to boot the generic kernel with grub, I just copied it over from the install CD
[01:50] <cjwatson> urgh bogus bzr configuration
[01:50] <pj_og> it kind of worked, but then there was a root disk problem or so, probably since the initrd didn't match really
[01:50] <pj_og> so I think there might be some check which the installer might want to do to ensure that the installed kernel actually will work.
[01:51] <cjwatson> it already tries. be more specific
[01:51] <pj_og> sbd on kernel said that the server kernel probably assumes i686. I have a pentium MMX. I'm not sure, but it might be not enough.
[01:51] <cjwatson> oh, that's fixed in gutsy
[01:52] <cjwatson> it requires 686 for the server kernel now
[01:52] <pj_og> of course, it could be another difference between the kernels. but with generic at least I get some messages, it starts to run.
[01:52] <cjwatson> base-installer's checks were indeed incomplete for server in <=feisty
[01:53] <pj_og> I'm using the installer CD for 7.04 server
[01:53] <CIA-18> ubiquity: cjwatson * r2228 ubiquity/debian/ (changelog rules ubiquity.postinst): * Start ubiquity init script at 29; don't bother stopping it.
[01:53] <pj_og> I tried to locate the technical requirements for the server from the ubuntu.com webpage but didn't find it
[01:53] <cjwatson> CIA> that's better
[01:54] <cjwatson> right, no need to file a bug though since 7.10 will get that check right
[01:54] <pj_og> ok. fine. and for my problem, I think doing an install with the normal CD might work?
[01:54] <cjwatson> yep
[01:54] <pj_og> or rather the alternate CD?
[01:54] <cjwatson> it doesn't have the server kernel on it so won't try to se it
[01:54] <cjwatson> use
[01:54] <cjwatson> yes
[01:55] <pj_og> ok. thank you!
[01:55] <pj_og> good lunch :-)
[02:34] <xivulon> cjwatson, I think that the double menu entry is due to the name change of Wubi, since the registry key also changed and the old one went undetected
[02:36] <xivulon> You probably had the previous version (called Wubi installed) and then run the new version (called Ubuntu)
[02:37] <xivulon> In normal circumstances if you run the installer multiple times you should only have a single menu entry
[02:37] <xivulon> I think that the double menu entry is due to the name change of Wubi, since the registry key also changed and the old one went undetected
[02:39] <xivulon> The current behaviour is that if Wubi was installed but no disks where created, the installer is re-run without uninstaller first, so that you can for instance resume an interrupted download
[02:40] <xivulon> If virtual disks have been created, you have to uninstall first before you can run the installer again
[02:41] <xivulon> I think it is fine as it is
[02:59] <xivulon> On second thought, it might be a good idea to always run uninstall on re-install and (optionally) backup partially downloaded files so that users can recover interrupted downloads
[03:49] <cjwatson> xivulon: no, they were both called "Wubi Ubuntu"
[03:49] <cjwatson> identical names visible in the menu
[03:52] <xivulon> cjwatson, the "Wubi Ubuntu" is harcoded in wubibcd.exe (which is something I need to change), I am talking about the executable itself
[03:52] <cjwatson> ah, didn't check that
[03:52] <xivulon> Wubi-7.10-XYZ.exe vs Ubuntu-7.10-alpha.exe.
[03:52] <cjwatson> right
[03:52] <cjwatson> I'll check next time I reboot to Windows, thanks
[03:52] <xivulon> The first one uses "Wubi" as registry key, the second one uses "Ubuntu"
[03:54] <xivulon> The key should be under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\
[03:57] <xivulon> To undo the menu entry in vista manually, you have to get the boot menu ID stored in the registry, then run
[03:57] <xivulon> bcedit.exe /delete $ID /f
[04:05] <cjwatson> ok, thanks
[08:41] <pj_og> After my n-th installation i now get a GRUB Error 18. What now?
[09:39] <superm1_> cjwatson, evand, the ubiquity-frontend-mythbuntu text, is it available in rosetta already, or does someone have to manually push it up?
[09:40] <evand> my understanding is that it has to be manually updated.
[09:41] <superm1_> well my files from ubiquity-frontend-mythbuntu.templates merged into the ubiquity source package's po files i believe
[09:41] <superm1_> so it will probably happen whenever ubiquity itself is added up there
[09:41] <evand> indeed
[09:42] <superm1_> well i'll double check make sure that all of my stuff is accurate than in the english variant
[10:02] <pj_og> My problems are solved. I have a working system now - after something like 10 installations with different methods and a lot of guesswork. :-/
[10:03] <evand> yikes, glad it's working for you now
[10:18] <pj_og> Well, yes, after 2 days of installation. First it did install a kernel which doesn't work for the processor used for the installation, then it didn't tell about the BIOS HD limit (maybe it simply can't), but then when I tried to install with different partitions (to get the boot kernel to the beginning of the HD), it fucked up some installations (probably due to too small a partition or so,...
[10:18] <pj_og> ...or for some other reasons). Well, it's fine now, anyway.
[10:21] <pj_og> I'm not exactly happy now since it ate so much time, but on the other hand, I think I can move on now to get the content on the machine and put it back online. Ouff.
[10:26] <pj_og> Other than these temporary problems, I'm really satisfied with (k)ubuntu. So thanks to any developers reading here, all those who make this project possible.
[10:57] <bdmurray> evand: Is swap always formatted?
[10:57] <evand> bdmurray: I believe so
[10:57] <evand> I seem to recall it being dangerous not to
[10:58] <evand> cjwatson: can you confirm?
[10:58] <bdmurray> The prepare partitions screen does show the "Format?" checkbox as being checked though
[10:58] <evand> whenever you return to IRC, that is
[10:59] <evand> bdmurray: I don't follow.  Are you saying that contradicts swap always being formatted?
[10:59] <bdmurray> evand: I am saying that I did not check Format and it still tells me it is going to be formatted.
[11:00] <evand> oh, hrm.  File a bug, please.
[11:00] <evand> at any rate the UI should be consistent
[11:01] <bdmurray> Yeah.  The fact that I am using Tribe 5 isn't relevant?
[11:02] <evand> It shouldn't be.  Partman hasn't been changed in the frontend following the tribe 5 release
[11:06] <bdmurray> evand: it looks like bug 83166 - do you agree?
[11:13] <evand> ah, indeed it does
[11:20] <bdmurray> cool, as a stop gap couldn't the format box always be checked for swap?
[11:22] <evand> bdmurray: indeed, though I'd like to discuss the options with cjwatson before resorting to that
[11:23] <bdmurray> evand: okay, I'll leave it in your hands. :)