[12:05] <cjwatson> anyway, one approach to doing that with d-i would be to preseed the first few steps of the installer (locale/keyboard/network) and put the stuff you actually want to do in preseed/early_command
[12:05] <cjwatson> maybe terminate it with reboot
[12:05] <cr3> cjwatson: and that can be performed over the net somehow. the purpose for this is to be able to boot the desktop install without having to burn a cd
[12:08] <cr3> cjwatson: if I add a custom d-i, somewhere after network has been detected and drives detected, could I somehow overwrite the installation process altogether, perform those actions I need and then reboot?
[12:08] <cjwatson> that would be the procedure I described above
[12:09] <cjwatson> well, you might have to force a hardware detection run but in practice disks should have been detected by that pointt
[12:09] <cjwatson> point
[12:11] <cjwatson> ultimately I'd like to be able to do boot-iso-from-hard-disk using grub2, but note that partitioning gets very difficult when you're relying on an image on the hard disk
[12:11] <cr3> cjwatson: very cool! I can most certainly run all the shell commands I need in that early_command section, thanks!
[12:11] <cjwatson> just a warning, I am unlikely to be able to support partitioning problems you run into by this method
[12:12] <cr3> cjwatson: how so? for now, since grub doesn't seem to support iso9660, I'm simply using cp -a into a 800Mb partition at the beginning of the drive
[12:12] <cjwatson> the disk is busy and therefore it is not possible to get Linux to re-read the partition table, so new partitions you create won't be usable
[12:12] <cjwatson> (until a reboot)
[12:13] <cjwatson> this is why both d-i and ubiquity try to avoid having anything mounted on the hard disk
[12:14] <cr3> cjwatson: the new partitions will not be usable to the currently running install, but the d-i script should be able to cp -a onto a partition and then reboot from that partition, right?
[12:16] <cjwatson> the device node won't appear until Linux has re-read the partition table
[12:16] <cjwatson> so no, not unless the partition existed before you booted
[12:17] <cjwatson> or unless you're using a separate hard disk to store the CD image from the one which you're partitioning
[12:19] <cr3> I wonder what tools I could use from the installer to grab the files from an internal server without having to grab the iso locally
[12:19] <cr3> wget -r might work, but I'm not sure if there are symlinks on the installation media and if that would work with wget
[12:19] <cr3> I guess iso9660 is rather limited in feature set so wget -r could potentially work just fine
[12:20] <cr3> I'm not sure if the -r option is supported by the version of wget on busybox
[12:21] <cjwatson> it's not
[12:22] <cjwatson> honestly, this isn't sounding like a test which will very accurately reproduce a normal installation
[12:23] <cjwatson> lifeless did figure out how to NFS-boot the desktop CD; talk to him if you like
[12:23] <cr3> ultimately, the original CD will be extracted integrally onto a partition from which the system will be installed. how is that different from a normal installation?
[12:24] <cjwatson> Because the partition table on that disk will be *immutable* while a filesystem is mounted from it.
[12:24] <cjwatson> Totally different. The installation really doesn't like unrereadable partition tables.
[12:24] <cjwatson> Well, not immutable, but changes won't be reflected until you reboot.
[12:25] <cjwatson> this is why e.g. the partitioner has to disable swap before committing partitioning changes
[12:25] <cjwatson> but if the partitioner is running off a partition on the hard disk, it won't be able to do that
[12:26] <cr3> doesn't the partitionner run from memory during the installation process?
[12:27] <cjwatson> no
[12:27] <cjwatson> it's read into memory in order to execute it obviously, but you can't just go unmounting its root filesystem under it!
[12:28] <cr3> there's something I don't understand, I thoutht the root filesystem was an initramfs?
[12:28] <cjwatson> if you're booting (a version of) the desktop CD, then the ISO is mounted, a squashfs is loopback-mounted from that, and the eventual root filesystem is a unionfs of that squashfs and a tmpfs
[12:28] <cjwatson> the root filesystem is an initramfs in d-i, but that's a very different environment
[12:29] <cjwatson> doing the desktop CD with an initramfs / would have vastly increased memory requirements over the existing solution
[12:29] <cjwatson> you'd have to unpack the entire CD (effectively) into memory before you could get started
[12:30] <cr3> just in case there's misunderstanding, when I intend the desktop installation to proceed from a partition on the hard drive, I intend it to install onto the rest of the drive and not touch the partition containing the installation media
[12:30] <cjwatson> I understand that, but it still won't work.
[12:30] <cjwatson> Not unless you use a *separate* drive.
[12:30] <cjwatson> A separate partition won't do because it's still inside a partition table which is going to be locked.
[12:31] <cr3> I'm starting to understand the problem now, darn ;(
[12:32] <cr3> cjwatson, I really appreciate you have taken the time to explain this to me, it would've taken me quite a while to figure it out on my own through trial and error
[12:32] <cr3> mostly error :)
[12:34] <cjwatson> not a problem, it's not an uncommon line of thought and it's not obvious at first glance why it doesn't work
[12:34] <cr3> I'm gone. g'night and thanks a million!
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-installer
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-installer
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-installer
[02:10] <evand> cjwatson: Sorry about that, I left right after my message.  I'll close the bugs, but is there any paticular reason why I should instead of waiting and letting LP do it for me?
[02:10] <evand> Just curious
[02:11] <cjwatson> evand: because LP won't do it for you yet ...
[02:12] <cjwatson> evand: the distro side of changelog-closes-bugs is implemented, but not the LP side
[02:12] <evand> cjwatson: Really?  I could've sworn it's been closing them.  Weird.  Ok, will do.
[02:12] <cjwatson> I've closed some following your uploads - you may have interpreted that as something automatic
[02:13] <cjwatson> s/your uploads/uploads I've done on your behalf/
[02:13] <cjwatson> I tend to just paste the changelog into the bug so it's not terribly distinguishable from something automatic
[02:13] <evand> ahhh, sorry about that.  I thought that was LP working its magic.  I'll take care of that in the future.
[02:13] <evand> Being now :)
=== cr3 [n=marc@pdpc/supporter/bronze/cr3]  has joined #ubuntu-installer
=== CIA-5 [i=cia@cia.navi.cx]  has joined #ubuntu-installer
[04:51] <cjwatson> evand: # FIXME: we'll probably need to check if /etc is its own part as well.
[04:51] <cjwatson> evand: /etc has to be on the same partition as / in pretty much all Unix systems I know of - can't do much else without /etc/fstab
[04:55] <evand> hahaha, point taken.  I wrote much of that very early in the AM after much frustration with UUIDs
[04:56] <evand> I'll remove the comment
[06:08] <CIA-5> ubiquity: cjwatson * r1947 ubiquity/debian/changelog: releasing version 1.4.0
[06:18] <CIA-5> ubiquity: cjwatson * r1948 ubiquity/ (configure configure.ac): bump to 1.4.1
[06:53] <CIA-5> ubiquity: cjwatson * r1949 ubiquity/ (debian/changelog ubiquity/tz.py): * Make the timezone database a singleton, saving about 2MB of memory.
[07:09] <CIA-5> ubiquity: cjwatson * r1950 ubiquity/ (debian/changelog ubiquity/tz.py):
[07:09] <CIA-5> ubiquity: * Avoid storing temporary variables as members of the (long-lived)
[07:09] <CIA-5> ubiquity:  SystemTzInfo class.
=== pkt_ [n=knoppix@athedsl-07079.otenet.gr]  has joined #ubuntu-installer
=== stgraber [n=stgraber@ubuntu/member/stgraber]  has joined #ubuntu-installer
=== cyp_taf [n=cyp@cyplp.org]  has joined #ubuntu-installer
[11:56] <cyp_taf> hello
[11:57] <cyp_taf> I have some questions about ubiquity : is it the good chan ?
[12:27] <CIA-5> oem-config: cjwatson * r268 oem-config/ (debian/changelog oem-config): * Add missing 'import os' to oem-config.
[12:31] <CIA-5> oem-config: cjwatson * r269 oem-config/ (debian/changelog debian/control oem-config-dm):
[12:31] <CIA-5> oem-config: * Stop using xsetroot in oem-config-dm for KDE, as the KDE frontend now
[12:31] <CIA-5> oem-config:  sets its own wallpaper.
[12:37] <CIA-5> oem-config: cjwatson * r270 oem-config/ (configure configure.ac): bump to 1.11
[12:41] <CIA-5> oem-config: cjwatson * r271 oem-config/ (d-i/manifest debian/changelog): * Automatic update of included source packages: user-setup 1.8ubuntu2.
[12:43] <cjwatson> cyp_taf: yes
[12:43] <CIA-5> oem-config: cjwatson * r272 oem-config/debian/changelog: releasing version 1.11
=== pkt [n=knoppix@athedsl-146748.otenet.gr]  has joined #ubuntu-installer
=== cr3 [n=marc@pdpc/supporter/bronze/cr3]  has joined #ubuntu-installer
[02:18] <cyp_taf> cjwatson: great
[02:19] <cyp_taf> there a website or someting like for know how modify ubiquity
[02:19] <cjwatson> no
[02:19] <cyp_taf> or a page decribing the internal comportment of ubiquity ?
[02:19] <cjwatson> aside from the live CD customization howto somewhere on help.ubuntu.com/community/
[02:19] <cjwatson> there's doc/README in the source package
[02:19] <cyp_taf> ok
[02:20] <cyp_taf> I have some trouble for use lvm with partman
[02:20] <cjwatson> not supported in ubiquity yet.
[02:20] <cyp_taf> partman see lvm intruction but dont apply them
[02:21] <cjwatson> don't bother trying in ubiquity; it's still a good deal of work. use d-i instead
[02:30] <cyp_taf> in facts, my boss ask to me to adapt ubiquity for our custom debian distribution so I can't use d-i directly ...
[02:42] <cjwatson> I'm afraid LVM support just isn't there yet
[02:42] <cyp_taf> :(
[02:42] <cjwatson> it shouldn't be *too* bad to do in the new partitioner, but hooking up the pieces will still be a reasonable amount of code
[02:42] <cjwatson> certainly a lot more tractable than in the old partitioner
[02:43] <cyp_taf> ok
=== Tux-Rox [n=Tux-Rox@71.216.18.84]  has joined #ubuntu-installer
[03:22] <Tux-Rox> While installing Ubuntu in Parallels Desktop on a MacBook, it hangs as the install is finishing, while trying to insmod an IDE controller driver. It never gets to the grub install and even though I can chroot into the file system in the Virtual Machine, grub-install does not see (hd0). Any ideas or command switches that might help?
[03:28] <cjwatson> sounds like something that should be fixed in the kernel
[03:28] <cjwatson> modprobe hanging => kernel bug
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-installer
[03:33] <Tux-Rox> cjwatson: Makes sense, except that I have tried not only herd-5and the daily build from the 8th of March, but also herd-1 and 6.10 as well. They all hang at the same spot. It is really odd. I am running ubiquity with the debug switch now to see what happens.
[03:35] <Tux-Rox> I feel it might be a Parallels bug, as I once had 6.10 working in an older beta version. I just wanted to get feedback from the installer developers first in case they may have an idea.
=== stgraber [n=stgraber@ubuntu/member/stgraber]  has joined #ubuntu-installer
[03:48] <Tux-Rox> cjwatson: The exact point at which it freezes the installer is at "Loading module 'aec62xx' for 'IDE chipset support'..." Still seem like a kernel bug?
[03:52] <Tux-Rox> Last line in the debug log states: debconf (developer): --> 1 Loading module 'aec62xx' for 'IDE chipset support'...  Mar 15 07:45:28 debconf (filter): --> 1 OK
[03:53] <Tux-Rox> Last two lines it seems.
[03:55] <cr3> cjwatson: thanks again for the help yesterday, I managed to get the live cd booting over nfs this morning and only two small patches were needed: 1. initramfs-tools to support netboot= option; 2. casper to enable the network for mountroot to work over nfs.
[03:56] <cr3> the patches have already been submitted to Mithrandir and lifeless
[03:57] <cr3> now, I have yet another question: how could I hook into the live cd to run some script once the installer has reached the desktop?
[03:57] <cr3> I could probably modify the squashfs or somesuch, but I really want to have as little impact as possible on the original media
[04:08] <cjwatson> Tux-Rox: yes, still seems like a kernel bug
[04:08] <cjwatson> ubiquity --debug probably won't help a lot
[04:08] <cjwatson> Tux-Rox: I bet if you reboot and run 'sudo modprobe aec62xx' from a shell it'll hang too
[04:09] <cjwatson> cr3: tweak casper to dump an appropriate script into /etc/init.d, make it executable, run update-rc.d on it so that it runs late in the boot process?
[04:13] <Tux-Rox> cjwatson: I quit out of the installer and first tried insmod. The response was that the module was already loaded. I tried to rmmod and it said that the module was in use by [permanent] , which I expected. I then tried modprobe, and sure enough I had to eventually ctrl-c.... :-(
[04:14] <cjwatson> right, that's a sure sign that the kernel has a problem
[04:14] <Tux-Rox> I am going to try installing 6.10 once again.
[04:14] <cjwatson> mind you I'm surprised you could even ctrl-c
[04:15] <cjwatson> Tux-Rox: hang on a sec, there's a workaround at least
[04:15] <Tux-Rox> Cool! That is what I was hoping.
[04:16] <cjwatson> Tux-Rox: edit /bin/hw-detect as root on the running live CD and look for get_ide_chipset_info
[04:16] <cjwatson> Tux-Rox: should be a line that looks like: if [ "$baseidemod" != hpt366 ] ; then
[04:16] <cjwatson> Tux-Rox: change that to: if [ "$baseidemod" != hpt366 ]  && [ "$baseidemod" != aec62xx ] ; then
[04:17] <cjwatson> Tux-Rox: you may have to repeat if other modules hang, and probably reboot after each failure, so I expect it'll be a slow process
[04:17] <cjwatson> Tux-Rox: or you could gamble and search for the second instance of get_ide_chipset_info in that file (in the get_manual_hw_info function) and just comment it out by putting a # at the front of the line)
[04:18] <Tux-Rox> cjwatson:   :-)   Thanks! I'll give it a go.
[04:18] <cjwatson> thinking about it your disk is probably detected already anyway so commenting that out should be harmless
[04:18] <cjwatson> maybe I should just kill off that chunk of code
[04:21] <Tux-Rox> It is assumed then that the live-cd puts the /etc scripts in ramdisk?
[04:31] <cjwatson> Tux-Rox: I don't understand the question?
[04:32] <Tux-Rox> Nevermind, I just typed something random that popped into my head. A bit of a brain fart is all... :-)
[04:33] <cjwatson> the whole / on the live session is a unionfs of the squashfs on the CD and a tmpfs
[04:33] <cjwatson> so you can write to all of it
[04:34] <Tux-Rox> I figured as much, it just took a second after typing the above cryptic question to realize it... :-)
[04:48] <cr3> cjwatson: I discovered that if I just dropped a squashfs in the casper directory, it could automatically be unionfs mounted for me. so, by not having to modify casper scripts, I wouldn't have to rebuild the initrd.gz
[04:49] <cr3> what would be nice is being able to nfs export the union of the live cd iso image and a directory containing my squashfs file, but nfs is broken in regards to unionfs :(
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-installer
=== avoine [n=avoine@modemcable036.0-70-69.static.videotron.ca]  has joined #ubuntu-installer
[05:29] <CIA-5> ubiquity: cjwatson * r1951 ubiquity/ubiquity/tz.py: minor neatness
[05:53] <CIA-5> ubiquity: cjwatson * r1952 ubiquity/ (debian/changelog scripts/install.py): * Fix broken call to kboot-installer.
[06:03] <CIA-5> ubiquity: cjwatson * r1953 ubiquity/debian/changelog: releasing version 1.4.1
[06:39] <cr3> aha! when exporting a filesystem over nfs, it assumes that it is located on a block device. otherwise, you must specify the fsid in the exports file. as simple as that!
=== joejaxx [i=joejaxx@ubuntu/member/joejaxx]  has joined #ubuntu-installer
[06:56] <thom> cjwatson: do you happen to know what happens if i call pkgsel multiple times?
[06:57] <thom> um, pkgsel/include
[06:57] <thom> in preseed installs
[07:03] <cjwatson> you mean specify that preseed more than once?
[07:03] <cjwatson> preseeding isn't procedural, it's declarative. The last one will win
[07:03] <thom> damnation :/
[07:03] <cjwatson> why not just comma-separate multiple package names?
[07:04] <thom> i have some common packages and some class specific ones
[07:04] <cjwatson> you'll need to generate the preseed file in a way that can add to a given line, then
[07:04] <cjwatson> or else perhaps use preseed/late_command if you just need to blat in a load of shell
[07:05] <thom> yeah, i'm using apt-install in late_command currently, was hoping for a cleaner way
[07:05] <thom> guess i'll either stay with that or just have a bunch of more or less duplicated pkgsel/includes in the class configs
[07:10] <cjwatson> sounds like it's worth having a smarter generator :)
[07:10] <thom> s/smarter// ;-)
[07:11] <cjwatson> heh
[07:11] <thom> d-i preseed/include_command string case $(debconf-get netcfg/get_hostname) in *-foo) echo foo.cfg ;; etc :-)
[07:13] <cjwatson> ah yes
=== mpt [n=mpt@121-72-133-166.dsl.telstraclear.net]  has joined #ubuntu-installer
[11:30] <joejaxx> cjwatson: is deboostrap-udeb downloaded along with the rest of the udebs that are pulled when you compile the d-i?
[11:31] <cjwatson> joejaxx: it's downloaded at run-time by d-i, not when you build the initrd (unless you're building monolithic)
[11:35] <joejaxx> hmm
[11:35] <joejaxx> because the debootstrap extract script is looking for it
[11:35] <cjwatson> could you give more detail?
[11:35] <joejaxx> on the Package.gz
[11:35] <joejaxx> in*
[11:36] <cjwatson> what debootstrap extract script?
[11:36] <joejaxx> cjwatson: the extract-debootstrap script
[11:36] <cjwatson> sure, it needs to be on your mirror
[11:36] <cjwatson> it doesn't need to be in the d-i initrd
[11:37] <cjwatson> extract-debootstrap is just there because debian-cd needs it later on for internal checking purposes
[11:38] <cjwatson> (which actually isn't all *that* useful with debootstrap 0.3, but anyway)
[11:38] <joejaxx> yeah because debian-cd is not putting the udebs on the cd archive
[11:39] <joejaxx> or atleast when it goes to do scanpackages during the build process it comes up with
[11:39] <joejaxx>  dists/feisty/main/binary-i386/: New 877kB 611 files 237MB 4m22s
[11:39] <joejaxx>  dists/feisty/main/debian-installer/binary-i386/: New 20B 0 files 0B 0s
[11:47] <cjwatson> check the stuff in tasks/blah/installer in the scratch directory
[11:47] <cjwatson> see if it actually lists any udebs
[11:48] <cjwatson> if not, one possibility might be that the mirror you're germinating from doesn't have a proper udeb mirror, or it could be something else weirder
[11:48] <cjwatson> e.g. if you're germinating off an incompletely debmirrored site, that would do it
[11:49] <joejaxx> oh ok
=== lifeless [n=robertc@ppp245-86.static.internode.on.net]  has joined #ubuntu-installer