[03:28] <veebers> Hi all, I'm experiencing issues trying to netboot the raring desktop iso (from here: http://cdimage.ubuntu.com/daily-live/current/) I'm hoping you can point me in the right direction
[03:29] <veebers> the error I'm seeing is here: http://pastebin.ubuntu.com/1373998/
[03:29] <veebers> effectively mount complaining protocol not supported when trying to nfsmount
[03:30] <stgraber> I remember seeing that the nfs kernel module was missing in today's builds and that was fixed with the last upload, so the images should start working again in a day or two
[03:31] <veebers> excellent, thanks for the info stgraber :)
[04:01] <infinity> stgraber: That was only for d-i udebs.  No one's yet confirmed or denied if I need to make changes to initramfs-tools or casper or some such to support the new nfs kernel module.
[04:03] <infinity> (But if so, I'll need to backport that to precise too, for the lts kernels that will eventually land there)
[04:03] <infinity> Fun, fun.
[04:04] <stgraber> infinity: hmm, the pastebin above suggests the nfs is somehow missing from the live initramfs, though casper error messages are some of the blurriest you can get, so until you get an actual shell in the initramfs, it's hard to know what's the actual problem :)
[04:04] <infinity> stgraber: Right, which would mean that today's kernel fix (adding nfsv3 to the nfs-modules udeb) won't help here, since this is casper, not d-i.
[04:05] <stgraber> indeed
[04:05] <infinity> Maybe I should do my initramfs-tools merge tonight, and then look at this.
[04:05] <infinity> I don't really want to rev initramfs-tools in raring until post-merge, just to avoid SRU version headaches. :P
[04:05] <stgraber> I'm doing a quick test boot here to check what's in the initramfs
[04:06] <stgraber> hmm, I have nfs.ko here
[04:06] <infinity> My guess is that everywhere initramfs-tools (and hooks from other packages) tries to copy_module nfs, it now needs nfs and nfsv3.
[04:06] <stgraber> now I don't have any nfs server to try it against, but I'm getting a fairly reasonable error message (rpc related) from mount
[04:06] <infinity> stgraber: Yeah, but not v3, right?
[04:07] <stgraber> ah, that's what changed! yeah, I only have nfs.ko in the initramfs
[04:08] <stgraber> where we apparently now have nfs.ko, nfsv2.ko, nfsv3.ko and nfsv4.ko (at least on my laptop)
[04:08] <infinity> Right.  I'll look at initramfs-tools tonight.  Though if casper has its own copy_module and/or nfs bits, that'll need love.
[04:10] <stgraber> casper calls modprobe, so that'll need to be updated
[04:10] <infinity> That might work.  I have no idea how this new scheme works.
[04:11] <infinity> Seems like it would be slightly broken if they expect you to modprobe all the versions just to detect the protocol on the other side.
[04:11] <stgraber> apparently we just inherit the nfs modules in the initramfs from the defaults in initramfs-tools but we can probably get away with just adding some manual_add_modules to hooks/casper as we already do it for cifs anyway
[04:11] <stgraber> hmm, indeed, you'd expect nfs.ko to do the negociation, figure out what's at the other end, then get the kernel to load the right version
[04:11] <infinity> stgraber: You could, but we want them in the default initrd anyway, I imagine.
[04:12] <infinity> stgraber: As to the auto-loading (which seems like the sane thing to do), do you have a quick way to test that?
[04:12] <infinity> Since you're the master of VMs and all. :P
[04:12] <infinity> Like, just put up an NFS server that speaks v3-only, try to mount something from it, repeat with v4.  See what the client does.
[04:13] <infinity> I'd expect that modprobing even nfs itself is overkill, but maybe not.
[04:17] <veebers> stgraber, infinity: to confirm, following your conversation that I didn't completely follow :), that in a day or so I will be able to net boot the raring iso like I have been the quanal/precise?
[04:19] <infinity> veebers: One way or another, yeah.  Maybe.  I'll be fixing it mostly blind.
[04:19] <veebers> infinity: awesome, cheers. Let me know if I can do anything to help
[04:20] <stgraber> alright, got a repacked initrd with nfsv3 and nfsv4 + updated modules.dep, let's see if that works any better
[04:28] <infinity> stgraber: Oh, that's going all out.  I was just suggesting mounting from a client machine with a 3.7 kernel to see if it autoloads modules sanely.
[04:28] <infinity> But netbooting ISOs for fun and profit works too.
[04:29] <infinity> stgraber: My assumption would be that even modprobing nfs is overkill, since "mount -t nfs" should ask the kernel to DTRT.
[04:29] <infinity> stgraber: But maybe there's some special chicken and egg reason with nfsroot that one can't do that?  I dunno.
[04:34] <stgraber> ok, so we need a bit more than just nfsv3 and nfsv4 apparently, some nfsacl module is also needed. Adding that now
[04:38] <infinity> Oh, freakin' praisellujah.  All my glibc testsuite regressions are fixed on x86.
[04:38]  * infinity waits for his powerpc machine to catch up before he uploads.
[04:42] <stgraber> ok, so I have some weird issues because of dual-natting between my VM an my nfs server, but besides that, it looks like adding nfsv3.ko, nfsv4.ko and nfs_acl.ko did the trick
[04:42] <stgraber> doing a simple mount -t nfs loads nfs and the right module for the supported protocol (in this case my server was v3 only)
[04:44] <infinity> Mmkay.  I wonder if I want v2 as well, or if we can just pretend that doesn't exist in the wild anymore.
[04:44] <infinity> Anyhow, I'll commit something to upstream initramfs-tools and then land it in my merge.
[04:45] <infinity> After I finish watching Dexter.  Which is very important.
[17:31] <xnox> bug 837054 is fix released \0/
[17:31] <ubot2> Launchpad bug 837054 in Ubuntu Geonames "Time Zone selection shows about 20 different "New York"s and doesn't autoselect my location" [Medium,Fix released] https://launchpad.net/bugs/837054
[17:33] <ogra-cb_> wohoo
[17:33] <ogra-cb_> congrats
[17:33] <xnox> coding for lucid is fun =)