=== bjf[afk] is now known as bjf === bjf is now known as bjf[afk] === kblin_ is now known as kblin === hrw|gone is now known as hrw === dyfet` is now known as dyfet === ericm_ is now known as ericm|ubuntu [09:12] lool, merci :) === dyfet is now known as dyfet_sleeping === amitk is now known as amitk-afk === zyga_ is now known as zyga === amitk-afk is now known as amitk === fta_ is now known as fta [13:00] ogra: Why is my file system becoming fried when I install my own kernel on OMAP3 daily build? [13:00] no idea, must be a kernel bug :P [13:00] fsck from util-linux-ng 2.17.2 [13:00] /dev/mmcblk0p2: The filesystem size (according to the superblock) is 533515 blocks [13:00] The physical size of the device is 532153 blocks [13:00] Either the superblock or the partition table is likely to be corrupt! [13:00] which filesystem exactly ? [13:00] Don't be silly [13:00] ah, not the vfat [13:00] Nope [13:01] is that after or before installation ? [13:01] i.e. after or before the autoreboot [13:01] I dd, mount, put on my initrd-uimage-boot.scr, umount, boot [13:02] I'll get you the full log [13:02] you shouldnt have an fsck at all at that stage [13:02] i dont get why you (or lool) even get one [13:02] * lag *shrugs* [13:03] the fsck should only happen after the partition table was newly written and the automatic reboot happened [13:03] It's your toy, you tell me [13:03] until the reboot there is no fsck at all [13:03] Clearly there is [13:03] I didn't know it was happening to lool too [13:03] did it even reboot ? [13:04] AFAIK it happens on first boot [13:04] right, i hear you, *did it reboot at some point* [13:04] first boot? you have 'fixrtc' set right in your bootargs? [13:04] rcn-ee, isnt needed on first boot anymore [13:05] only on subsequent ones [13:05] http://paste.ubuntu.com/482869/ [13:05] That's my boot.scr [13:05] if it gets to an fsck before rebooting, then something with the reboot is wrong [13:06] which in tunr points to either a busybox or kernel bug [13:06] anyreason for no 'ro' in that? or isn't that needed anymore either? [13:06] rcn-ee, it gets changed after first reboot [13:06] jasper rewrites the kernel cmdline [13:08] So there's nothing wrong with my boot.scr? [13:08] jasper does: kick in in initramfs *before* anything gets mounted, then repartitions according to teh SD size, reformats the vfat completely, grows the rootfs to full size, touches the last mouted stamp on the FS, mounts it, does some setup and then reboots into oem-config [13:09] *before* oem-config runs, the system does its first fsck [13:09] http://paste.ubuntu.com/482871/ [13:09] ah, cool.. [13:10] ogra: Where does Jasper get it's kernel from? [13:10] from the vfat [13:10] "reformats the vfat completely" [13:10] right for that part it pulls it from /boot [13:11] So if I want to test another kernel, I have to put it in there too? [13:11] the booting kernel is the uImage, the kernel after first reboot is a new uImage from /boot [13:11] yeah [13:11] Great! [13:11] but your initrd seems strange in that log [13:11] It's one I built [13:11] aha [13:12] What's wrong with it? [13:12] its missing jasper completely [13:12] Ahhhhhhhhhh [13:12] you should see a lot of jasper messages after line 260 [13:12] ogra: is omap4 in good state? [13:12] You certainly know how to make my job difficult don't you? [13:12] the first part of jasper is a local-premount script and is still very niosy [13:12] asac, no [13:12] asac, nothing is in a good state atm [13:12] would anyone of you be able to test an image if we produced one at some point for us? [13:13] just headless -> on sd ... booting -> done ;) [13:13] not now ... in a few days [13:13] telepathy-glib prevents image buiolding currently and oem-config is broken (upload pending) [13:13] we dont have omap4 atm :(( [13:13] asac: Yes [13:13] asac, sure, no prob, just ping me with an url once you have iot [13:13] good stuff ... [13:13] ogra: could you give me the mkimage paramaters ;)? [13:14] parameters ... damn my fingers never get it right [13:15] ogra: What am I going to do about this? Is it just a matter of installing Jasper? Or are there other hidden nasties that you've implemented? [13:15] asac, they are the same as for omap3 [13:15] ogra: and if possible a good boot cmdline ;) [13:16] ok good for the uimage [13:16] lag, have a chroot with jasper in it and run update-initramfs there [13:16] mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu Kernel" -d "$uboot_input_kernel" "$uboot_kernel" [13:16] mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n "Ubuntu Initrd" -d "$uboot_input_initrd" "$uboot_initrd" [13:16] from the debian-cd script [13:16] asac, ^^^ [13:17] asac, and see lag's paste above for a boot.scr [13:17] oh, wait, thats omap3 [13:17] ogra: ok found it [13:18] oh [13:18] ;) [13:18] looked really too similar ;) [13:19] asac, http://paste.ubuntu.com/482874/ [13:19] thats better [13:19] ogra: How do you install Jasper? [13:19] uboot_kernel_addr="0x80000000" [13:19] uboot_ramdisk_addr="0x81600000" [13:19] lag, apt-get install jasper in the chroot you use [13:20] board_opts="mem=463M" [13:20] ? [13:20] yeah, needed [13:20] thanks [13:20] Tried that [13:20] E: Unable to locate package jasper === fta_ is now known as fta [13:20] lag, its in main [13:20] lag, only in maverick though [13:24] * lag had an empty sources.list file [13:25] Err http://uk.archive.ubuntu.com maverick/main armel Packages [13:25] 404 Not Found [IP: 194.169.254.10 80] [13:25] Doh [13:25] ogra: I told you that size of the fs issue would bite you in real life!! [13:26] lool, no, it wouldnt if jasper would be executed [13:26] lool, you didnt by chance keep a log from your broken boot test, did you ? [13:28] ogra: Why isn't it finding the armel packages? [13:28] http://194.169.254.10/ubuntu/dists/maverick/main [13:28] ? [13:29] lool, the point is that the initial rootfs is never used or touched, the whole thing gets adjusted before any fsclk, mount or other filesystem operations happen, while the corruption is ugly it *must* be gone after jasper has run [13:29] so it shouldnt affect anyone unless jasper doesnt run [13:29] lag, you want pool [13:30] ? [13:31] Instead of dists? [13:31] ogra: I suspect resize2fs is running fsck or some equivalent [13:31] ogra: I don't think it's the boot triggering fsck [13:31] ogra: I'm not sure it's clear, but the issue seeems to indicate a corrupted to start with!! [13:33] ogra: [13:33] deb http://uk.archive.ubuntu.com/ubuntu/ maverick main restricted universe multiverse [13:33] deb-src http://uk.archive.ubuntu.com/ubuntu/ maverick main restricted universe multiverse [13:33] lool, jasper runs an fsck thats fully redirected to the logfile *right after* the new partitions were written [13:33] lool, there is no way that you see *any* error message from that if jasper ran successfully ... and *after* jasper ran there shouldnt be any corruption anymore [13:34] my point is that the corruption will not affect the actually installed filesystem [13:34] i ageree that it needs to be fixed, but of the setup worked right you will never ever be able to even get any info about that corruption apart from jasper.log [13:35] ogra: Are those sources.list entries correct? [13:35] if you *see* an fsck during boot, something went completely wrong (i.e. jasper wasnt executed, you didnt use a 4G SD card etc) [13:35] lag, no, needs to be ports.ubuntu.com [13:35] k thanks [13:35] the ports archive isnt mirrored [13:36] lag, s|uk.archive.ubuntu.com/ubuntu|ports.ubuntu.com/ubuntu-ports| [13:36] oh, right [13:36] i missed /ubuntu-ports [13:36] Rather, nobody has yet announced a public URL with a mirror. There exist some number of mirrors that aren't announced (I know of at least 4, but none better for the UK than ports.ubuntu.com) [13:37] * ogra knows one [13:37] but i guess there is a reason thats not announced anywhere [13:38] ogra: It's in your house? [13:38] I can't speak for anyone else, but I haven't announced mine because I don't serve it from a stable IP. [13:38] lag, nah :) [13:39] ogra: [13:39] The following NEW packages will be installed: [13:39] apt-xapian-index aptitude bc bogl-bterm consolekit cpp cpp-4.4 cryptsetup dbus defoma devio dmraid dosfstools ecryptfs-utils flash-kernel [13:39] fontconfig fontconfig-config gcc-4.4-base gconf2-common gettext-base gir1.0-glib-2.0 hicolor-icon-theme hwdata iso-codes jasper keyutils [13:39] language-selector-common laptop-detect libasound2 libatk1.0-0 libatk1.0-data libavahi-client3 libavahi-common-data libavahi-common3 [13:39] libboost-iostreams1.42.0 libbsd0 libcairo2 libcanberra-gtk-module libcanberra-gtk0 libcanberra0 libcheese-gtk18 libck-connector0 [13:39] libclass-accessor-perl libcroco3 libcups2 libcwidget3 libdatrie1 libdbus-glib-1-2 libdebconfclient0 libdebian-installer4 libdmraid1.0.0.rc16 [13:39] libecryptfs0 libeggdbus-1-0 libept1 libexpat1 libffi5 libfontconfig1 libfontenc1 libfreetype6 libgconf2-4 libgcrypt11 libgdbm3 libgdk-pixbuf2.0-0 [13:39] libgirepository1.0-1 libgmp3c2 libgnome-desktop-2-17 libgnutls26 libgpg-error0 libgssapi-krb5-2 libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 [13:39] libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libgudev-1.0-0 libice6 libicu42 libidl0 libio-string-perl libiw30 libjasper1 libjpeg62 libk5crypto3 [13:39] god ! [13:39] libkeyutils1 libkrb5-3 libkrb5support0 libldap-2.4-2 libltdl7 libmpfr4 libnspr4-0d libnss3-1d libogg0 liborbit2 libpam-ck-connector libpango1.0-0 [13:39] !paste [13:39] use a pastebin ! [13:39] libpango1.0-common libparse-debianchangelog-perl libparted0debian1 libpixman-1-0 libpolkit-gobject-1-0 libpython2.6 librsvg2-2 libsasl2-2 [13:39] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [13:39] libsasl2-modules libsigc++-2.0-0c2a libsm6 libstartup-notification0 libsub-name-perl libtasn1-3 libtdb1 libthai-data libthai0 libtiff4 [13:39] libtimedate-perl libvorbis0a libvorbisfile3 libx11-6 libx11-data libxapian15 libxau6 libxcb-atom1 libxcb-aux0 libxcb-event1 libxcb-render0 [13:39] libxcb-shm0 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont1 libxft2 libxi6 libxinerama1 libxml2 libxrandr2 [13:39] libxrender1 lsof make oem-config oem-config-debconf os-prober parted perl perl-modules python-apt python-cairo python-dbus python-debian [13:39] python-gobject pyt [13:39] Argggggggggggggggggggggggggggggggggggggggggggggggggggg [13:40] Paste bin is not as much fun! [13:40] heh [13:40] Yeah, but not using one reliably makes me go fiddle with IRC commands :p [13:40] anyway, jasper depends on oem-config indeed [13:40] persia: I noticed [13:40] ogra: Again, I'm not sure you see that the problem is *earlier* [13:40] the other deps you see are all oem-config deps [13:40] ogra: I'm pretty sure the issue is that the fs in the image itself is truncated [13:41] whatever you do starting from there is bound to suffer from the corruption [13:41] lool, well, but where did your fsck come from ? [13:41] there is no technical possibility that you ever see any output of fsck if jasper ran [13:42] ogra: My understanding is that jsaper does a resize2fs [13:42] lool, jasper runs completely silently *all* output of any subcommands is redirected to a logfile [13:43] Well I still got some output apparently [13:43] if jasper ran there cant be any discrepancy between the partitioning and the fs anymore [13:43] Note that your pipe + read might not be enough to stop commands from writing to /dev/tty [13:43] What type of bot is ubot2? [13:43] since the rootfs partition was resized (no matter of the corruption or not, sfdisk doesnt care) [13:44] lool, well, then someone must have secretly uploaded a changed jasper :) we had various bugs and breakages that caused fsck errors that only show up in the log [13:45] i wouldnt know why that suddenly would change and ignore a redirect of stderr and stdout [13:46] Well it's just a guess [13:46] well, my guess is that jasper didnt run at all for you [13:46] either the fs is corrupted in the image, or it gets corrupted in the resize [13:47] ogra: http://people.canonical.com/~lool/fsck.png [13:48] lool, there is no initramfs output at all [13:48] ogra: It's earlier [13:48] ogra: But I can't scroll back [13:48] do you have a shot of that too ? [13:48] Let me try with serial console [13:48] ah, darn [13:48] ogra: is there a way to turn serial console output during boot? [13:48] only by changing boot.scr on the vfat [13:49] as long as plymouth breaks once console= is set we cant make it a default else we wont have any splash anymore [13:49] (second boot is completely with splash etc) [13:51] ogra: Can you give me the commands to run to type in u-boot? [13:51] one sec [13:51] I don't have a boot.scr nearby [13:52] fatload mmc 0:1 0x80000000 uImage [13:52] fatload mmc 0:1 0x81600000 uInitrd [13:52] So I'm on the serial line [13:52] ** Unable to use mmc 0:1 for fatload ** [13:52] mmc init [13:52] sh, indeed [13:52] s/sh/ah/ [13:52] Ok, this is done [13:52] Now the tricky part [13:52] setenv bootargs vram=12M omapfb.mode=dvi:1280x720MR-16@60 console=ttyS2,115200n root=/dev/mmcblk0p2 fixrtc [13:52] bootm 0x80000000 0x81600000 [13:52] thanks, booting [13:53] ogra: !paste [13:53] Lol [13:53] :D [13:53] :P [13:53] I get kernel output on serial console at least [13:54] ogra: So now I have Jasper installed, when I run my usual script to build an initrd, Jasper will just appear in there yes? [13:54] if jasper is inside the chroot you run upadte-initramfs in it will end up inside the initrd, yes [13:55] Jasper is installed in the chroot, yes [13:55] well, then it should end up in your initrd [13:55] * lag crosses fingers [13:56] ogra: http://paste.ubuntu.com/482895/ [13:57] lool, it doesnt reboot after line 30 ? [13:57] ogra: no [13:57] aha [13:57] thats one of the issues, can you try booting a second time ? [13:58] that will behave differently [13:58] right [13:58] ogra: I'm quite busy for doing long testing; would you be interested in looking into it with qemu? [13:58] it's not hard to reproduce in qemu [13:58] lool, also /var/log/jasper.log would be intresting [13:59] well, using these images in qemu will require a lot of tinkering with images in advance [13:59] ogra: Why is that? [13:59] because the FS needs to actually be resized [14:00] if you just boot the img file there is no spare space [14:00] Yes, which exposes this bug which apparently other people are seeing [14:00] so you would need to create a 4G image and dd the img file into it to have the proper way [14:00] As I noted in email, if I append some zeroes at the end of the image, I don't get this issue [14:00] like 10 MBs or so [14:00] yes, the bug is on antimony side though [14:01] ogra: It's trivial to add space to the QEMU SD backing image... [14:01] dd if=/dev/zero bs=1024 count=10240 >> /tmp/maverick-preinstalled-netbook-armel+omap.img [14:01] but it shouldnt appear if there is space to resize to, the resizing "fixes" the filesystem [14:02] thats why we dont see it (apart from jasper.log) on real installs [14:02] Has the meeting been cancelled? [14:02] lag, nope [14:02] ogra: Ok; I have other things to work on and I'm not blocked by that bug; I found it relevant to share what I believe is a bug in the Ubuntu images exposed by testing in QEMU, but it's time consuming for me to make my point and I have tons of other things to look into, sorry [14:03] lool, yeah, understood, thanks for pointing it out [14:03] I can share the recipe to reproduce, but you don't seem interested in resolving what appears to me as a bug in the jasper scripts [14:03] its not in jasper [14:03] the FS is apparently corrupt without resizing [14:03] which means its corrupt at creation time [14:04] and thats surely something i'll look at [14:04] what is worrying me more though is that the reboot doesnt work [14:13] ogra: When I build my own initrd, do I have to execute depmod at any stage? If so, what stage? [14:13] ogra: Well I'm not entirely sure it's corrupt at image creation time [14:13] update-initramfs does that iirc [14:14] ogra: jasper resizes the partitions before calling resize2fs, to it might get that part wrong... [14:14] lool, only your jasper.log could tell :) [14:14] but after you sent me that mail i checked a jasper.log and i see corruption there [14:15] ogra: Well perhaps you can reproduce in QEMU and dig the info you need? It's not hard, the .debs are pre-built, wont mess your other qemu, and you just need a maverick daily image to try out [14:15] lool, i will [14:17] NCommander: I've just pasted the bug id on #linaro, but you don't seem to be in there [14:17] NCommander: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/623375 [14:17] Launchpad bug 623375 in initramfs-tools (Ubuntu) "Skipping the bootloader installation when creating rootfs or installation media (affects: 1) (heat: 8)" [Undecided,New] [14:18] lool, i pointed him to it in the arm meeting [14:18] lool: yeah, I saw that. Whoops on my part, though ideally, we shouldn't directly run update-initramfs in a chroot either [14:22] NCommander: I don't see an issue with running update-initramfs in a chroot, in fact it's the only way to generate an initrd [14:23] ogra: ? [14:23] lag, ? [14:23] Look up [14:23] update-initramfs does that iirc [14:23] lool: I meant run it if a trigger calls it; we should run it if the user calls it directly. Obviously the generic bit of generic subarch detection is a bit too generic :-) [14:23] look up too ;) [14:23] NCommander: I don't think we want to run flash-kernel though [14:24] Which is what the bug is about [14:24] lool: I think we can detect the chroot via a syscall (I remember there's a way to do it in C), and then we can adjust what we do based off that [14:24] lool, before NCommander changed it it wouldnt have executed :) [14:24] lag: update-initramfs does that iirc [14:24] :) [14:24] lool, https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-maverick-arm-improved-subarch-detection [14:25] ogra: right, since flash-kernel --supported would have ailed [14:25] *failed [14:25] * NCommander needs a new keyboard [14:27] NCommander: it's a bad idea to detect the chroot [14:27] NCommander: d-i and ubiquity will install into /target, where you do want flash-kernel to run [14:28] lool: we can have special logic in flash-kernel-installer to simply manually call flash-kernel and work around the problem. [14:28] but point taken [14:28] lool: what do you suggest for a solution? [14:29] ogra: http://paste.ubuntu.com/482907/ [14:30] lag, cool ! [14:30] How is that cool? [14:30] it works [14:31] ogra: FATAL: Could not load /lib/modules/2.6.35-18-omap/modules.dep: No such file or directory [14:31] ignore that, you get to ubiquity-dm [14:32] (which doesnt start because of a bug in oem-config) [14:32] I don't want to ignore that [14:32] I want to fix that :) [14:35] ogra: -^ === dyfet_sleeping is now known as dyfet_waking [14:44] NCommander: well it was discussed in the bug already [14:44] lool: I haven't had a chance to read it. LP from China is ... interesting [14:45] NCommander: Oh you're there already, how is it? === dyfet_waking is now known as dyfet [14:45] Chinese? [14:45] lost of meo-burgers :) [14:45] lool: I've been here for a little over a week and a half :-) [14:45] *meow [14:45] ogra: that's vietnam === bjf[afk] is now known as bjf [14:59] ian_brasil: so, I admit, I haven't looked at the liquid stuff in-depth. Do you have a seed yet? [14:59] yes [14:59] (or a metapackage, but a seed is preferable) [14:59] oooh [14:59] handy [14:59] ogra: you really should watch food network sometime. You'd know that in china, dog is the meat of choice. [14:59] ian_brasil: so if I build a chroot, and then do apt-get install kubuntu-liquid^, everything works? [15:00] no [15:00] ian_brasil: it doesn't? [15:00] * NCommander admits he's not sure what your seed name is [15:00] no ..we dropped the liquid name [15:00] liquid was just a code name [15:01] ian_brasil: oops, I'm out of the loop >.<; [15:01] damn..fire alarm..back in a minute [15:13] excitement over [15:13] NCommander: the meta package is kubuntu-mobile [15:13] https://edge.launchpad.net/ubuntu/maverick/+package/kubuntu-mobile [15:13] ian_brasil: heh [15:14] ian_brasil: right, next step is to modify livecd-rootfs to add it as an image target [15:14] ian_brasil: its pretty straightforward on where the edits have to be made. Only thing is you want to pull by task, and not metapackage [15:15] ok [15:16] we have done that before i seem to remember [15:19] NCommander: i will ping you when that is done [15:19] ogra: Hi! I was wondering what OMAP3 boards you support in your OMAP prebuilt images. Just the Beagle board? [15:20] cureently just the beagle, yes [15:20] ian_brasil: thanks. I can't merge or do the upload, but I can guide you with the edits and doing some initial testing [15:20] ogra: all right, thanks! [15:20] mopdenacker, iegp2 might work if you have a special u-boot, gumstix too [15:20] ootb only beagle though [15:21] mopdenacker: ogra: xm should also work, but we have a mmc issue [15:21] err, indeed, i counted that as beagle :) [15:21] ogra: there are just too many different beagles at the marked hah [15:22] b, c, XM [15:22] C4 and XM are the ones we'll support by release day [15:22] sure [15:22] b will likely have issues to even boot [15:22] hehe, probably [15:22] at least our current images [15:22] unless we get a minimal image, no way to support it [15:22] even for simple boot [15:23] right [15:23] mine is running well with a simple rootstock fs [15:23] ogra: Any chance of building an alt-inst image? [15:23] GrueMaster, nope [15:23] ok. [15:23] ogra: I commented at the ureadahead bug, it doesn't make any difference for us [15:23] I checked that [15:23] GrueMaster, we are fully focused on preinstalled images and would have no way to support systems without NAND in a sane way atm [15:24] but let's wait for the new rewrite [15:24] and it doesn't make any sense to run until we get OOM, doesn't help at all [15:24] rsalveti, yeah, i talked to Keybuk already this morning (thats why he commented on the bug) [15:24] ogra: ok. [15:24] ogra: I saw that, and at the time I got to irc he wasn't there anymore [15:24] GrueMaster, would be good to probably address that in N [15:25] oh, he dropped again ... ? bah [15:25] ogra: What about a preinst-min image? [15:25] ogra: so let's wait for the new version, then we can test [15:25] GrueMaster, requires time i dont have [15:25] Minor mods needed. [15:25] but I doubt it will make any difference [15:25] no, massive mods needed [15:25] Ok, just a suggestion. [15:25] thats the prob [15:25] but will be happy to be wrong [15:25] there apparently is a base image already that has been implemented for special purposes [15:26] to change that requires a ton of changes [15:26] (it doesnt build an image, just a base tarball for local testing purpose) [15:27] GrueMaster, i'd love to have it, but the current quality of the images we actually have makes me thing that i wont find the time [15:27] *think [15:27] * ogra gest some coffee [15:28] Actually, if we had them, it might be easier to debug netbook image issues. [15:28] And daily image testing could continue at a limited pace. [15:29] * GrueMaster remembers making this same arguement months ago. [15:32] so I have a new imx51 "SmartTop" system sitting here I want to upgrade to maverick. Will it break ? [15:34] GrueMaster, yes, and i said "i'd love to have them but i dont know if i have the time" [15:34] rsavoye, no idea, we dropped imx51 support with lucid [15:35] bummer. Can I upgrade and leave the kernel alone ? [15:35] mater of luck i guess [15:35] it's running karmic now [15:36] rsavoye: You'd need to bump the kernel. Karmic was Armv6+vfp. [15:36] Might be as easy as copying the config and rebuilding. [15:36] it might be possible to run v7 userspace with a v6 compiled kernel, not sure [15:37] as long as your userspace is all v7 [15:37] i'D just keep a backup of the original system and try it :) [15:37] so to do the user space hack, I'd just change sources.list? [15:37] yes [15:37] guess I'll let you know :-) [15:37] but really, keep a backup ! [15:38] it's fresh hardware, so nothing to loose [15:38] GrueMaster, our buildds were all running v5 compiled kernels until we got the babbage boards in the DC [15:38] there were issues but i dont know if they were caused by v5 vs 6/7 [15:40] is ther an easy way to block upgrading the kernel when I upgrade everything else ? [15:41] it shuldnt upgrade the kernel unless you already have an ubuntu kernel package [15:41] which i doubt [15:41] cool, I'll give it a try [15:42] rsavoye: I confirm. I use Lucid on my IGEPv2 board, and everything gets updated, except my custom kernel. [15:42] rsavoye: YOu can try to do a dist-upgrade, but cancel when it asks to continue. Then do a manual install on individual packages. [15:43] dist-upgrade or update-manager -d ? [15:44] both should work [15:44] or do-release-upgrade [15:44]