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