[00:46] Can the kernel that ships with Jaunty be replaced with a newer kernel? [00:47] I've read some about building a mainline kernel, but it also talks about mapping to a close match. [00:47] In my situation, there is a bug in the kernel, which is fixed in later versions. [00:49] I guess I would also like to know how upstream fixes like that eventually work their way into Ubuntu. [01:25] I just spoke with Anholt, one of the Intel graphics driver developers. He says the page allocation table (PAT) code in the kernel is a mess--there have been a ton of bugfixes, but there is indication that not all of them have been fixed even in the most recent version. This is preventing xorg from starting properly for those affected using the Intel graphics driver. [01:25] They think the best solution is just to disable PAT by default, using the "nopat" kernel option via GRUB. [01:26] My concern is that affected users are simply going to find that they aren't able to start xorg after upgrading to Jaunty. [01:49] The guys over on #intel-gfx are telling me that Jaunty disables PAT by default; but I am finding that, in my case, it is NOT disabled unless I manually add the "nopat" kernel option in GRUB. [13:33] apw: grub2 bricked my xps1710. [13:33] rtg how did it fail? [13:34] unrecognised device? [13:34] apw: fails at the chain command line. I'll get theerror message in a bit, but when you attempt to boot a selection it always says the same thing, something like 'Unidentified device string' [13:34] rtg yes thats a known issue [13:35] boot it to there, and edit the entry and change the word root to uuid [13:35] how helpful :) [13:35] i have a fix building for it now [13:35] known in the sense we found it acouple of hours ago, rather than known for a long time! [13:35] apw: I'm pretty sure I tried root --> uuid [13:35] hmm that should work, cirtainly worked here for me and cking [13:36] apw: well, its on a different floor in the mansion. I'll go back up there and mess with it while I make some coffee. [13:36] heh ok ... hope it is the same issue [13:37] * cking too [13:37] biab [13:38] cking, heres hoping. sounds too like what we both saw to not be ... [13:39] i have the full fix building in my PPA now [13:39] lemme know when it's cooked [13:39] waiting on a publisher run right now [13:45] cking, ok it should be there now ~apw3 [13:46] OK [13:46] installing on my crashy too [13:48] bugger its too clever [13:50] mm.. did not seem to work for me [13:50] hrm .. really [13:50] what didi it do? [13:50] was this a downgraded system of a virgin [13:51] hrm yes seems flawed... will recheck it [13:51] it was clean install [13:51] k, same result here... yet i tested it ... /me returns to the source [13:53] apw@dm$ /bin/bash foo "123-412121" [13:53] uuid [13:53] apw@dm$ /bin/bash foo "123412121" [13:53] uuid [13:53] apw@dm$ /bin/bash foo "(hd0,1)" [13:53] root [13:53] it is supposed to make the right choice! [13:55] whitespace perhaps? [13:55] perhaps ... am checking [13:55] i picked the check straight out of grub 1 ... so its a little confusing [13:57] ooooo, its got a #! /bin/bash on it, but if you test it with /bin/sh it doesn't work ... i wonder [13:58] apw: I managed to get the root --> uuid thingy correct, so it at least boots. [13:59] rtg excellent. sorting the converter script as we speak [13:59] are you following the testing page? [13:59] is there a grub2 menu.lst where I can make that change permanent? [13:59] you are in chainload mode (if you are seeing this) [14:00] so that is in the real grub one, in menu.lst [14:00] if you do the next step, switching to it completely [14:00] then its irrelevant [14:00] https://wiki.ubuntu.com/KernelTeam/Grub2Testing [14:01] I kind of think the buggy BIOS where grub2 won't work are very few and far between - and new users should be very rare to hit BIOS weirdness in the boot loader nowadays [14:02] as grub hasn't had to change for an age [14:04] for aeons [14:04] so any new bugs are compatible with old ones :) [14:04] when did we last see a BIOS bug where the bootloader failed? [14:04] they are all hotkeys, and fan control and things after boot [14:05] yep - but early bootloader issues are nuts'n'bolts BIOS flaws and that is rare (anyhow there is just as much voodoo in isolinux) [14:06] for sure [14:06] rtg can you put your results on the testing page for us [14:07] apw: yep, I just got distracted assembling my road show. gotta leave crack 'o dawn tomorrow [14:07] woh, nasty ... u carry on [14:31] umm, so installing grub2 removes the old grub, expected? [14:33] though it does leave the installed bootloader in place.. so, why yess! [14:37] tjaalton, its odd, it replaces your grub with a legacy grub of its own [14:38] also right now is bolloxes up your menu.lst [14:38] i've finally just fixed the transition script [14:38] uploading the fix to my ppa for those who want to test it ... [14:38] it did work here without modification [14:38] apw, will do [14:38] interesting [14:38] whatsup? [14:38] cking, i'll yell when its done building [14:39] cking, it worked for tjaalton unexpectedly [14:39] ? [14:39] oh he may have just told it to install [14:39] tjaalton, did you skip the chainload mode? [14:40] apw: no, it chainloaded from grub1 [14:40] ! [14:40] this was the version in karmi [14:40] c [14:40] and you didn't have to change the root -> uuid [14:40] no [14:40] karmic and jaunty are the same package [14:40] in which file would that be? [14:40] * cking is mystified [14:40] so do you have uuid or root specifiers in your menu.lst? [14:40] in each entry? [14:41] root=UUID=bleh [14:41] in /boot/grub/meu.list [14:41] the other one, the one in each entry [14:41] ah [14:41] root (hd0,5) [14:41] there is normally a 'uuid fooo' or 'root foo' in each entry [14:42] ok so that makes sense then, no idea why its not a uuid, but its not using uuid [14:42] so you would be fine [14:42] probably because it's an older installation [14:42] maybe since gutsy or hardy [14:42] that makes sense - upgrades don't get the UUID [14:42] yeah [14:42] yeah something like that. uuid wern't normal for grub itself [14:42] good understood [14:43] * cking is no longer mystified [14:43] tjaalton, are you following the test page, ie are you going to update the test page with your results (pretty please) [14:43] I'll try to boot vista (yeah..) [14:43] apw: sure [14:43] * cking crosses fingers [14:43] heheh [14:44] apw: I've got a 2.5GB USB flash based bootable full installation with grub2 for peeps to try out at UDS [14:44] oh it was xp, and works. then there's the factory vista installer [14:44] * cking cheers [14:45] Nice to know XP and Vista now work [14:45] I'll try that one too, just for the kicks [14:49] cking, ok this one tests ok locally built, the ppa is on the go. tested it both ways and things come out right for a change [14:49] * cking goes and checks [14:49] the ppa will take a few more minutes to complete ... ~apw5 is the working version [14:50] hmm, no 'update-from-grub-legacy' here [14:50] argh [14:50] *upgrade [14:51] ok, done [14:51] yeah its very confusing [14:57] takes a while for it to be published ... [14:57] yeah it sure does. the publisher runs on a half hour [14:57] cycle or something [14:57] ppa publisher is 0, 20 and 40 minutes past the hour [14:58] not far off then :) [14:59] i like the fact it tells you its not published now, thats new [14:59] and that it now show you which are published with the green tick [14:59] ie those which are not published yet are there [15:02] cking, its published, and ready to test [15:03] looking good here [15:03] looks good to me [15:04] sweet [15:04] * apw goes get it uploaded [15:05] apw: your ppa? [15:05] yeah its in my ppa ~apw5 version [15:05] * apw goes jump hoop [15:09] apw, good work! [17:24] Hi, all! I'm trying to understand why my kernel.org (non ubuntu, non modular) kernel won't boot on jaunty. [17:24] It worked fine on hardy and intrepid, but on jaunty it panics, "VFS: Unable to mount root fs on unknown-block(0,0)" [17:25] apw: can you assist akk pls? [17:25] hello [17:25] I'm using UUID= everywhere so I don't think it's a libata vs. old ide problem. [17:25] hmmm ... well i would try using root=/dev/sdxxx sort of boot to confirm its not a uuid issue [17:26] but in general that is done in initramfs, so your kernel shouldn't be an issue for that i'd think [17:26] I've tried root=/dev/sdaX and root=/dev/hdaX both [17:27] what kernel config did you use to build you kernel [17:27] apw: akk build a custom upstream kernel [17:28] akk: initramfs creation prob? [17:28] No initrd [17:28] non modular kernel, it's never needed an initrd [17:28] if its non-initrd, you won't have any support for UUID period [17:28] as that is done in userspace in ithe initrd [17:29] if its panicing then that implies you don't have the driver for your disk controller enabled [17:29] interesting! I could have sworn I'd done that before. [17:29] (if its panicing with the /dev/sdXN or hdXN specifiers) [17:30] i would boot the regular kernel and see which driver reports as finding the disks [17:30] and track that back to ensure its enabled in your config [17:30] That's in dmesg? [17:30] should be around where it find those disks [17:32] With the jaunty kernel, "Driver 'sd' needs updating - please use bus_type methods" [17:32] yeah normal [17:33] then a lot of confusing messages about sata (which I don't think this board has) and ata. It does mention scsi2: pata_via, scsi3: pata_via [17:33] are those what I'm looking for? [17:33] (it is a via chipset) [17:33] akk very likely, you could push the whole dmesg to a pastebin, and we could check [17:34] http://shallowsky.com/tmp/dmesg.out [17:34] brb, changing irc machines so I can do boot tests [17:36] akk, yeah you seem to be using pata_via and sata_via, so you need to make sure they are enabled [17:38] This same kernel was working under intrepid, so I figured I had all the right drivers [17:38] but I'm checking that [17:38] the exact same kernel or the same .config [17:39] exact same kernel [17:39] hmmm [17:39] same file in the shared /boot partition [17:39] well that is mytifying as the kernel is loaded in the same way, and from the same bootloader [17:39] and the kernel doesn't even know its loading the jaunty userspace as it cannot mount it to find out [17:40] so its not at all obvious how the kernel can work under intrepid [17:40] are you saying if you put the root spec for the intrepid userspace on this machine it loads? [17:40] in the same entry? [17:40] are both the intrepid and jaunty userspace on the same drive? [17:40] That's a good point. Let me double-check my menu.lst entries and make sure they're really identical. [17:41] Same drive, different partitions. [17:43] ah, actually if the menu.lst entries are the same, the error is different [17:43] it gets a little past mounting the root and hangs after loading the usb devices [17:43] how can that be [17:43] can you paste bin them both please [17:43] the entries [17:43] sure, just a sec ... [17:44] btw, "setting the system clock" is the next step (after where it hangs) if I boot into intrepid [17:44] blah, it decided to fsck this time so it'll be a little while before it's back up [17:44] hit escape? [17:46] escape doesn't stop it [17:46] hmm, odd. normally does for me [17:46] nor does ^C [17:47] 12% [17:47] I keep meaning to put these fscks onto some sort of user warning so I can run them manually and they can't hold me hostage at boot time. [17:48] on all my systems using usplash you can hit esc, and they do it next time [17:48] ah, I like seeing the boot messages so I'm not using usplash [17:49] a downside is you can't stop the fsck it seems [17:49] yep! [17:49] I didn't know usplash did that [17:49] the other trick is to reboot with the power out which prevents it occuring [17:50] With which power out? [17:50] the power cord, if it has a batter of course [17:50] oh, cool! It doesn't fsck on battery? [17:51] (This is a desktop, so I don't have that option, but that's great to know for the laptop) [17:51] nope puts it off to next time, if its a '30 boot is enough' type check [17:51] yeah, this is a 29 times check [17:52] I've been superstitious about booting on battery power, because some past ubuntu version set performance to low for the duration of the session when I did that. [17:52] Probably with laptop-mode and so forth, that's no longer a problem and I should try it again. [17:52] you could just edit your fstab and then you will never get an fschk on boot [17:53] jjohansen: That's what I've been meaning to do -- but only after I put a check and warning somewhere else, otherwise I might forget to ever do it. [17:54] I've heard assertions that really there's no point in fsck'ing ext3 anyway and it's safe to go without, but I'm not sure whether to believe it. [17:55] yay, done. Now what was I checking? :) oh yeah, pasting the menu.lst lines [17:57] http://shallowsky.com/tmp/grublines.txt [17:59] oh, the static /dev is screwed up on that jaunty partition, so I am indeed doing something stupid [18:00] yeah, that was it [18:00] it boots with root=hda5 ... so my problem was not realizing that root=UUID= required an initrd. [18:05] Thanks for the help! [18:08] akk you are welcome [19:37] any chance to get this fixed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/277749 [20:19] DGMurdockIII: you didn't provide the info that Chris requested yet?