=== dannf` is now known as dannf === smb` is now known as smb [07:41] * apw yawns [07:43] * smb waits [07:46] smb, have you seen this KVM hang people are reporting in saucy (since -3 i _think_) [07:47] apw, no, but mostly because I have not yet looked at kvm recently as I was busy with xen [07:47] (and by hang i mean host locking solid) [07:48] apw, do you have the bug number more ready than me? [07:48] i saw it myself last night, and someone was reporting it on #ubuntu-kernel last night, but though i asked for a number i wasn't present if and when it was filed [07:49] Hm... lets see what is see in scrollback... [07:56] so there was no bug from jdstrand then ? [07:56] not mentioned in this channel [07:57] * apw starts looking to see whne it was introduced [07:57] * apw gets out a piece of paper === fmasi_afk is now known as fmasi [08:11] smb, jdstrand, KVM hang bug filed: bug #1204005 [08:11] Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005 === ara is now known as Guest55554 [09:01] apw: brb [09:01] ops [09:01] brb [09:01] ppisati, heh [09:43] booting into 3.10.0-4 messes up my graphics. Uses vesa because it can't find /dev/dri/card0. Is that a known issue? [09:43] oh, this is an intel card btw [09:54] larsu, If 3.10.0-3 was working still it might be the same module loading with arguments stopped working regression. I thought i915 was sometimes affected too. You might try the -5 kernel. apw, is that somewhere already [09:55] yep, -3 is definitely working (I booted into that now) [09:55] https://launchpad.net/ubuntu/saucy/+source/linux/3.10.0-5.14 [09:56] smb, larsu, seems to be in -proposed at the moment, but there are some prerelease ones here: http://people.canonical.com/~apw/master-next-saucy/ [09:56] Currently still in proposed but that should not be enabled [09:56] Or directly wget from launchpad [09:58] smb, apw: thanks, I will try that one [09:58] hey there [09:58] larsu, did you figure out your intel issue? [10:00] apw pinging you because I thought you might be up [10:00] wireless doesn't work for me with the new kernel :( [10:00] and it sounds like larsu has some video issues? [10:00] rickspencer3: yep, apw just pointed me to -5, which might fix the issue [10:01] http://people.canonical.com/~apw/master-next-saucy/ [10:04] smb, apw, rickspencer3: -5 fixes it indeed. Thanks! [10:04] larsu, great ... it is stuck in migration cause of the alpha2 freeze, but they actually want it [11:05] apw: re bug #1204005, thanks! [11:05] Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005 [11:10] apw, Unfortunately I am as unsuccessful in getting the hang with a EFI booted desktop as I was before... :( [11:11] smb, i am going to put that on the boggle list and not worry about it too much for now [11:11] smb, it is clearly reproducible for many of us, so that is very odd indeed [11:11] smb, so i get to find it :/ [11:12] apw, Yeah. Just sad that I cannot be of any help there [11:15] * ppisati -> reboot === fmasi is now known as fmasi_afk [12:15] diwic, hello! I'm ready for debugging whenever you can [12:15] nessita, hi, I just started looking at your logs [12:15] nessita, it looks like several "maybe" bugs in combination somehow [12:16] nessita, but first, don't get confused by Raymond - he's often out on the wrong track [12:16] diwic, I was going to mention, his comments really, really confused me [12:20] diwic, is there anything I can run/test from here to help? [12:21] nessita, maybe we should try the wakeup_rt tracer to see what's causing system latencies. Instructions coming shortly, I just have to refresh my memory a little on how to do that... [12:22] diwic, great, I'll wait for those [12:28] BenC: Were you going to do any regression testing (or a smoketest, at least) of the raring-proposed kernel on your hardware? [12:29] nessita, ok, now posted as comment in the bug [12:29] * nessita goes and check [12:31] nessita, when it says "run for a minute or two" that means run skype/mumble/hangout [12:31] diwic, what should I run for the "Run for a minute or two" part? [12:31] nessita, just try to talk to someone on mumble e g [12:31] ah, ok [12:37] diwic, attached, shall I also attach the pulseaudio verbose log? [12:38] nessita, thanks, I'm analysing the wakeup_rt file now [12:38] It's the graphics, that's for sure [12:39] diwic, the graphics mess up with the sound? [12:39] nessita, do you use open-source or binary nvidia drivers? [12:40] diwic, checking [12:40] nessita, binary it seems like [12:41] NVIDIA Driver Version: 304.88 [12:42] yeah, that's binary [12:42] yeah, wasn't fully sure because in the upgrade to raring I did not explicitely enabled any propietary drivers [12:43] so; either we can try pursuing this track, i e, trying different driver versions, open-source drivers if you don't need anything that the binary drivers provide etc [12:44] or I could try looking deeper on the PulseAudio side to see if I can understand why you start getting underruns every 200 ms [12:44] or both... [12:45] diwic, happy to do whatever you think is best. I'm not sure about the open-source drivers, there was a time were those were underperforming, no idea now [12:47] nessita, okay, let's say you give the open-source nvidia drivers (nouveau) a try, and see if they work sufficiently well for you or if they cause other trouble. [12:48] BenC, yo ... do i have access to your saucy repo, i was just trying to push the new linux-ppc-udebs thing that infinity was after [12:48] nessita, and if they cause trouble, come back to me and we'll try to look deeper on the PulseAudio side of things [12:49] diwic, so, before I do that, question: I reproduce the sounce bug in a raring booted in mem from a pendrive [12:49] diwic, doesn't that setup use the default stuff from the ubuntu repo? [12:49] I reproduced* === fmasi_afk is now known as fmasi [12:50] (ie, the default stuff would be the open source driver) [12:50] nessita, yes, if you boot Ubuntu from a pendrive, that should use the open-source drivers by default I believe [12:50] diwic, right, I reproduced the same audio playback issue there (was the second thing I tried -- first one was latest kernel) [12:51] nessita, so if that also causes the problem, it would be interesting to see what a pulseaudio verbose log looks like when booted from the pendrive [12:52] diwic, I can do that. Is there any way of enabling verbose pulseaudio output without rebooting [12:52] nessita, https://wiki.ubuntu.com/PulseAudio/Log doesn't include rebooting [12:53] diwic, ah, yes, but that disables autospawn, and I've noticed different behavior of the sound stopping with or without autospawn [12:53] nessita, in what way is it different? [12:53] without autospawn is much "harder" to reproduce the bug [12:54] with autospawn I can reproduce almost instantly [12:54] nessita, autospawn is unrelated, possibly the debug level can cause that effect, but not autospawn in itself I believe [12:54] diwic, but if the information is the same for you in both cases, I can certainly try that [12:55] nessita, you can also just execute "pacmd set-log-level 4", without restarting PA, and it will start outputting the verbose log to /var/log/syslog [12:55] nessita, if you like that better [12:55] diwic, I do! will use that [12:56] ok, so, rebooting to raring from pendrive [13:02] * henrix -> lunch [13:13] diwic: hi there, I'm in the raring booted from pendrive. Definitely using nouveau: video 19390 1 nouveau [13:13] yep [13:13] diwic: ran the pacmd set-log-level 4 command but verbosity did not increased in syslog [13:13] diwic: shall I have restarted the pulseaudio service? [13:14] nessita, no, that's not necessary [13:14] nessita, did "pacmd set-log-level 4" say anything else than "hi and welcome to pulseaudio"? [13:14] diwic: yes, it did [13:14] will paste the whole output [13:15] diwic: I had audio playback at first, but opened chrome to do a hangout and audio stopped. Pasting output [13:16] diwic: http://paste.ubuntu.com/5904065/ [13:16] PA output seems not verbose though [13:17] nessita, could you execute "pulseaudio -k", start the wakeup_rt tracer, go to a hangout, stop the wakeup_rt tracer and attach the output? [13:17] diwic: yes. Shall I start from a clean raring again? [13:17] nessita, from the pendrive [13:18] nessita, you don't need to reboot, just restart pulseaudio with "pulseaudio -k" [13:18] diwic: ack! [13:19] diwic: I have more log in syslog (opening it with less showed me that there was much more verbosity). Shall I pastebin that? [13:19] nessita, ok [13:21] diwic: http://paste.ubuntu.com/5904076/ doing the other test now (pulseaudio -k) [13:22] Scheduling delay of 105.41ms, that's a lot, really [13:26] diwic: does that give you any hint of what needs fixing? [13:26] nessita, the kernel needs fixing [13:26] heh [13:27] nessita, if we could capture one of those really high spikes with the wakeup_rt tracer it could tell what part of the kernel needed fixing, too [13:27] diwic: yeah, trying to do a hangout, but it keeps erroinh [13:27] erroing [13:27] * nessita is on it [13:28] nessita, you can also try just using the audio wizard in mumble [13:28] great, let me install mumble [13:31] gaaaah 2fa [13:31] * nessita hunts a 2fa code [13:31] nessita, no, just start the audio wizard [13:31] nessita, you don't need to connect to a server [13:31] diwic: yeah yeah, already did, the 2fa is for logging in to LP [13:31] and upload the trace [13:31] nessita, pastebin it here instead [13:32] diwic: as you wish, already found the code generator [13:34] diwic: http://paste.ubuntu.com/5904115/ (also uploaded to the bug) [13:34] jdstrand, you are hitting this hang in kvm, could you tell me which display adpater you have configured [13:36] jdstrand, if you have vmvga configured, could you switch it to cirrus and see if it will boot without eating your machine [13:37] Sarvatt, ping, what do you think of the trace nessita just posted? [13:37] Sarvatt, nouveau hanging the kernel for 90 ms? And nvidia did it for ~20 ms [13:39] Sarvatt, also I can't really understand that even if nouveau wants to do that, why don't we just schedule audio/Pulseaudio on another CPU core? [13:43] diwic: is there anything else I can do from this raring boot? happy to wait if that could help, but otherwise I may reboot to my "normal" setup [13:44] nessita, feel free to reboot to your normal setup [13:44] thanks [13:44] * nessita brb [13:51] diwic, so, I will be resuming some tasks, let me know if you need something else from me [13:51] nessita, ok, thanks! [13:52] thank you :) [13:54] diwic, not sure if it's relevant, but in all cases mic keeps working (people keeps listening to me) [13:55] nessita, I'm not sure if it's relevant either. [13:57] ack [14:00] apw, just pushed a rebase to saucy unstable that might impact the boot issues on your laptop. [14:01] bjf, apw: did either of you have time to read the k-team email I sent yesterday entitled 'Patches dropped on the way to 3.11-rc2' ? [14:02] rtg, i glanced at it [14:02] * bjf goes back to find it [14:03] BenC: Are you around? linux-ppc in saucy is very broken. [14:24] apw, After running for a while I had a kvm guest crash my AMD machine (using vmvga). Though it took a while and also the stacktrace points to virtnet ... === josepht_ is now known as josepht [14:32] smb, hmmm perhaps it is not the same, there seems to be a lot of issues this week [14:39] apw: lucid and precise are cirrus, quantal and higher are vmvga [14:40] let me reboot to see if either makes a differnce [14:41] jdstrand, it isn't reasonable for that to fix it at all, as clearly there should be nothing which allows a hang like this, but i would like to confirm you see the same as me [14:43] apw: yeah, and fwiw, cirrus is rubbish for quantal and higher [14:45] jdstrand, yep, i was much happier with the other one in R, but if it is that at least i have it cornered a little [14:45] there is a bug on that too [14:46] bug #1080674 was for display corruption [14:46] Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed] https://launchpad.net/bugs/1080674 [14:47] but on quntal, there were frequent guest crashes [14:47] I don't know if a bug was filed for that [14:47] jdstrand, fwiw it also affects Xen and you cannot change the gfx there :-P [14:48] * smb wished they had fixed the driver and not just the default gfx card for KVM [14:48] * rtg starts bisect for mb raid0 mount failure in 3.11-rc2 [14:48] md* [14:53] ** [14:53] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [14:53] ** [14:54] I assume someone's still looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204005 ? [14:54] Ubuntu bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] [14:55] infinity, I think apw is on it [14:55] infinity, yeah that one i am working on right now [14:56] infinity, if you switch the graphics for your VM to cirrus it'll likely stop it eating your machine [14:56] while i struggle to find out wtf is going on [14:56] diwic, saw your comment in the bug, shall I try that ppa with my current raring installation (nvidia) or booting raring from the pendrive? [14:56] rtg: Oh, you mentioned that the foo-udebs package blows up for you on lts-raring? I don't much care but, on the other hand, we tried to engineer it to work right for derivative kernels. What breaks? [14:57] infinity, I fixed it, no big deal. [14:57] apw: I'm not hitting it personally, I'm just being annoying about following up on what looks like a nasty bug. [14:57] rtg, what did you have to change [14:57] apw, added the flavours bit that is specific to saucy LTS [14:57] control info [14:57] oh yeah, i see what you mean [14:58] infinity, so he just had to configure it is all [14:58] Right, okay. I was worried that fixing it meant breaking it. ;) [14:58] gimme _some_ credit :) [14:59] rtg: I dunno. Do I have to? [15:10] apw: ok, booting into 3.10.0-5 I started amd and i386 vms for lucid and precise, all at once, all using cirrus [15:11] apw: I got to the login screen, logged in, started a browser, all fine [15:11] apw: I then shut those down, and started an amd64 saucy vm with vmvga, got to the login screen, logged in and bam [15:12] I don't think I always had to log in though [15:12] (maybe, not sure) [15:12] jdstrand, that sounds like waht i saw thanks [15:13] so somehow vmvga tickles this, now to try and work out how a userspace emulation is imploding the world [15:21] infinity: Broken how? [15:21] nessita, it does not matter. [15:22] -rw------- 1 adconrad adconrad 153262637 Jul 23 07:59 vmlinux-3.10.0-0-powerpc64-smp [15:22] -rw------- 1 adconrad adconrad 5148092 Jul 23 07:59 vmlinux-3.10.0-0-powerpc-e500 [15:22] -rw------- 1 adconrad adconrad 5160618 Jul 23 07:59 vmlinux-3.10.0-0-powerpc-e500mc [15:22] -rw------- 1 adconrad adconrad 113357254 Jul 23 08:00 vmlinux-3.10.0-0-powerpc-smp [15:22] BenC: ^-- The lack of stripping on two out of four flavours... [15:23] That's…very odd [15:23] diwic, ack! [15:28] infinity: I'll check into it [15:32] BenC: Many thanks. [15:44] infinity: how do I reproduce the environment in the buildds that causes it to build debug debs? [15:45] infinity: And are the modules stripped ok? [15:45] BenC, full_build=true to fdr binary-arch will ensure the ddebs are made, expect it to take a while though [15:46] BenC, if you are using an sbuilder then you can find where we set that in the source and just force it on [15:47] apw: Thanks [15:47] BenC: Can you think of a module that would be large enough to tell for sure? [15:47] du -sh /lib/modules/* [15:47] And see if there's a large descrepancy [15:47] file on them tells you if they are stirppedd or not [15:47] BenC: file(1) claims none of my modules are stripped, even for e500* [15:48] 131M /lib/modules/3.10.0-0-powerpc-e500mc [15:48] 123M /lib/modules/3.8.0-11-powerpc-e500mc [15:48] 123M /lib/modules/3.8.0-12-powerpc-e500mc [15:48] I suspect the modules are ok for e500mc [15:48] http://paste.ubuntu.com/5904539/ [15:48] At least they match up with raring [15:48] Random module pick. [15:49] So, I dunno. file(1) could be wrong, or module stripping might just be weird. [15:49] I don't think they would be fully stripped [15:49] Yeah, it could just be file being wrong. [15:49] There'd at least a debug link to the /usr/lib/debug blob [15:50] BenC: Anyhow, as you point out, the module sizes appear to match 3.8.x, ish. [15:50] infinity: My guess is that the ppc64/ppc-smp kernels show this problem because it is just a copy of vmlinux where as e500 kernels are the uImage (stripped/compressed/wrapped) [15:50] BenC: So, whatever's going wrong here, I imagine it's just the kernel images. [15:51] Probably need to add some machinery to strip these sorts of cases [15:51] BenC: I'm a bit curious as to how that only became necessary between 0.3 and 0.5 [15:51] apw: this will likely be something to pull back into master for debian/rules.d/ [15:51] BenC: Did we not always have massive debug kernels that needed stripping? [15:52] infinity: That's what I'm wondering [15:52] BenC: The new CONFIG_ option may have tickled this. [15:52] What is the config option? [15:52] CONFIG_DYNAMIC_DEBUG=y [15:52] And CONFIG_DEBUG_INFO [15:52] So, two of them. [15:53] debian.ppc/config/config.common.ubuntu:# CONFIG_DYNAMIC_DEBUG is not set [15:53] CONFIG_DEBUG_INFO is on [15:54] That's likely it [15:54] BenC, is that a change from 0.3 ? [15:55] rtg: Did this problem not happen in previous saucy linux-ppc kernels? [15:55] + [ Ubuntu: 3.10.0-2.11 ] [15:55] + [15:55] + * [Config] enforce CONFIG_DEBUG_INFO [15:55] BenC, rtg: This only showed up in -0.5, -0.3 was fine. And -0.5 includes the above rebase. [15:56] Ah, I remember having to enable that for the enforce [15:56] Had it disabled before [15:56] Problem identified [15:56] So, it's probably right to enforce that, *but*, only if we can sanely strip the kernel that lands in the pakcages. :P [15:56] Otherwise, dropping it for PPC for now seems a sane workaround. [16:08] yeah striping is normal during install i am supprised yours is not [16:10] infinity: I can safely get it to strip [16:11] BenC, i am somewhat supprised you have to get it stripped [16:11] as the install i am sure asks for that for the binaries, and not for the ddebs [16:11] apw: All of the other kernels that end up in .deb's are bzImage and similar, which get stripped before they are compressed [16:11] apw: ppc/ppc64 use the raw vmlinux, which doesn't [16:11] Yeah, but this should have been a problem for years, not suddenly today. [16:11] That's what I'm unsure about. [16:12] infinity: CONFIG_DEBUG_INFO wasn't enabled on ppc before this [16:12] I mean, yeah, more CONFIG_DEBUG stuff got turned on, but the kernels should have still been big and debuggy before. [16:12] BenC, good to know [16:12] BenC: Oh, that *was* enabled elsewhere before, but not enforced on PPC? [16:12] Right [16:13] Probably because nobody felt like dealing with it (maybe even me) [16:13] enforcement is new, because we lost it in master and that is bad for the ddebs [16:13] Well, it would have never been on on PPC, even when it was in master, then. [16:13] That's the bit I'm confused about. [16:14] hmm indeed, odd [16:14] apw: Is CONFIG_DEBUG_INFO actually arch-specific in precise? [16:14] The debian.master/config/enforce is what changed [16:14] BenC: Sure, but keep in mind powerpc wasn't always rebased source. I'm trying to sort out the root of this. [16:14] infinity: Most likely [16:14] If it really was arch-specific (perhaps due to this), that's a bit lolz. [16:15] BenC: Anyhow, I assume there's some canonical kernel way to strip that isn't just "strip vmlinux"? [16:16] infinity: I'm checking if there's maybe a "make STRIP=1 vmlinux or something like that [16:16] there must be a way [16:16] I nly see the MOD_STRIP business. [16:17] stupid thing [16:19] $(obj)/vmlinux.strip: vmlinux [16:19] $(STRIP) -s -R .comment $< -o $@ [16:24] yeah you might be able to switch [16:24] No idea if that's bootable, but that seems to be the object we'd want. [16:24] (I see no reason why it wouldn't be bootable, I just can't test right now) [16:24] BenC: ^ [16:25] BenC: So we want vmlinux.strip, not vmlinux, and a bit of movey-twiddling when installing it. [16:25] infinity: Ah, that's really easy to do then [16:25] (Which is fine, you have to rename it anyway to add version/abi/etc) [16:26] Doesn't require syncing a fix back to master [16:44] apw, drat. my SNB mount failure appears to be Ubuntu specific. vanilla 3.11-rc2 works OK. [16:56] ## [16:56] ## Kernel team meeting in 5 minutes [16:56] ## [17:06] * ppisati -> gym === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 13th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:34] * rtg -> lunch === fmasi is now known as fmasi_afk [19:38] does our mako kernel have USB on the go patches ? [19:39] xnox, all android kernels use the android gadget to be able to run adb [19:39] so USb is claimed by that atm [19:39] ogra_: ok, but that was not my question =) [19:40] well, we dont really offer a way to re-enable adb again if you disable it [19:40] stock mako kernel has on-the-go disabled and needs patches to be enabled, there are custom kernels available on $forums, but i'd like mine from a deb =))))) [19:40] and you cant reboot without cmdline ... so it would be useless [19:41] we'd need a UI switch to toggle adb, then you could use OTG [19:42] i assume we will want these patches in 14.04 for convergence though [20:32] * rtg -> EOD [22:05] Question... can I get 32bit ubuntu kernel booting with EFI? [22:05] I have an IA32, efi-only atom tablet that I'm having issue getting ubuntu installed on. I tried a method of installing to a usb-stick and using boot-repair to change it to EFI, but it's complaining about the kernel not being compatible. [22:17] infinity: Can yaboot use gzip compressed kernels? [22:20] infinity: Better yet, can I send you a deb to see if it works on your ppc64 and ppc32? === kentb is now known as kentb-out [22:46] F41l: As far as I'm aware, EFI-for-IA32 is blissfully unimplemented. [22:57] BenC: Not home in front of test hardware until August. :/ [22:57] BenC: I think it would be safe to assume the stripped vmlinux would boot fine, gzipped kernels would need a lot more testing, and not all ppc32 machines are yaboot. [22:58] infinity: Unfortunately, you can't "make vmlinux.strip" directly, and calling "make zImage" creates vmlinux.strip.gz [22:59] infinity: The compressed zImage is actually an executable, that would unzip itself [22:59] I just need to make sure it works [23:01] BenC: Sure, I realize what a zImage is and I realize that, in theory, it should Just Work from pretty much any bootloader, but I make no guarantees. One would think that if there were no problems with zImage on PPC, we'd have been using them all along, no? [23:01] BenC: And, at least on my 32-bit system, I fear for things like BootX and Quik sucking. :P [23:04] BenC: Right, so, load addresses are the issue. Any modern yaboot should probably be fine, ancient bootloaders (like mine) might not be. [23:04] BenC: You could just make vmlinux and strip it with the same arguments that vmlinux.strip uses as you install it to the deb? [23:05] infinity: Yes, but that requires me to mess with things in debian/rules.d/ and I was hoping to avoid that :) [23:07] BenC: Well, I'm willing to bet I won't be able to coax my ppc32 machine into booting a zImage, but happy to play next month when I get home. [23:07] BenC: I realize that machine (an ancient G3) is hardly a large or common use-case, but I see no reason to gratuitously break it either. [23:08] infinity: Very true [23:08] BenC: From what I can tell, though, yaboot should have supported zImage since 2001, ish. [23:09] BenC: We can, again, confirm that when I get home, but I'd see no reason we can't switch ppc64 to zImage if that's true, since the only ppc64 bootloaders we use (yaboot or grub2) would both work. [23:09] infinity: I'd be willing to bet the executable zImage will work even on your machines, but I'd have to make sure [23:09] infinity: I might post these images to debian-powerpc and see if people can test it [23:10] BenC: Well, as pointed out in the yaboot-supporting-zImage thread I found, the fundamental issue is that the bootloader needs to detect if the image is a zImage or vmlinux, cause they need to be loaded to a different address before jumping into them. [23:10] BenC: http://lists.debian.org/debian-powerpc/2001/09/msg00710.html [23:10] BenC: So, I'm willing to bet no one ever bothered to retrofit quik and bootx to do that, cause who cares. [23:12] BenC: Worse, benh hasn't touched bootx since 2000 or so, so I imagine it's bitrotted to the point where my trying to fix it would make me want to shoot myself. Or he may have even lost the source, I forget noew. [23:14] BenC: On the other hand, we don't support bootable media with anything but yaboot, so I could totally support zImage by default, and a bit of a hack to provide a linux-image-coff package that just has the vmlinux binary in it (and depends on the full linux-image) for schmucks like me. ;) [23:15] BenC: If we do some testing and discover that zImage works for everyone who isn't me, I may give you a patch to do that. [23:15] BenC: Cause smaller kernels for everyone who can use them sounds good. [23:15] infinity: How about this…I'll upload with zImage and we'll figure out the fallout from there :) [23:16] Worse case, we revert to stripped vmlinux [23:16] BenC: Sure. I suspect the fallout won't be all that interesting. The people in my position (stuck with ancient bootloaders) are probably few, far between, and all running Debian. [23:17] BenC: Oh, wait. [23:17] BenC: No, please don't. [23:17] BenC: We'll need a migration strategy too. [23:17] BenC: Cause that changes the names yaboot.conf needs to look for. [23:17] infinity: Well, if it "just works" what is there to migrate? [23:18] No, I left it as vmlinux (I don't really care about the name matching with x86 vmlinuz type things) [23:18] BenC: Oh, fair enough. If the naming doesn't change, it should Just Work, unless it doesn't. ;) [23:18] BenC: I'd test remotely right now, but I need that machine to not explode while I'm away. :/ [23:19] I'll expect a full report when you return home :) [23:19] Or at least silence if everything works with no harm done [23:19] BenC: Although, qemu-system-powerpc should emulate a yaboot-using type of machine. [23:20] I think qemu stuff boots linux directly [23:20] BenC: I'm pretty sure you'll hear from me about the ppc32 kernel. But we'll see. Maybe I'll get lucky. [23:21] Even on e500 qemu stuff it doesn't even emulate uBoot [23:23] Well, there's an openfirmware build specifically for qemu, which leads me to believe it *can* give you an early boot experience, if you so choose. [23:24] Admittedly, I've never used it, cause I have faster PPC hardware than I could possibly emulate on my x86 kit. [23:24] I'll toss it around in there and see what happens [23:24] BenC: openhackware - OpenFirmware emulator for PowerPC [23:25] BenC: Not installed as a dep of qemu by default, to keep the PPC cross-compiler and friends out of main, so you'll need to install it. [23:26] Oh, hrm. The package description claims it doesn't know forth, so maybe it just fakes it. [23:26] And yaboot is a forth OF application, isn't it? [23:26] So, nevermind. [23:26] Not a valid test. [23:26] yaboot is 32-bit native [23:26] Oh, is it? [23:26] only the bootX stuff is forth [23:26] It was quik that was forth. [23:27] I know the boot logo is in forth :) [23:27] BootX is a MacOS application. [23:27] Ah, right [23:27] yaboot is the same base code as silo [23:27] Neither of which is forth [23:27] Althought both call into open firmware routines in order to work [23:28] So maybe openhackware implements just enough for that [23:28] RAOF: "blissfully unimplemented", as in, not coded, or... do I need a module, something? [23:28] It's probably high time I spend a Saturday just switching PPC to grub2 and ditching yaboot anyway. [23:28] Not that this helps my poor beige G3 with its BootX woes. :P [23:29] F41l: Not coded, AFAIK [23:29] fek [23:29] infinity: I purchased an Apple //c last week from a thrift store…thinking of adding a 6502-a2c kernel some time soonish [23:29] how am I supposed to run 32bit 'buntu on an EFI-only system? [23:29] thought linux runs on friggin' everything! [23:29] BenC: Hah. Masochist. :) [23:29] F41l: why not run 64-bit? [23:29] Impossible with this system. [23:30] BenC: I assume it's a 32-bit-only Atom. [23:30] It's IA32 Atom [23:30] Intel's special way of saying they hate you. [23:30] F41l: Oh, I suspect it's not an EFI problem as much as a correct kernel problem [23:30] You said you got it to boot a kernel but it claimed it wasn't the right type of system [23:31] Not necessarily. [23:31] Atom requires special binary, right? [23:31] Like, it can't just run any old x86-32-bit kernel [23:31] I installed ubuntu on a USB drive (as the hard drive), and am trying to change that installation to use an EFI bootloader. [23:31] No, Atoms are just plain old i686 [23:32] But you need an EFI-happy kernel (and bootloader) if you have EFI-only firmware. We provide none of that on i386. [23:32] infinity: I thought the assembly was slightly different because of some ripped out functionality... [23:32] using the boot-repair-disk, I attempted to do this, but the software gave me an error akin to something that the kernel wasn't compatible. [23:32] Ah [23:32] F41l: As they say in my country…SoL [23:33] F41l: It's not wrong, our 32-bit kernels don't support EFI (and 32-bit EFI may be incomplete upstream too, haven't looked in a while), and we also don't provide a 32-bit grub-efi. [23:33] Seems kind of dumb to alienate an entire swath of systems from running ubuntu. [23:33] F41l: This isn't Ubuntu. Upstreams don't support 32-bit EFI either, or didn't last we checked. [23:33] F41l: I doubt it's an ubuntu problem [23:33] I can get elilo to boot, but need a kernel too [23:34] F41l: And to be fair, that "whole swath" is, like, three and a half computers. All 32-bit Atoms were legacy BIOS until very, very recently. [23:34] F41l: and to be fair the "swath" of Atom-EFI systems is more like a sliver [23:34] * BenC ^5's infinity [23:35] *surprised horror* you rather I run windows 8 [23:35] ! [23:35] they even made 64bit atoms that never got 64bit blob drivers (hello cedartrail with pvr graphics blobs) so needed the 32 bit efi crap to fix that fail. [23:35] F41l: Anyhow, this isn't something we're being intentionally obtuse about either. If the upstream support is there, we'll look at enabling EFI on i686 in Ubuntu too. [23:36] blegh [23:36] fucking clovertrail [23:36]