[00:01] <cjwatson> the thing is that the eeebuntu people didn't particularly talk to us about their jaunty fork
[00:02] <cjwatson> so it's unlikely to upgrade very cleanly
[00:02] <cjwatson> if you do an install as I suggested (mount /home, make sure the format checkbox is cleared, but format /) then it'll just overwrite all the system stuff
[00:02] <cjwatson> i.e. fresh install but preserving user data in /home
[00:03] <cjwatson> won't preserve /etc or anything else, of course
[00:03] <cjwatson> when I did it, I took a full system backup first
[00:03] <cjwatson> that way it was cheap to try the install and I knew I could roll the entire thing back if I needed to
[00:06] <MHJessen> It's full system backup that would be the problem. I don't have access to external storage due to homelessness.
[00:07] <MHJessen> I think I could probably get away with using Synaptics to create a history script that would reinstall the packages I have in play but it's what the versions would be that I'm not sure about.
[00:08] <MHJessen> Since the Synaptic solution would be from a Jaunty system what would happen when I tried to bulk install all the packages on a 10.10 system?
[00:10] <cjwatson> the eeebuntu packages just wouldn't be available any more
[00:10] <cjwatson> I don't know whether synaptic records package+version or just package name
[00:10] <cjwatson> if it's the latter then you're ok, it'll do the best it can
[00:10] <cjwatson> if it's the former, good question, no idea
[00:11] <cjwatson> have a look at the file it generates
[00:16] <MHJessen> I think that's my next step. I've been really happy with eeebuntu, but the writing is on the wall that I need to do something because everything is taking longer and longer to trickle back to Jaunty. Thanks for the info! :)
[00:16] <cjwatson> jaunty's end-of-life now
[00:16] <cjwatson> I doubt anything more will trickle back to it ever
[00:18] <MHJessen> That's too bad but I understand the need to keep moving forward. I really noticed it with Firefox. I've been waiting a couple weeks now for 3.6.12 to be available and I'm not sure it ever will. At any rate I have to run. Thanks again!
[00:19] <cjwatson> yeah, I think you can assume it won't now, sorry
[00:20] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-announce/2010-September/000137.html
[00:20] <cjwatson> "Ubuntu 9.04 reaches end-of-life on October 23, 2010"
[00:25] <MHJessen> Ouch! Well that does it. Thanks! Bye!
[08:47] <twb> 10.04 d-i defaults to gpt for brand new 2TB disks
[08:47] <twb> This is only going to run 10.04 -- is there any reason I shouldn't continue using msdos partition type?
[10:44] <cjwatson> twb: I suspect our comparison is actually against decimal 2TB, which is slightly less than 2TiB
[10:44] <cjwatson> which is the actual technical limit
[10:45] <cjwatson> twb: you can use either, if it's actually no more than 2TiB.  gpt's technically a superior format, but you may have other reasons.
[10:45] <twb> technically superior, but more confusing/complicated
[10:46] <twb> AFAICT (I've been reading up on it), the practical benefits are minimal
[10:48] <cjwatson> certainly, for anything over 2TiB, you must use gpt if you want to be able to address the whole disk
[10:48] <cjwatson> gpt is actually simpler
[10:48] <cjwatson> if you disregard the protective mbr bit, which is basically for compatibility
[10:48] <cjwatson> it doesn't have the whole primary vs. logical partition nonsense, which vastly complicates things
[10:48] <cjwatson> it's just a simple linear array of partitions
[10:48] <twb> Grante; but I'm using LVM so I only have two partitions per disk
[10:49] <cjwatson> so it probably doesn't matter to you
[10:49] <twb> If it meant I got "optimal" block alignment for free from partman, that might be a practical win
[10:49] <cjwatson> you get that anyway
[10:50] <cjwatson> oh, gpt has more robust boot loader storage methods, that's the other major difference
[10:50] <cjwatson> we don't have to use the boot track hack any more
[10:50] <twb> For me, the bootloader lives in the partition itself :-)
[10:51] <twb> I think the other thing that confuses me is that all GPT documentation assumes, to a greater or lesser extent, that I'm running either an Itanium or a macbook
[11:15] <cjwatson> mm, just historical - that'll stop as the world moves to >2TiB drives
[11:25] <twb> Nod
[13:26]  * ev discovers bzr lp-propose-merge
[13:32] <soren> ooooh!
[13:33] <soren> ev: Awesome. Thanks for the hint!
[15:21] <superm1> charlie-tca, you realize you closed your own bug with bug 646027 and the triaging scripts?
[15:21] <ubot2> Launchpad bug 646027 in ubiquity (Ubuntu) "Keyboard can not be changed in Ubiquity (affects: 1) (heat: 6)" [Undecided,Invalid] https://launchpad.net/bugs/646027
[15:28] <charlie-tca> closed another bug?
[15:29] <charlie-tca> oh, no
[15:29] <charlie-tca> I did not realize I was the reporter. The bug is invalid, though, now
[15:29] <superm1> i just thought it was a little funny :)
[15:30] <charlie-tca> It is, when I see the reporter name
[15:30] <twb> I once solved a bug by googling, and finding a pastebin I had pasted six years prior
[15:30] <charlie-tca> I don't always look at the name, but I did try to reproduce it
[16:44] <dlyneswork> Is there a pkgsel/exclude verb?
[16:44] <dlyneswork> Or something that would achieve the same end?
[16:45] <dlyneswork> I want to be able to tell 10.04 NOT to install nouveau (system hangs at startup after about 5 lines of kernel output...last four lines are nouveau output)
[16:45] <twb> https://help.ubuntu.com/10.04/installation-guide/amd64/appendix-preseed.html covers options you can pass
[16:46] <twb> I can't see anything relevant
[16:46] <twb> Re nouveau specifically, post-install I think you can blacklist the kernel module
[16:48] <dlyneswork> twb, but i can't blacklist it if i can't boot up
[16:49] <dlyneswork> twb, to do that, i'd need to rip the hard drive out of every single machine after I've installed, throw it onto another machine as a secondary drive, modify the config files, disconnect, and reinstall into the original machine
[16:50] <cjwatson> you can blacklist on the kernel command line
[16:50] <dlyneswork> twb, is there a reason it insists on installing a video driver, even though i haven't told it to install x11?
[16:50] <twb> There's a boot-time option like "video=nouveau:disable" or "video=vga16fb" or something
[16:50] <dlyneswork> Oh, ok
[16:50] <cjwatson> not that I know the syntax off the top of my head
[16:50] <cjwatson> the video driver is part of the kernel
[16:50] <dlyneswork> It's in /target/....??
[16:51] <twb> dlyneswork: loading video drivers is opt-out in recent kernels so the naff splash stuff can run
[16:51] <cjwatson> video mode setting is moving from X to the kernel because it's loads more robust there in general
[16:51] <dlyneswork> Ah...I'm still accustomed to the good old days when nobody used framebuffer drivers in the kernel bootup :)
[16:51] <cjwatson> twb: nonsense
[16:51] <cjwatson> frankly
[16:51] <cjwatson> KMS is far wider than just plymouth, although I realise it's fashionable to blame plymouth for stuff
[16:52] <twb> cjwatson: so it's also there to make text unreadably small? :-P
[16:52] <dlyneswork> kms?
[16:52] <cjwatson> kernel mode setting
[16:52] <dlyneswork> ah
[16:52] <cjwatson> you can boot with 'nomodeset' to disable it
[16:52] <twb> That's the one I was trying to remember
[16:52] <dlyneswork> cjwatson, but in 10.04, where is it that it gets modified?  Is it in the same file and the same way as 9.04?
[16:52] <twb> FWIW, Debian has KMS, but it doesn't compile it into the kernel
[16:53] <dlyneswork> cjwatson, with 9.1 ubuntu switched to grub2, didn't it?
[16:53] <cjwatson> dlyneswork: I don't recall the state of 9.04, but it probably didn't have KMS
[16:53] <cjwatson> dlyneswork: correct
[16:54] <dlyneswork> cjwatson, so is there any documentation as to which file I need to modify and where?  I don't have a working 10.04 install to look at to know where to fix it in my preseed script
[16:54] <twb> Oops, I just added nomodeset to my new LXC server, and os-prober found lucid on all the containers and added them to grub.cfg
[16:54] <cjwatson> dlyneswork: just add nomodeset to the end of the kernel command line when installing; or for already installed systems you can try it out by editing the kernel parameters interactively at boot time
[16:55] <cjwatson> dlyneswork: to make it permanent, add it to GRUB_CMDLINE_LINUX in /etc/default/grub and run update-grub
[16:55] <cjwatson> twb: it's not built-in in Ubuntu either, it's modular
[16:55] <dlyneswork> cjwatson, ah, ok...so I'll need to hit left shift to do it, then...ok...thought I had to edit the grub file after it was installed /target/boot/grub/menu.lst on grub1
[16:55] <ev> hm, since when does -l need to come after -o in gcc?
[16:56] <cjwatson> ev: technically it always ought to have done, but the linker was made stricter on Monday
[16:56] <cjwatson> as part of other changes
[16:56] <ev> ah, fair enough
[16:56] <cjwatson> actually I think it only needs to come after the object that uses symbols from the linked libraries, not necessarily after -o
[16:56] <ev> right
[16:57] <dlyneswork> cjwatson, ok...so /target/etc/default/grub, and then run update-grub against /dev/sda
[16:57] <ev> cjwatson: thanks for the clarification
[16:57] <dlyneswork> cjwatson, thanks
[16:57] <cjwatson> dlyneswork: um, why are you fiddling with /target for this?
[16:57] <dlyneswork> cjwatson, because it's borked after the pxe boot install
[16:58] <cjwatson> dlyneswork: why not just boot it interactively with nomodeset, and then you can edit it directly when it's running?
[16:58] <dlyneswork> cjwatson, so i need to fix it as part of my preseed/late_command
[16:58] <cjwatson> ah, no, better solution for that
[16:58] <dlyneswork> cjwatson, because I want to be able to have it fixed without trying to explain to some windows user how to fix it
[16:59] <dlyneswork> cjwatson, it's probably going to be some clueless windows user installing these systems...I'm just setting up the automated installer
[16:59] <cjwatson> put nomodeset on the end of the append line in your pxelinux configuration
[16:59] <cjwatson> make sure there's a "--" parameter somewhere before it
[16:59] <dlyneswork> cjwatson, not needed there....the pxeboot is working just fine
[16:59] <dlyneswork> cjwatson, it's the post install that's not
[16:59] <cjwatson> everything after "--" (with a few specific exceptions) gets copied into the installed bootloader configuration
[16:59] <cjwatson> trust me
[16:59] <cjwatson> this is much simpler and more robust than using preseed/late_command
[16:59] <twb> dlyneswork: if you put it in the pxelinux APPEND *after* a --, it'll be added automatically post-install
[17:00] <cjwatson> so the append line would look like "blah blah blah -- nomodeset"
[17:00] <dlyneswork> cjwatson, oh...so whatever I add into the kernel parameters for the pxelinux.cfg/default file gets applied to the /etc/default/grub in the install?
[17:00] <dlyneswork> twb, ah...cool...thanks both of you
[17:00] <cjwatson> anything after "--", yes
[17:01] <CIA-4> migration-assistant: evand * r105 migration-assistant/ (Makefile debian/changelog): Fix linking to libxml2.
[17:01] <dlyneswork> erm...sorry... i386/boot-screens/text.cfg right?
[17:02] <cjwatson> whatever you're using :)
[17:02] <dlyneswork> And there I would move my vga-normal from before the '--' to after the '--'?  Or put it in both locations?
[17:02] <dlyneswork> erm vga=normal, i mean
[17:03] <twb> IIRC vga is magical and is always ignored
[17:03] <twb> In terms of propagation to post-boot
[17:03] <dlyneswork> ah, ok
[17:03] <dlyneswork> so just -- nomodeset then, instead
[17:03] <cjwatson> twb is correct
[17:04] <cjwatson> vga= breaks suspend/resume so we filtered it out
[17:04] <dlyneswork> ah
[17:05] <dlyneswork> Trying with the nomodeset now in text.cfg, then
[17:05] <dlyneswork> Will that get rid of plymouthd on startup, as well?
[17:06] <twb> dlyneswork: fyi, here's my netboot script: http://paste.debian.net/100222/
[17:06] <ev> you cannot get rid of plymouth
[17:06] <cjwatson> just remove 'splash' for that
[17:06] <cjwatson> plymouthd will still run, but not the splash screen
[17:06] <CIA-4> migration-assistant: evand * r106 migration-assistant/debian/changelog: releasing version 0.6.8
[17:06] <twb> I noticed that if you hit ESC twice, plymouth will put two copies of the console output one after the other on the screen
[17:06] <cjwatson> (which is what most people who ask this question care about)
[17:06] <cjwatson> twb: I think that's fixed upstream
[17:07] <dlyneswork> twb, and what exactly does that do?
[17:07] <dlyneswork> twb, your script, that is
[17:07] <cjwatson> I noticed something that looks very plausible for that in the merge diff
[17:07] <twb> dlyneswork: it creates /srv/tftp
[17:07] <dlyneswork> twb, you mean a mirror?
[17:07] <twb> dlyneswork: no, for PXE booting.
[17:07] <dlyneswork> twb, or you mean the tftp pxeboot stager?
[17:07] <dlyneswork> twb, ah..yeah...I've got all that set up already
[17:07] <dlyneswork> twb, got it set up for 9.04, 10.04 and 10.1
[17:08] <dlyneswork> twb, for multiple specialized configurations
[17:08] <twb> dlyneswork: I was just mentioning it in case you wanted to compare implementations
[17:09] <dlyneswork> twb, ah....yeah...I used the ubuntu pxeboot howto as a template, but have performed fairly extensive modifications to it, because i need a 2nd stage installer to do the drbl installation
[17:09] <dlyneswork> twb, basically pxeboot install the masternode....masternode is a pxeboot server for multiple slave nodes that mount all their files over nfs
[17:10] <dlyneswork> twb, plus i have another installer for a copy machine and another one for development machines
[17:10] <dlyneswork> twb, drbl's a project from taiwan (drbl.sf.net)
[17:11] <twb> Nod.
[17:11] <twb> Sounds similar to my project (prisonpc.com)
[17:20] <davmor2> cjwatson: By the way ref the install issues I don't get them if I upgrade only if I install fresh from natty iso
[17:20] <dlyneswork> twb, yeah...not so sure drbl has security well in mind :o
[17:20] <cjwatson> davmor2: I'm trying a kvm install now
[17:21] <dlyneswork> twb, but then again, prisonpc looks like it's geared towards management of a windows network?
[17:22] <davmor2> cjwatson: I might get a bit of quieter time latter if I do I'll do a fresh install and open up ssh for you if that will help, just let me know :)
[17:22] <twb> dlyneswork: our primary target is prisons currently running Windows
[17:22] <twb> They don't run Windows once we're done with them :-)
[17:22] <dlyneswork> twb, yeah...and prisoners would never ever try to pirate software or visit porn sites now, would they?
[17:22] <cjwatson> ev: should that m-a upload fix the partman vs. m-a crash somebody reported the other day?
[17:22] <dlyneswork> twb, or buy drugs on the internet? :p
[17:23] <cjwatson> ev: I just saw that in a no-frills kvm install
[17:23] <cjwatson> also, no /var/log/syslog.  wtf
[17:23] <ev> cjwatson: doubtful.  If you're referring to davmor2's bug, that's the result of parted_server shutting down before m-a comes on the scene.
[17:23] <twb> dlyneswork: shrug.
[17:24]  * cjwatson thinks blackz dropped /etc/rsyslog.d/50-default.conf
[17:24] <cjwatson> ev: confused as to what would have changed to cause that
[17:24] <davmor2> ev: no I blanked the HDD and did a fresh install that didn't trigger the m-a issue I just had plymouth with the Ubuntu logo and the dot constantly cycling
[17:25] <ev> cjwatson: indeed, I'm perplexed as well.  I'll investigate it after I get through this partman-auto work.
[17:25]  * cjwatson concludes that to a first approximation nobody is using natty yet
[17:25] <cjwatson> since there's no bug about rsyslog being configured entirely wrongly
[17:26] <ev> cjwatson:  http://paste.ubuntu.com/534328/ - would you mind committing some variant of that to Debian?
[17:29] <cjwatson> are you sure that's needed?  that's weird
[17:29] <cjwatson> I wouldn't have expected the position of -o to be relevant (as I said above)
[17:29] <ev> it appears to be
[17:29] <ev> perhaps I'm glossing over a deeper bug
[17:31] <cjwatson> partman-base 146ubuntu1 failed to build, certainly, but the unreleased change immediately above yours fixed it
[17:31] <cjwatson> it was only necessary to move $(LIBS) after the .c
[17:31] <cjwatson> (and I already committed that change to Debian)
[17:31] <cjwatson> the current unreleased version builds for me in a natty chroot
[17:32] <cjwatson> it's my oversight that I forgot to upload that
[17:32] <ev> fair enough
[17:32] <cjwatson> sorry about that
[17:32] <ev> no worries at all
[17:32] <CIA-4> partman-base: cjwatson * r222 ubuntu/debian/changelog: releasing version 146ubuntu2
[17:33] <ev> I'm just trying to plough through so I can get a new ubiquity to work with for the other end of this new partman-auto option
[18:14] <dlyneswork> be465n9-r
[18:14] <dlyneswork> oops
[18:15] <dlyneswork> cjwatson, thanks...that method worked perfectly, and plymouth didn't get in the way that way, either
[18:16] <cjwatson> cool
[18:17] <dlyneswork> Still need to fine tune it a bit, but it's working in a much more usable manner, now
[20:08] <charlie-tca> Is there a way to abort the install now? Installation from live desktop on hardware running 45 minutes
[20:09] <charlie-tca> appears to be hung, no dialog in the "ready when you are..." box to indicate, but has not progressed the marker for 30 minutes
[20:11] <charlie-tca> natty, by the way
[20:11] <cjwatson> yes, I saw that too
[20:11] <cjwatson> I killed the vm until I had a chance to investigate properly :)
[20:12] <charlie-tca> So, a hardware shutdown? Is there a way to pull the logs for you?
[20:12] <cjwatson> it was hard to investigate anything because of rsyslog being broken, so I fixed that and decided to wait for the next build
[20:12] <cjwatson> no, there won't be useful logs because rsyslog was busted
[20:12] <charlie-tca> Okay, I will try again tomorrow
[20:12] <cjwatson> hence my perhaps excessively sarcastic comments on #-devel earlier ...
[20:13] <cjwatson> you can certainly do c-a-f1 and poke around on a console