| mateen_maldar | hi all , i builded the kernel on ubuntu but it gives error modules.dep not found while booting the kernel that i built | 06:40 |
|---|---|---|
| mateen_maldar | can anyone here tell me how to resolve this issue | 06:43 |
| andersk | What's the reason you built your own kernel? That is almost never necessary. | 06:44 |
| andersk | But you might start by checking the documentation at https://help.ubuntu.com/community/Kernel/Compile | 06:45 |
| mateen_maldar | andresk: i want to make modification to 2.6.27.7 version that's why i compiled the kernel | 06:48 |
| === asac_ is now known as asac | ||
| rlj | hi all! a quick style question: i'm preparing a trivial patch to add a keyboard quirk (actually, i posted it to the list in november but got no feedback, so reposting now), but there's since been a similar patch added for another computer which adds a function atkbd_inventec_keymap_fixup which is identical to my proposed atkbd_hp_zv6100_keymap_fixup function. | 12:31 |
| rlj | in my reposting now, would the preferred way be to: 1) add a #define atkbd_hp_zv6100_keymap_fixup atkbd_inventec_keymap_fixup or 2) duplicate both functions in case they would diverge later on or 3) rename the function and share between both quirk code paths? (the functions are all callbacks called when dmi matches are found) | 12:32 |
| mjg59 | rlj: 3 | 12:33 |
| rlj | thanks | 12:33 |
| cjwatson | cking: have you forwarded your ext4 patch to the Debian BTS so that their grub maintainers pick it up? It'd make it easier for me to get installer work done (there's a fair bit of translation involved so it's best done in Debian where possible) | 13:59 |
| cking | cjwatson: I have not yet forwarded this (yet). | 14:01 |
| * pgraner notices cking is having problems forming coherent English sentences today... | 14:02 | |
| cking | However Tim uploaded this yesterday https://bugs.launchpad.net/ubuntu/+source/grub/+bug/314350/comments/3 | 14:03 |
| ubot3 | Malone bug 314350 in grub "Grub: Add support for ext4" [Wishlist,Fix released] | 14:03 |
| cking | cjwatson: ^^^ | 14:04 |
| cjwatson | cking: yeah, I saw that, I just wanted there to be a record of it in Debian as well so that I can say "hey, there's a bug for it" when other Debian d-i developers ask me how this ext4 stuff is supposed to boot then | 14:06 |
| cking | cjwatson: Should I just create a Debian bug report and reference the patch - even if the patch may not apply cleanly to the Debian grub? | 14:11 |
| cjwatson | cking: it's a good start | 14:14 |
| cjwatson | I don't see an existing bug for it | 14:16 |
| cking | Will do | 14:17 |
| cjwatson | looks like Debian grub2 already supports it as well but I have no idea whether it's ready to go | 14:17 |
| cjwatson | http://paste.ubuntu.com/101668/ <- basic untested installer support | 14:18 |
| cking | cjwatson: looks reasonably sane to me at a glance | 14:21 |
| cjwatson | I wonder whether libparted will explode or merely fall over gracefully | 14:22 |
| cking | hopefully the latter | 14:30 |
| * apw wonders how advanced the grub2 work is. | 15:01 | |
| apw | did we bottom out on when we might offer it as an option | 15:01 |
| tjaalton | IIRC it was meant to be offered as an option in jaunty, and revisit the default bootloader again for jaunty+1 | 15:06 |
| tjaalton | I'm interested in testing it on my preseeded installations | 15:07 |
| apw | cjwatson, are we doing anything with grub2 for jaunty? | 15:09 |
| apw | (installer wise) | 15:09 |
| cjwatson | apw: it's on the foundations roadmap but at low-priority, so not sure yet | 15:09 |
| apw | fair enough, if it is on someones map it is at least not forgottten | 15:10 |
| Ng | out of interest, which alsa and e1000e versions are in jaunty? | 16:49 |
| TheMuso | Ng: alsa 1.0.18rc3 is the version, but there are some commits from 1.0.18 final. | 17:15 |
| Ng | Tnice, that's the answer I wanted :0 | 17:16 |
| Ng | hopefully it has a new enough e1000e to support a 82567LF-2 | 17:17 |
| rtg | Ng: whats is the PCI ID? | 17:28 |
| Ng | rtg: unknown, I've not bought the hardware yet, it's an Intel DG45ID motherboard | 17:28 |
| rtg | Ng: drivers/net/e1000e/ich8lan.c: * 82567LF-2 Gigabit Network Connection | 17:29 |
| Ng | hmm, I see people saying they've had to compile a newer e1000e driver than is intrepid, so maybe it's a weird variant | 17:30 |
| rtg | Ng: this is Jaunty | 17:30 |
| Ng | rtg: ah, any idea which version of the driver it is though? | 17:31 |
| rtg | Ng: drivers/net/e1000e/netdev.c:#define DRV_VERSION "0.3.3.3-k6" | 17:32 |
| Ng | k, thanks | 17:32 |
| NCommander | rtg, if you have no objections, I'd like to merge in the patch from cjwatson after testing it so we can get d-i working for ARM | 18:06 |
| rtg | the grub recommends patch? | 18:06 |
| cjwatson | no, https://lists.ubuntu.com/archives/kernel-team/2009-January/004042.html, just a few minutes ago | 18:07 |
| NCommander | Oh, cjwatson's here :-) | 18:07 |
| rtg | NCommander: never mind, just read the list | 18:07 |
| cjwatson | grub recommends was from apw | 18:07 |
| cjwatson | apw: I don't think lilo and grub should conflict - the kernel's postinst has special stuff to run only one bootloader installer | 18:09 |
| cjwatson | it's not just whichever one was installed last or whatever | 18:09 |
| rtg | NCommander: done | 18:09 |
| mjg59 | And lilo's useful even if you're using grub to boot | 18:09 |
| cjwatson | apw: you might want to have both installed simultaneously while switching from one to the other (typically a delicate operation so you don't want the packages to refuse to install at the same time, making it harder for you to revert if stuff goes wrong) | 18:09 |
| NCommander | rtg, I'll test it here. | 18:09 |
| rtg | mjg59: right, sometimes you use LILO for other devices. | 18:10 |
| cjwatson | grub's postinst definitely doesn't overwrite the MBR and I don't think lilo's does either, generally | 18:11 |
| apw | cjwatson, i was intending on saying the same thing, moving from one to the other might require both for safety | 18:14 |
| rtg | apw: so, what is Hobsee complaining about? Does it bork the upgrade? | 18:15 |
| apw | smb_tp, sru justification is in the bug, and pushed | 18:15 |
| apw | rtg i think there may be no reall effect other than scaring people cause it installled lilo | 18:15 |
| apw | i think all of the changes make sense overall | 18:15 |
| apw | as having both is generally not what is wanted unless it is specifically requested | 18:16 |
| rtg | what does the recommends order have to do with it if there is no net affect? | 18:16 |
| rtg | deleterious affect, I mean | 18:16 |
| apw | that is why all of the changes are only targeted at jaunty | 18:16 |
| apw | i believe this is interesting only because we now install 'recommends' as part of an update by default | 18:17 |
| apw | and if neither is there, then the first of the | will be chosen | 18:17 |
| apw | and we primarily want grub, so mostly would have to swap it without the change, rather than only on wanting lilo | 18:18 |
| apw | cjwatson, about right? | 18:18 |
| rtg | apw: that not how I understand recommends. regardless of order, both packages get installed. | 18:18 |
| apw | then we need to get cjwatson's input here | 18:18 |
| rtg | apw: according to hobsee's bug report, that is exactly what is happening. | 18:24 |
| apw | well cjwatson's description i think says we install lilo cause of the depends, then the installer installs grub cause we are going to use it, and can't remove lilo cause its needed by the depends on the kernel | 18:24 |
| apw | i agree if both get installed as deps regardless of the | then yes the change seems pointless | 18:25 |
| rtg | in that case there is little difference between recommends and depends. | 18:26 |
| apw | with 'install recommends' turned on its not at all clear that they are differnet really | 18:26 |
| apw | in effect, other than being able to --no-install-recommends | 18:26 |
| cjwatson | rtg: it's a recommends: lilo | grub | 18:27 |
| cjwatson | that means "one or the other" | 18:27 |
| rtg | cjwatson: but that is not what the bug is reporting. grub is already installed, but then lilo is sucked in. | 18:28 |
| cjwatson | rtg: the order only had anything to do with it due to a ubiquity bug, and it's not *necessary* to fix the order to fix this bug; however, saying that grub is the preferred alternative seems to make sense these days | 18:28 |
| cjwatson | rtg: grub is installed for a different reason | 18:28 |
| cjwatson | ubiquity *explicitly* installs grub, completely independent of the kernel recommends | 18:28 |
| apw | rtg, no that was an error in the report. it was already installed in intrepid before the update | 18:28 |
| apw | what she saw was it being upgraded as the jaunty version is newer | 18:28 |
| cjwatson | lilo is sucked in due to the recommends, although ubiquity should have removed it (but didn't) | 18:28 |
| apw | not installed for the first time | 18:28 |
| cjwatson | if it were "recommends: lilo, grub" then *that* would install both | 18:29 |
| apw | cjwatson, i am correct in saying that we confirmed that the lilo was installed in intrepid before the upgrade to jaunty, from her log files | 18:29 |
| rtg | ok, so recommends _does_ behave in a logical way. | 18:29 |
| cjwatson | let's be clear though, swapping the recommends alternative order is not really to fix the bug that Sarah saw; it's simply because it makes more sense that way | 18:29 |
| cjwatson | apw: yes (well, not directly from her log files, I went round and confirmed the bug elsewhere - essentially code inspection) | 18:30 |
| apw | i think with the change we will have to remove lilo less often when it wasn't needed rigth | 18:30 |
| cjwatson | yes | 18:30 |
| apw | as basically we get one or the other, and must switch it if we were wrong in d-i | 18:30 |
| rtg | cjwatson: if neither recommends package is installed, will it then pick the first one? | 18:30 |
| cjwatson | rtg: one reason why people are suddenly complaining now is that lilo was fixed to deal with large kernel/initramfs combinations, but that fix breaks old BIOSes, so it asks a debconf question on upgrade | 18:31 |
| cjwatson | which rather surprises people who didn't know they had lilo installed in the first place | 18:31 |
| cjwatson | rtg: yes, it will | 18:31 |
| rtg | ok, now I think I understand. | 18:31 |
| cjwatson | apw: scrolling back, you said "can't remove lilo cause its needed by the depends on the kernel" - actually not, we're perfectly able to remove it since it's only a recommends, we just weren't even trying | 18:32 |
| apw | ok... | 18:32 |
| cjwatson | and that's the difference between recommends and depends | 18:32 |
| cjwatson | with recommends, you can say "no, you fool, I don't want this" and that will be respected. If you try that with depends then the packaging system will whine at you for the rest of your natural life | 18:32 |
| rtg | apw: ack'd | 18:33 |
| apw | so the short form is ... we install the first one on the Recommends: line, we then work out if we need a different one and if so install it, we then _should_ remove the one we don't need which we don't | 18:33 |
| cjwatson | I'm sure there's a truly ancient bug report about the recommends ordering | 18:33 |
| Nafallo | hhaaha | 18:33 |
| cjwatson | apw: right | 18:33 |
| Nafallo | cjwatson: nice! :-) | 18:33 |
| apw | thanks ... | 18:34 |
| NCommander | rtg, I've kicked off a test build with cjwatson's change to make sure all the udebs will get properly built | 18:34 |
| cjwatson | cf. bug 43531 for background on why the kernel recommends a boot loader, although be rather careful about taking action on that report as the interactions (as we discovered today) are REALLY subtle | 18:36 |
| ubot3 | Malone bug 43531 in linux "Kernel isn't very useful without a boot loader, but doesn't depend on one" [Medium,In progress] https://launchpad.net/bugs/43531 | 18:36 |
| apw | i have updated hobsee's bug to include the a NOTE that the problem is subtly different to how it was reported | 18:37 |
| NCommander | rtg, I have to ask, does CONCERNECY_LEVEL actually work correctly? It's behaving a little ... strange | 18:38 |
| rtg | NCommander: it only works when its spelled right | 18:39 |
| NCommander | rtg, :-P | 18:39 |
| rtg | NCommander: if not specified, its -j(NR_CPU*2) | 18:40 |
| NCommander | Well, I'm building from my ARM board, but I want to offload via distcc to the PC | 18:41 |
| NCommander | I'm getting hits in the distccd.log, so it seems to be working | 18:41 |
| rtg | are you using .intrepid-env ? (should be .jaunty-env) | 18:42 |
| NCommander | I just ran dpkg-buildpackage with the correct environmental variables exported | 18:42 |
| rtg | NCommander: you can do that to, I'm just lazy. | 18:43 |
| rtg | though, to be honest, I haven't used distcc in awhile. | 18:44 |
| * NCommander has been dependent on distcc to build KDE on his NSLU2 ... | 18:44 | |
| rtg | I have this monster dual quad core that is quite swift. | 18:45 |
| NCommander | Offloading ARM builds to the x86_64 makes them palletable | 18:45 |
| NCommander | it would be too slow any other way | 18:45 |
| apw | NCommander, does that mean we could have a crosscompiler based buildd? | 18:49 |
| NCommander | apw, we do/did that for m68k for ages | 18:50 |
| NCommander | apw, you still need your host architecture thing for things that can't be cross-compiled obviously, but considering I got my NSLU2 to build KDE in the same time it took the buildds .... | 18:51 |
| apw | would that mean we could ahve arm builds in ppa's | 18:51 |
| NCommander | apw, er, not quite, because you still need an ARM host | 18:51 |
| apw | ah yes | 18:51 |
| NCommander | apw, that being said, maybe we could convince IS to put QEMU in a XEN instance, and then the cross-compilers in it | 18:52 |
| apw | rtg, are we planniing on another kernel upload before alpha3 ? | 18:55 |
| rtg | apw: yep - I hope to include Ben's work regarding ACPI suspend. | 18:55 |
| apw | cool. thanks | 18:57 |
| rtg | NCommander: what is the console baud rate on this board? | 18:57 |
| NCommander | 115200 | 18:58 |
| NCommander | That should get you to the redboot prompt (if it starts trying to find bootp info, hit Ctrl-C to kill it and it will fall back to local booting) | 18:58 |
| rtg | that's a ridiculously high baud rate. | 19:00 |
| cjwatson | NCommander: generally we've been very reticent to rely on cross-compilers for buildds; the human effort required to babysit them generally seems to exceed the machine time you save | 19:00 |
| cjwatson | (factoring in the extra cost of human attention) | 19:00 |
| cjwatson | oh, geez, am I going to need a serial console when I get one of these board? | 19:00 |
| cjwatson | s | 19:00 |
| cjwatson | I was kind of hoping for VGA out | 19:00 |
| NCommander | cjwatson, yeah | 19:00 |
| NCommander | cjwatson, there is one | 19:00 |
| NCommander | cjwatson, but at the moment, its not quite usable | 19:00 |
| cjwatson | (and keyboard in, obviously ...) | 19:01 |
| NCommander | cjwatson, its got USB ports | 19:01 |
| cjwatson | guess I'd better find a serial cable for the moment | 19:01 |
| NCommander | cjwatson, I bought a 20 dollar USB/Serial null modem cable | 19:01 |
| rtg | ARM cross compiling is pretty well tested ' | 19:02 |
| rtg | 'cause its the only way you could do it. | 19:02 |
| cjwatson | not for most packages in the archive | 19:03 |
| cjwatson | for the kernel, maybe | 19:03 |
| cjwatson | there is a large swathe of packages in the archive that simply won't cross-compile sanely | 19:04 |
| cjwatson | and nobody has particularly cared about getting them going on arm; but it matters for us since we're building the whole archive | 19:04 |
| cjwatson | allocating lots of human attention to making them cross-compile versus just throwing more hardware at the problem isn't really such a good use of resources as it seems on the face of it, IMO | 19:04 |
| cjwatson | and we've already got over the initial hump of building the whole archive for armel, so it'd be silly to change now | 19:05 |
| rtg | oh, I wasn't advocating that. | 19:06 |
| apw | i was only interested in those options for ppa stuff which needs a 'protected environment' | 19:06 |
| cjwatson | yeah, the lack of ppa is awkward | 19:06 |
| cjwatson | rtg: what would be the best feature to test for when asking the question "is this filesystem ext4", do you think? | 19:07 |
| cjwatson | I was going to go with extents, but that's an EXT3_ symbol (although it doesn't seem to be supported by fs/ext3/ in the kernel so maybe it's ok) | 19:07 |
| rtg | cjwatson: inode size | 19:08 |
| cjwatson | rtg: hmm, that doesn't seem to be one of the feature bits though? | 19:11 |
| cjwatson | rtg: or do you mean EXT4_FEATURE_INCOMPAT_64BIT or EXT2_FEATURE_INCOMPAT_META_BG or something? | 19:11 |
| rtg | cjwatson: what are you looking at? something already on the disk? | 19:12 |
| cjwatson | hmm, or maybe EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE or EXT4_FEATURE_RO_COMPAT_HUGE_FILE | 19:12 |
| cjwatson | rtg: yeah, I'm looking for a feature flag I can test in libparted to return the proper filesystem type | 19:13 |
| cjwatson | like, for ext3 it tests for EXT3_FEATURE_COMPAT_HAS_JOURNAL | 19:13 |
| cjwatson | which is a pretty obvious "this is ext3" marker | 19:13 |
| cjwatson | it's in libparted's probe code | 19:14 |
| rtg | I think EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE is exclusive to an ext4v file system. The inode size is 256 as opposed to ext3 128. | 19:14 |
| cjwatson | we actually create ext3 with inode size 256 nowadays | 19:15 |
| cjwatson | but I can buy extra_isize, that appears to be a feature we don't turn on for ext3 according to /etc/mke2fs.conf | 19:15 |
| cjwatson | cool, thanks | 19:15 |
| andersk | I think EXT4_FEATURE_INCOMPAT_EXTENTS is the important one. | 19:15 |
| rtg | cjwatson: yeah, how about one of the incompatible flags? | 19:16 |
| cjwatson | ok, fine by me | 19:16 |
| cjwatson | I just wasn't sure what ext4 people considered to be the important thing about ext4 | 19:17 |
| rtg | I'm a little confused about your goal. Is it to determine how to detect and mount the file system? | 19:17 |
| andersk | http://ext4.wiki.kernel.org/index.php/Ext4_Howto says that turning on the extents feature is how you convert an ext3 filesystem to ext4. | 19:17 |
| cjwatson | gotcha | 19:18 |
| cjwatson | rtg: basically yes. libparted determines how the filesystem will show up in the installer's partitioner | 19:19 |
| rtg | ok, so you're looking for a bit that says it can _only_ be ext4. | 19:19 |
| cjwatson | I'm going to have mkfs.ext4 do the actual hard work, but I need some minimal support otherwise the partitioner falls over entirely when dealing with ext4 filesystems | 19:19 |
| cjwatson | right | 19:19 |
| TheMuso | 1/c -all | 20:26 |
| TheMuso | gah | 20:26 |
| rtg | NCommander: i hate RS/232 | 20:36 |
| NCommander | rtg, redboot does know how to work over telnet | 20:36 |
| NCommander | (although I'm not quite sure it works on this board) | 20:37 |
| rtg | its booting and requesting DHCP, just can't get the console | 20:37 |
| NCommander | rtg, push ctrl-C during DHCP to cancel that, and then push it again to get to the RedBoot prompt | 20:37 |
| NCommander | rtg, are you using minicom? | 20:38 |
| rtg | I mean, I cannot get anything out of the console. wrong NULL modem | 20:38 |
| lure | anybody here know how to fix lvm root after today's udev package? I am left in BusyBox with no clue... | 21:29 |
| jbarnes | ugg has anyone fixed install-kernel yet? | 23:26 |
| jbarnes | err /sbin/installkernel | 23:27 |
| jbarnes | looks like /sbin/installkernel is just missing a call to do the mkinitramfs -o /boot/initrd.img-${ver} ${ver} | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!