=== JaneW [n=JaneW@dsl-165-202-116.telkomadsl.co.za] has joined #ubuntu-kernel [01:08] so I'm using git-bisect to find this ia64 kernel annoyance... and the bisected place is FTBFS... how do I tweak it one version to the left or right? [01:14] heh... RTFweb-page [01:27] BenC: ping === lamont would love to know where the debian/ directory went... === lamont decides to just blame it on 64-bit isms in git [01:36] master source tree to do the git bisect commands in, then rsync --delete it to the other machine to build and test. simplicity in its finest [01:53] BenC: ping https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/41284 === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-22.34 uploaded (The last kernel you'll ever need....just kidding....but not really) | If you have ANYTHING you want in dapper kernel, message BenC here, or email me directly bcollins@ubuntu.com (malone is kind of noisy right now so I might miss things on there) === Topic (#ubuntu-kernel): set by BenC at Sun May 7 16:36:45 2006 === #ubuntu-kernel [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup === human_blip [n=mike@220.157.65.236] has joined #ubuntu-kernel [04:15] git bisect good [04:15] Bisecting: 90 revisions left to test after this [04:15] woot! [04:17] otoh, make -j4 on the faster box is nice. [04:18] and ccache is love [04:22] cluster stuff, or acpi... now there's a trivial-seeming question [04:25] 1.5% ccache miss rate. [04:31] You already have a ELILO configuration in /etc/elilo.conf [04:31] Install a boot block using the existing /etc/elilo.conf? [Yes] [04:31] grumble. I thought we'd fixed that [04:33] and git-bisect bad [04:33] 18 minutes. not bad === human_blip [n=mike@220.157.65.236] has joined #ubuntu-kernel === lamont gets to play with reverted reverted acpi patches [04:37] oh joy [04:50] BenC: any chance you're around? === lamont rolls the dice again [05:27] Keybuk: Still around? [05:27] infinity: yup [05:28] Keybuk: Does udev create tape devices? [05:28] dunno, know anyone who's got one? [05:28] (From #ubuntu-server): [05:28] 19:22 < IRCsloth> anyone using an adaptec 29160 and a Seagate DDS4 drive? [05:28] 19:23 < IRCsloth> in 2.4 based kernel distros without udev I get a /dev/st0 device but on hoary i [05:28] see the device in dmesg but a /dev/ device doesn't get loaded. [05:28] Err, "but on hoary"... Nevermind. [05:28] get them to try a dapper CD [05:28] Somehow I missed that bit. [05:28] I assume it does [05:28] I can't believe the kernel people would have driver-core'd scsi and missed of tapes [05:29] I've got a rule in there to put them in the "tape" group too [05:29] Does seem unlikely. [05:31] SYSFS{type}=="1", RUN+="/sbin/modprobe -Qba st" [05:31] yeah, I do that too === Keybuk just checked [05:32] neato. 4900 lines of diff -u, and the patch break in the middle of the two fails in a completely different manner. [05:32] st_class_member = [05:32] class_device_create(st_sysfs_class, NULL, [05:32] MKDEV(SCSI_TAPE_MAJOR, [05:32] TAPE_MINOR(dev_num, mode, rew)), [05:32] &STp->device->sdev_gendev, "%s", name); [05:32] looks ok to me [05:33] Keybuk: Kay, cool. Thanks. [05:33] that's far too much research [05:33] this SoC list is soul destroying [05:33] Keybuk: udevplug shouldn't spew a series of visit_entry: error stat '/sys/devices/pci0000:a0:0000:a0:04.0/////////////////////////////re': No such file or directory [05:34] right? [05:34] I don't think I've ever seen "Begin: Waiting for the root file system... ..." before. [05:37] lamont: no, it shouldn't do that :p [05:37] that sounds like rr sysfs gone bye-bye [05:38] lamont: initramfs-tools does that if you enter mountroot() without the root file system device existing [05:38] it'll wait up to three minutes for it to show up, on the basis you may have a slow scsi/usb device that hasn't caught up yet [05:46] yeah... so now I have a diff to stare at. [05:46] I just wish it were shorter. === lamont wonders if drivers/acpi/tc1100-wmi.c actually gets used on ia64 [05:49] sadly, that's not part of the diff though [05:49] but it does have an ia64-fatal bug [05:50] CC [M] drivers/pci/hotplug/acpiphp_glue.o [05:50] drivers/pci/hotplug/acpiphp_glue.c: In function ioapic_add: [05:50] drivers/pci/hotplug/acpiphp_glue.c:633: warning: gsi_base may be used uninitialized in this function [05:50] there's a candidate [05:52] acpi_bus_generate_event(device, event, (u32) wmi->state); [05:52] neato === dapp-live-macmin [n=ubuntu@cpe-066-057-008-035.nc.res.rr.com] has joined #ubuntu-kernel [06:05] mjg59: around ? [06:06] dapp-live-macmin/g2: he's most likely asleep, as he's in the U.K. [06:06] crimsun: thx [06:08] crimsun: I guess the dapper livecd kernel only runs one processor, correct ? [06:15] incorrect [06:15] dapper kernels are SMP [06:16] Keybuk: then it's a bug [06:16] what is? [06:17] or acpi only reports 1 processor for a duo [06:17] pastebin /proc/cpuinfo [06:18] http://pastebin.ca/54982 [06:18] and uname -a ? [06:18] 2MB cache size ... yummy [06:18] LiveCD uses -386 doesn't it? [06:19] nod [06:19] Which is the only non-SMP kernel. [06:19] ahh, I thought -386 was SMP as well now? [06:19] (To support some sketchy old ISA drivers that aren't SMP-able, IIRC) [06:19] uname -a [06:19] Linux ubuntu 2.6.15-21-386 #1 PREEMPT Fri Apr 21 16:43:33 UTC 2006 i686 GNU/Linux [06:19] yeah, infinity's right, that isn't an SMP kernel [06:19] sucky [06:20] Is there a different livecd ? [06:20] Given the nasty hardware requirements of a livecd in general, I'd be all for taking a vote to change the livecd to -686, but that would be for Edgy. [06:20] Now way we want to make that sort of change 3 weeks before dapper. [06:20] or can I roll my own kernel and rebuild the livecd ? [06:20] s/my/ubuntu's/ [06:21] dapp-live-macmin: Is it really important that the livecd use both cores? [06:21] infinity: well actually I'm looking to have a macmini based ubuntu [06:22] so I'll want that kernel for the install [06:22] dapp-live-macmin: the fact the CD isn't bootable on a Mactel will hit you first ;) === human_blip [n=mike@220.157.65.236] has joined #ubuntu-kernel [06:22] umm I'm booted on it now [06:22] dapp-live-macmin: Anyhow, you could take the squashfs from the livecd, mount it, "cp -a" the contents to a directory, chroot into it, "apt-get --purge remove linux-image-2.6.15-21-386 && apt-get install linux-686", exit, and resquash the FS. [06:22] oh, did someone make mkisofs support HFS+ thingy now? [06:23] Keybuk: no, boot camp can boot to ISO CDs [06:23] dapp-live-macmin: But what's on the livecd doesn't matter for the install. You boot the livecd, install to the real system, install another kernel. [06:23] oh, you boot-camped it [06:23] that's cheating, anyway :) [06:23] Keybuk: well for now [06:23] dapper can't see the hfs fs [06:24] I'm planning on having a dual Mac OSX/ Ubuntu environment anyway [06:24] I think with refit, and lilo/elilo I might be able to install Dapper now [06:25] and have refit default to ubuntu [06:26] My pal did an install from the livecd and it trashed Mac OS [06:26] it's confused about the real MBR [06:26] elilo [06:26] that issue needs to be worked out [06:26] Keybuk: does elilo build with dapper ? [06:27] Yes, it's in dapper. [06:28] infinity: that's the binary right ? [06:28] -EPARSE [06:29] Of course the binaries are in dapper. Doesn't make much sense to just ship the source. :) [06:29] although, if we only shipped the source, we wouldn't need anyone to feed the buildd hamsters [06:29] infinity: wel my question was does it build with dapper [06:29] The hamsters are doing well today anyway. [06:29] I gave them 3000 packages to eat, and they've not choked much. === infinity finds some wood to knock on. [06:30] dapp-live-macmin: Yes. Does build and is built. [06:30] the ia64 port kinda relies on it [06:30] Keybuk: Well, to be fair, we had to hunt a few obscure bugs to make it stop breaking on i386/MacTel. [06:31] But yes, we've been building it for ages on ia64, and it works fine. === fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-kernel [06:31] (And by "we", I mean mjg59, who did most of the hunting and irritating us on IRC until it worked) :) [06:32] he gave up before he finished though :) [06:32] once all the difficult bits were done, he got bored [06:32] Well, the only blocker is the hfs+ thing. [06:32] yeah, and that's "trivial" [06:32] If so, please fix it on Saturday in your copious spare time. :) [06:32] Keybuk: great, so I'll play clean up [06:33] heh, I did look at it actually [06:33] and it's in my todo list if nobody beats me to it [06:33] but haven't yet reached any spare time [06:33] mostly just plodding through the Apple HFS+ spec and cargo-culting the existing HFS code in mkisofs to match [06:34] I need new hardware. [06:34] you do? [06:34] what's wrong with the hardware you have? [06:34] No ipw3945, no ATI X1xxx, no MacTel, I had nothing "obscure" for this release cycle to test on. [06:35] heh === Keybuk hugs his X2 [06:35] Last cycle, I was all about "new and broken" with my PCIe laptop, which is now old-hat. :) [06:35] nothing particularly obscure, except nothing in Linux supports SLI [06:35] nVidia SLI? [06:35] aye [06:35] The craptastic binary driver can do it, no? [06:36] it claims to yes [06:36] Its claims are false? [06:36] I have to use that anyway, as the even-crapper source driver goes "is that an nVidia? doesn't look like one to me!" [06:36] dunno [06:36] glxgears -iagreethatiamanaadvark gives me 300000 FPS [06:36] Ouch. New PCI IDs, or are we programming the card wrong? [06:36] so I guess that could be an indication that it works [06:36] infinity: not sure [06:37] they're pretty new cards [06:37] 7800 GLX [06:37] Could just be PCI IDs, then. If you could test adding your IDs to nv, that would be awesome. [06:37] could be supported now, but weren't earlier [06:37] is dma for disks turned on in this kernel ? [06:37] 7900 and some 7800 stuff were pretty shiny just recently. [06:37] dapp-live-macmin: probably [06:38] we turn dma on if it looks like it won't bring the world down in pieces around you [06:38] infinity: it's sufficiently shiny that lspci just says "Unknown device" [06:39] Oh, lord. You wouldn't believe the number of users who think installing an X driver should change the PCI database. [06:40] hmm, PCI id is listed in the nv driver now [06:40] it might work [06:40] I've got a reboot coming up for new kernel anyway, will try it then for kicks [06:40] I've triaged SEVERAL bug reports that say something like "I installed fglrx, but lspci still says 'Unknown Device' for my video card, does that mean it doesn't work?" [06:40] *giggle* [06:41] yeah, it's amazing how down-trodden people look when you explain it's just a text file that somebody gets round to updating some time each century === infinity nods. [06:41] I guess it wouldn't hurt to have that text file have some sort of include functionality, and let upstreams ship updated ID/description pairs, but that's certainly not done now. [06:41] I like how each PCIe card appears numbered as if it were an entire bus all to itself [06:42] I also like how the PCIe subsystem is busted, and just numbers everything pcie00 === dapp-live-macmin likes how PCIe has BW [06:42] They are a bus to themselves. [06:42] 0000:01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0090 (rev a1) [06:42] 0000:02:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0090 (rev a1) [06:42] PCIe guarantees dedicated bandwidth, unlike PCI. === dapp-live-macmin is now known as [g2-macmini] [06:42] . o O { one would have thought I'd've patched that by now to actually say the right card } [06:43] but given it's a "standard" file, probably best just to leave it alone [06:44] ... It'll be out of date a month after release anyway, so whatever. [06:44] what's wrong with this picture? :) [06:44] quest scott% ls /sys/bus/pci_express/devices [06:44] pcie00@ pcie00@ pcie00@ pcie00@ pcie03@ pcie03@ pcie03@ pcie03@ [06:44] -- [06:45] The same thing that's wrong with mine? :) [06:45] readlink /sys/bus/pci_express/devices/pcie00 ... which one? [06:45] I just love how sysfs doesn't have to follow any of the usual rules of a sane filesystem. [06:45] "Bah, duplicate filenames are FINE" [06:45] Keybuk: [06:45] it's _supposed_ to follow the usual rules [06:45] the pci_express bus is just busted [06:46] i was almost close to point the sodomotron towards you this morning when i saw "Waiting for nfs /path/to/nothing/real"... [06:46] (in-kernel implementation that is) [06:46] ;) [06:46] Anyhow, all my duplicate links all go to the same duplicate target, so it's harmless, just ugly. [06:46] infinity: that's a bug too [06:46] oh grr @ paste [06:47] /sys/devices/pci0000:00/0000:00:0e.0/pcie03 [06:47] /sys/devices/pci0000:00/0000:00:0e.0/pcie00 [06:47] /sys/devices/pci0000:00/0000:00:0d.0/pcie03 [06:47] /sys/devices/pci0000:00/0000:00:0d.0/pcie00 [06:47] /sys/devices/pci0000:00/0000:00:0c.0/pcie03 [06:47] /sys/devices/pci0000:00/0000:00:0c.0/pcie00 [06:47] /sys/devices/pci0000:00/0000:00:0b.0/pcie03 [06:47] /sys/devices/pci0000:00/0000:00:0b.0/pcie00 [06:47] -- [06:47] supposed to be different devices [06:47] fabbione: I could do with a go on the sodomotron, bf isn't around for a couple of weeks :-/ [06:47] what was it? [06:47] Keybuk: ehhe stop fixing bugs than :P [06:48] fabbione: was it the "keybuk uploaded the debugging version of that script which happily looked inside comments" one? :) [06:48] Keybuk: yes... [06:48] Keybuk: it took a while to boot up ;) [06:48] bah, it only waits 90s [06:48] cat /etc/fstab | grep ^# | wc -l [06:48] 34 [06:49] dude, wtf do you have in your fstab ?! [06:49] most of them are old nfs mount points to shared chroots [06:49] oh i am not that upset... [06:51] aww [06:52] <[g2-macmini] > Keybuk: any idea how fast the GigE is on the mini duo ? [06:53] [g2-macmini] : probably about 1,024Mb/s [06:53] <[g2-macmini] > Keybuk: you think it's do line rate ? [06:53] I've got no idea [06:54] the answer appears to be in the question though [06:54] "how fast is this 300 baud modem?" ... "300 baud" [06:54] "how fast is this GigE network card?" ... "gigabit" [06:54] <[g2-macmini] > my AMD64 does 400+Mbs and which is limited by the SATA disk [06:54] <[g2-macmini] > it'll do 600+ over the wire from memory [06:54] <[g2-macmini] > and 2.4Gbs through the IP stack [06:55] <[g2-macmini] > real numbers measured [06:55] SATA should be faster than that [06:56] isn't it 300MB/s ? [06:56] <[g2-macmini] > no hdparm returns around 60MBs [06:56] <[g2-macmini] > and I get about 57-58MBs over the wire [06:56] Keybuk: well the speed of the bus != speed of the disk :) [06:56] <[g2-macmini] > so it's disk limited [06:57] fabbione: true [06:57] <[g2-macmini] > when I pull from memory it goes 600+ [06:57] Keybuk: when i pull from my SAN i get around 200MB/sec from the disks [06:57] but then i hit the switch 2Gb bottle neck [06:57] <[g2-macmini] > I haven't RAIDed the disk as 28 seconds for a Gigabyte transfer was fast enough [06:58] Timing cached reads: 3660 MB in 2.00 seconds = 1829.36 MB/sec [06:58] 8GB/s should be more than enough to saturate a GigE [06:58] <[g2-macmini] > fabbione: you should be able to do 256MBs on the 2G no ? [06:58] <[g2-macmini] > 128MB will saturate a GigE [06:58] [g2-macmini] : never heard of protocol overheads? [06:58] hell, my laptop can saturate it's gige [06:59] when you start encapsulating scsi over fc-hba over raw fiber... [06:59] <[g2-macmini] > fabbione: yes I was talking relative not absolute === [g2-macmini] used to write NPU firmware [07:00] [g2-macmini] : raw = 2Gb.. [07:00] once you get to the data i get around that [07:03] <[g2-macmini] > well nice chatting guys [07:03] <[g2-macmini] > time to reboot this mini and build elilo on another boxen [07:04] <[g2-macmini] > cheers all === [g2-macmini] [n=ubuntu@cpe-066-057-008-035.nc.res.rr.com] has left #ubuntu-kernel ["Ex-Chat"] [07:04] "build" ? [07:04] is he a Gentoo person, do we think? [07:05] (no, he uses Debian, and he works with the openwrt guys. he's from my LUG.) [07:16] BenC: btw, 7e856098daf7275030504b7f149f49e27010e887 or the one before it is the patch that broke ia64 [07:25] infinity: got a second? [07:26] Depends. Will my second be useful to you? [07:26] all the blah-22-* in anastasia are due to an ABI change, right [07:26] in the seeds they're still -21-* [07:26] should those be updated now, or is there some reason they haven't? [07:27] The seeds should be updated to 22, now that d-i has been. [07:27] Apparently, someone forgot, assuming that someone else would do it. :) [07:28] I can do the seeds now, if you'd like. [07:28] I have the seeds open now [07:28] was making other changes [07:28] Kay. Do everyone at once. [07:28] yup [07:28] (For this change, anyway) [07:28] quest dapper-seeds% grep " * Kernel-Version" * [07:28] installer: * Kernel-Version: 2.6.15-22-amd64-generic [07:28] installer: * Kernel-Version: 2.6.15-22-hppa32 2.6.15-22-hppa64 [07:28] installer: * Kernel-Version: 2.6.15-22-386 [07:28] installer: * Kernel-Version: 2.6.15-22-itanium-smp [07:28] installer: * Kernel-Version: 2.6.15-22-powerpc 2.6.15-22-powerpc64-smp [07:28] installer: * Kernel-Version: 2.6.15-22-sparc64 [07:29] Right, so merge that to kubuntu/edubuntu/xubuntu, so we can all be happy about the CDs not being broken. [07:29] this will cause a whole bunch of stuff to want to move to universe, right? === infinity suspects this is the cause of lamont's earlier lament that his kernel didn't match his modules on a recent daily CD. [07:30] how do you tend to merge? just pull the lot? [07:30] Keybuk: Should cause all of the -21- stuff to want to go to universe, but we just want to remove it anyway, since it's NBS. [07:30] right [07:31] Keybuk: I just merge the single revision. I keep all the seeds sitting next to each other, so I can just do "bzr merge -r15..16 ../ubuntu/" in the other seeds. [07:32] yeah, never changed the others before [07:32] just copying and reverting them now [07:36] ... I made a 1-line change, why does push take a metric week? [07:37] sigh. -g kernel machine checks [07:41] . o O { I should be able to bind these checkouts now, right? :p } [07:47] I'm mostly bzr illiterate, so I dunno. [07:52] right, gonna try that reboot and nv driver === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel [08:21] CC [M] drivers/media/video/stradis.o [08:21] drivers/net/skge.c:108:25: error: h/skversion.h: No such file or directory [08:21] CC [M] drivers/media/video/cpia.o [08:21] bad kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === human_blip [n=mike@220.157.65.236] has joined #ubuntu-kernel === doko_ [n=doko@dslb-088-073-095-044.pools.arcor-ip.net] has joined #ubuntu-kernel === human_blip [n=mike@220.157.65.236] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [01:06] BenC: can you please pull from my archive before next upload? [01:06] changelog: add inotify syscalls to syscall_table.S for parisc === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === human_blip [n=mike@220.157.65.236] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [02:13] heylo [02:15] hi zulighno [02:15] heh...hey fabiomassimo [02:17] how is it going? === TheMuso [n=luke@ubuntu/member/themuso] has joined #ubuntu-kernel [02:23] zul: as usual and you? [02:24] just winding stuff down at work [02:24] how is x going? [02:25] it's going... another day and it will be done (my side) [02:26] cool [02:29] fabbione: yeah, pulling now === BenC notices this morning he forgot about the distro meeting [02:29] BenC: thanks dude.. any ETA for the upload? [02:29] hopefully over the weekend [02:30] ok === fabbione is getting ready for holidays [02:30] staying home? [02:30] BenC: i dont think you got back to me last night about my noapic question [02:30] zul: "yes" [02:31] okie dokie [02:31] zul: nope... [02:31] or i didnt see the anwser [02:31] flying to italy for 4 days [02:31] I think we are having a dmi blacklist issue with some IBM laptops though [02:31] and 2 days at home [02:31] fabbione: have a relaxing time [02:31] BenC: i hope so.. i need it === human_blip [n=mike@220.157.65.236] has joined #ubuntu-kernel [02:32] IBM laptop dmi blacklist? [02:33] I think there are some IBM laptops that are broken because some blacklist is too vague [02:33] BenC: Whereabouts? [02:34] problem is right now that my guess about this is very vague aswell :) === lloydinho [n=andreas@rosinante.egmont-kol.dk] has joined #ubuntu-kernel [02:34] the guy at IBM doing our abat stuff can't boot his laptop with dapper [02:34] I need to catch him when he has some time [02:36] Urgh. What hardware? [02:37] can't remember, he pasted this info in /msg while I was asleep last week === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [02:38] Heh [02:38] I didn't think we had any Thinkpad DMI lists, except for apm [02:40] BenC: where is the list btw? [02:40] I can't recall where off hand, but I remember adding some R30 stuff over the course of dapper [02:42] BenC: Oh, yes. R40. [02:42] But all that does is disable CPU low-power states. === tuxmaniac [n=aanjhan@60.254.67.17] has joined #ubuntu-kernel [04:08] <[g2] > Keybuk I'm a build from source kinda guy, my company does embedded linux distros [04:09] <[g2] > I did a couple year tour with Gentoo, but for the past couple years it's be OpenEmbedded and Debian/Ubuntu [04:10] <[g2] > would this be the place to chat about an EFI network installer or #ubuntu+1 ? [04:11] <[g2] > #ubuntu-boot ? [04:13] EFI or PFE? === BenC has done EFI on an ia64 [04:13] <[g2] > EFI [04:14] what does it need? [04:16] <[g2] > BenC let's back up a minute... what's PFE ? [04:16] maybe it's PFX, but it's the intel network boot protocol [04:16] for x86 [04:16] PXE isnt it? [04:16] yeah, that's it :) [04:16] too many stupid acronyms [04:16] <[g2] > heh [04:16] heh...pxe is easy to do..i have done it before [04:17] <[g2] > well the MacIntel already has network booting as an option [04:17] I thought EFI would be even easier, just create a kernel+initrd image [04:17] <[g2] > I haven't tried network booting dapper [04:17] BenC: same thing with PXE [04:18] <[g2] > so there are 2 scenarios [04:18] PXE is easy, but the lilo pxe stuff isn't straight forward to setup [04:18] true, but I used syslinux [04:18] <[g2] > 2 scenarios I can see for the MacIntel [04:18] <[g2] > 1) your replacing Mac OSX and it doesn't matter your taking over the machine [04:19] g2: ia64 is EFI, and we support network booting from it, so I suggest just duplicating what it does [04:19] <[g2] > 2) you want to co-exist [04:19] <[g2] > or tri-boot [04:19] g2: well, those are installer issues, handled at install, irregardless of the boot method [04:19] and I am pretty sure we handle them in some way [04:20] not sure that the x86 installer is pivvy to MacOSX being a possible alternate OS though :) [04:22] <[g2] > BenC well Dapper trashed my OSX rootfs last night when updating the 3rd partition [04:22] <[g2] > so while in theory it doesn't matter at all, there are in practice issues to be worked out [04:23] definitely an issue for #ubuntu-boot or whatever channel [04:23] <[g2] > ok I'll take that up over there [04:24] <[g2] > that leaves the issue of building the kernel to run from EFI [04:24] <[g2] > i'ts a kernel config option for running from EFI that doesn't have legacy support from my understanding === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [04:34] EFI is enabled in the kernel [04:34] not sure what else would be needed, if anything [04:34] Our kernels are already MacTel-ready, afaik. [04:35] We're just lacking a tiny bit of mkisofs magic to get our install CDs to boot sanely, so we can go from there. [04:36] And no, booting with bootcamp doesn't count, since that then doesn't give us an EFI-ish system to work with, and sucks in ways we'd rather not deal with. [04:41] <[g2] > infinity so basically it's Ubuntu or the highway ? [04:41] Err, no... [04:42] Basically, it's "we need to fix our mkisofs to create HFS+ magic, then we can worry about the installer working right" [04:42] Cause B won't ever happen without A. [04:43] <[g2] > infinity can we work on both issues in parallel ? [04:44] <[g2] > I've got 2 mini's one is the target [04:44] <[g2] > so from EFI we can do many things to the disk [04:44] Can you boot the install CD from EFI? [04:44] <[g2] > I do with boot camp [04:44] If not, it's a bit tough to test the install CD as booted from EFI. [04:44] You see what I'm saying here? [04:45] bootcamp provides you with some extra layers of hardware abstraction we don't want to deal with, aiui. [04:45] (like giving us a fake VGA BIOS we don't want to deal with, etc, etc) [04:46] <[g2] > right, no need to re-invent the wheel twice [04:46] <[g2] > I'm fine with that, I'm asking more about compatibility [04:47] <[g2] > if I understand you, having an HFS+ based livecd allows the CD to boot from EFI by just holding down the "C" or Apple C key [04:47] <[g2] > that's the place you want to start from, correct ? [04:48] It's not the filesystem on the livecd that matters, but the tiny little boot filesystem that the bootloader is read from. [04:48] <[g2] > stick in the CD/DVD, hold the C/Apple C key down, wake up in Ubunutu [04:48] But yes, essentially, we need HFS+ on the CD, so we can bless it, so the braindead MacTel version of EFI will boot it. [04:49] <[g2] > correct [04:49] <[g2] > my point was we can bless the disk image that will result from the install and potentially start testing and debugging that now [04:50] <[g2] > you are absolutely correct, that for the process to work straight from CD/DVD other things need to happen 1st for the final product [04:51] <[g2] > I'm just suggesting a different way of debugging the process which may be totally off base === \sh [n=shermann@unaffiliated/sh/x-000000002] has joined #ubuntu-kernel [05:29] <\sh> moins [05:29] <\sh> dpkg-gencontrol -isp -pkernel-source-2.6.15.6-ubuntu1 -Pdebian/tmp-source/ [05:29] <\sh> dpkg-gencontrol: error: package kernel-source-2.6.15.6-ubuntu1 not in control info [05:29] <\sh> is it just me? or is the latest kernel package somehow not buildable [05:30] [g2] : If you boot in boot camp, you don't have access to EFI [05:30] [g2] : Our kernels have about as much mactel support as they're going to have (other than a couple of bugs which I've just submitted patches for) [05:31] [g2] : I've been testing the Ubuntu installer. We know what bugs there are for mactel installs, and they're pretty easy to fix. The booting is the fundamental issue [05:33] <\sh> ok...apt-get source and apt-get install is totally different...problem is sitting in front of the keyboard [05:36] BenC: ping [05:38] \sh: -22.34? [05:42] <\sh> lamont: yeah...just installed the source package of the source package of the linux kernel .. totally wrong [05:42] \sh: its easier if you install git and get the git tree [05:42] and it sounds like you installed kernel-source instead of linux-source... [05:54] lamont: pong [06:05] <\sh> lamont: yeah I did:) [06:06] <[g2] > mjg59 ok so let's talk about the booting [06:07] [g2] : As far as the booting goes, you can either boot with bootcamp (loses access to EFI) or from EFI (for booting off CD, this requires an HFS+ filesystem on the CD to contain a blessed elilo) [06:08] <[g2] > ok timeout right there [06:08] <[g2] > booting with bootcamp to the current Dapper 2 beta works [06:09] <[g2] > clearly, the install is the issue IMHO [06:09] <[g2] > as that standard image _could_ just install and bless and HFS+ fs on the disk, no ? [06:10] <[g2] > I can fully understand ubuntu may want to release a _next gen_ EFI i32/i64 release that utilized EFI [06:11] <[g2] > I think your second scenario is that instance on an HFS+ fs [06:12] <[g2] > does that make sense ? [06:17] [g2] : No [06:18] <[g2] > mjg59 Ok [06:18] We don't have anything for producing HFS+ filesystems [06:18] (We won't distribute APSLed stuff) [06:19] <[g2] > is HFS+ under some Apple souce license ? [06:20] Yes [06:20] <[g2] > Ok, so two issues with that are: [06:20] But if you're booting with boot camp, then there's no point in creating extra HFS+ partitions [06:21] Since you've almost certainly got MacOS anyway, and it comes with one [06:21] <[g2] > right [06:21] The biggest drawback with bootcamp is that dealing with the partition table is very very difficult [06:21] Because you have two partition tables that have to be kept precisely in sync [06:23] <[g2] > so you are saying we put elilo on the 3rd partition and format that in a sane way [06:24] No [06:24] elilo can live happily in the FAT partition [06:24] But you need to be able to set EFI variables to make it bootable [06:25] <[g2] > well bootcamp already creates a FAT partition that's bootable no ? [06:25] No [06:25] Not in any useful way [06:25] It's not about whether partitions are "bootable" or not [06:25] In the Mac universe, there's no such thing [06:25] <[g2] > this is all EFI stuff [06:26] <[g2] > and apple's implementation of it [06:26] No [06:26] Macs do not boot in the same way as EFI does normally [06:26] Apple have wedged their own boot system into EFI [06:26] EFI can boot off any partition it can read files off [06:26] <[g2] > right as it's "open" more so in the BSD sense [06:27] I have absolutely no idea what you're talking about, I'm afraid [06:27] The mactel boot system is basically a slight modification of the way Macs have booted since the blue and white G3s [06:27] <[g2] > I mean the EFI code apple is using is probably based on the EFI code release as a reference by Intel [06:28] In order to get EFI to boot a file, you need to have access to EFI [06:28] But Apple have provided no mechanism for doing that [06:29] <[g2] > the EFI boot loader is read in off the SPI right ? [06:29] <[g2] > a question is how locked down that SPI is [06:30] <[g2] > my boards ship with a JTAG header to be able to reflash the bootloader [06:30] <[g2] > I'm sure there's some equivalent on the Mini's [06:31] Well, the question here is what are you trying to do? [06:31] <[g2] > that's easy -- dual boot dapper and os x [06:31] If you just want to run something yourself, this can all be done without JTAGing [06:31] There's a couple of bugs in the installer that you'll have to work around, but other than that all you need is a USB stick [06:32] <[g2] > Ok, usb stick/ external usb drive ? [06:32] Yeah [06:32] That's the easiest way [06:32] <[g2] > I've got plenty of those [06:33] Make an HFS+ partition on it, copy the kernel and initrd off an install CD, put elilo on there, write an appropriate elilo.conf (it just has to pass the same kernel options as isolinux would), bless elilo, reboot, hold down alt, select the USB drive [06:34] And make sure the install CD is in the drive [06:37] <[g2] > Ok... what about creating another partition that has the squashfs or the whole contents of the CD inside and pass an option th the kernel that elilo is booting ? [06:38] <[g2] > that way the booting kernel doesn't need to deal with HFS+ which is the issue at hard, but the media doesn't need to be CD either [06:38] There's no requirement for the media to be CD [06:38] It's just handy [06:38] You can put it on a USB device or whatever if you want [06:39] <[g2] > ok, so mounting on the network would work too [06:39] I believe so, yes [06:39] In that case you might need the netinstall images rather than the ones on the install CD [06:39] But at that point it's fairly unrelated to the kernel, so not really on-topic here [06:40] <[g2] > right [06:43] BenC: if you happen to upload a new kernel before I finish tracking down 40286? (ia64 oops), please change ia64 config to have CONFIG_ACPI_DEBUG=y [06:43] that at least masks the problem. [06:48] crimsun: I think we need a combined headphone/mute LED quirk [06:50] <[g2] > mjg59 infinity THX for the time discussing the EFI/kernel issues === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [07:02] mjg59: commit http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=2de01f5ad849fae75ea6339a7c8e9d08b49178e0 was originally the combined headphone/mute LED quirk, which was the state in -21- that bug 44066 reports. If we revert that, we break what was fixed in bug 41015. Apparently we have identical sub{vendor,device} ids with different behaviour :/ [07:03] crimsun: I've wondered whether that's possible. Oh dear. :/ [07:05]