Re: booting rootfs with linux-image-vexpress in qemu 1.0~ from harddisk image
Am 04.06.2012 23:30, schrieb Arnaud Patard (Rtp): One should never draw conclusions in bug reports, but when browsing the kernel config posted for the original vexpress wish (#670462), there is an nfsrootfs configured in CMDLINE option. So I guess the requestor checked that with a rootfs over network but not from qemu's local harddisk?! you can try initrd+qemu sd/mmc emulation. Excellent. Option -sd plus root=/dev/mmcblk0 made it [0]. Now I need to generate a proper sd-card image (partiontable etc.)... Thanks for the hint! Marcus [0] https://gitorious.org/debian/rootfs-builder/blobs/master/configs/wheezy-grip_qemu_armhf_config#line17 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd1ccc1.8010...@googlemail.com
Re: cross compile kernel with deb-pkg
Am 06.06.2012 01:08, schrieb Marcus Osdoba: Recently I tried to cross compile a kernel (package) with make ARCH=target CROSS_COMPILE=target-triplet- deb-pkg That worked well for 2.6.32 kernels from squeeze. But the 3.2 kernels from wheezy/backports fail with: [..] Since cross compiling (pacakges) is possible with squeeze kernels, but not with those from wheezy, I'm not sure, if this feature was intentionally dropped, because everybody should use a qemu-binfmt backed pbuilder nowadays..? Because the conversion in [0] ended, I guess the issue is still open. Is it possible to re-enable cross building the kernel with deb-pkg? Or a commandline option to supress generating the header-pkg ? Thanks and kind regards, Marcus [0] http://lists.debian.org/debian-kernel/2011/01/msg00494.html -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd1ff88.2000...@googlemail.com
cross compile kernel with deb-pkg
Hello, Recently I tried to cross compile a kernel (package) with make ARCH=target CROSS_COMPILE=target-triplet- deb-pkg That worked well for 2.6.32 kernels from squeeze. But the 3.2 kernels from wheezy/backports fail with: dpkg-gencontrol: error: current host architecture 'powerpc|armel' does not appear in package's architecture list (i386|amd64) I tried multiple combinations: host = amd64 or i386 and target = armel/armhf/powerpc It turned out that that the 3.2 package didn't build with the above error, but 2.6.32 does. I have found a former thread but without conclusion. http://osdir.com/ml/linux-kernel/2011-01/msg00135.html When I looked into the generated debian/rules (or control?) I noted the i386 architecture setting for the kernel-header package. Since cross compiling (pacakges) is possible with squeeze kernels, but not with those from wheezy, I'm not sure, if this feature was intentionally dropped, because everybody should use a qemu-binfmt backed pbuilder nowadays..? Kind regards, Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fce9165.2020...@googlemail.com
booting rootfs with linux-image-vexpress in qemu 1.0~ from harddisk image
Hello Mailinglist, I'm not sure, if this is worth a bug report, but recnetly I tried to boot a multistrapped wheezy armhf system in qemu from squeeze-backports. The qemu command line included the -hda option but the vexpress kernel wasn't able to find /dev/sda or /dev/hda. The system dropped to busybox command line and I didn't see an sda or hda device when runnign dmesg there. One should never draw conclusions in bug reports, but when browsing the kernel config posted for the original vexpress wish (#670462), there is an nfsrootfs configured in CMDLINE option. So I guess the requestor checked that with a rootfs over network but not from qemu's local harddisk?! Best regards, Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fcd213b.2070...@googlemail.com
Bug#670492: linux-image-2.6.32-5-amd64: RTL8111/8168B Wake on LAN does not work
Hi, I encountered the same problem with one of the last 3.2 kernels from backports on my squeeze server installation (node B). The system has two rtl interfaces - a gigabit on board and a 100Mbit as PCI card. r8169 :03:00.0: eth0: RTL8168b/8111b at 0xc960e000, 00:18:f3:21:XX:YY, XID 1800 IRQ 44 8139too :05:01.0: eth1: RealTek RTL8139 at 0xc9644c00, 00:e0:7d:9e:ZZ:AA, IRQ 22 I always woke up the system by wakonlan RTL8139. Some weeks ago I upgraded the backports-kernel and the wakeonlan stopped working. I tried the same with the onboard adapter RTL8168b/8111b. That was successful. So I can still wake up the system by a magic packet, but the desired interface (RTL8139) doesn't work. Regards, Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb2acbb.5000...@googlemail.com
Re: Outdated linux-2.6 backport
Am 24.01.2012 16:00, schrieb Ben Hutchings: On Mon, 2012-01-23 at 13:41 +, Ben Hutchings wrote: On Mon, 2012-01-23 at 08:16 +0100, Marcus Osdoba wrote: I have found linux-2.6 in the bpo upload Q today. Thanks for this. Please keep cpufrequtils-007-2 for kernels= 3.0 in mind. I will leave that to you to upload. This isn't necessary as cpufrequtils has already been fixed in stable (007-1+squeeze1). Excellent. So 007-1+squeeze1 == 007-2 ? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1f09ed.90...@googlemail.com
Re: Outdated linux-2.6 backport
Am 18.01.2012 05:05, schrieb Ben Hutchings: On Wed, 2012-01-18 at 03:42 +, Ben Hutchings wrote: On Wed, 2012-01-18 at 00:40 +0100, Marcus Osdoba wrote: [...] Now that I finished with building up [...] linux-image-3.1.0-1-486_3.1.8-2~bpo60+1_i386.deb This is wrong; modules built for '3.1.0-1-486' in testing/unstable will not be loadable in a backported kernel due to the compiler version change. (I don't believe that gcc 4.4 and 4.6 are at all incompatible, but the module loader does check this.) [...] Hmm... I think it used to, but I don't see any sign that it does any more. But let's not test this. Sorry, I didn't get this. I've downgraded the compiler for the backported kernel to gcc 4.4. Thesis: In general you won't have plain testing-packages if you just use stable+stable-backports. So when compiling the 3.1.8-modules with the same stable gcc (4.4) there is no gcc version mismatch within stable+stable-backports (there is no gcc 4.6...) So every additonal kernel module (besides those packaged inside linux-image) need to be backported with the same gcc version. Forgive me, if I got that completly wrong. Anyway, are there any news in the backport upload process? I still use my own packages, but on the server I feel more comfortable with an official version where more users may file bugs against. Thanks for your hard work. Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1bd704.5060...@googlemail.com
Re: Outdated linux-2.6 backport
Am 18.01.2012 04:42, schrieb Ben Hutchings: cpufrequtils (007-2) A separate build-container for each architecture was used to be sure, that there are only stable packages installed. I reverted the compiler back to gcc 4.4. Cpufrequtils is needed for newer kernels to have the cpufreq modules work properly. I had forgotten that. Thanks. I have found linux-2.6 in the bpo upload Q today. Thanks for this. Please keep cpufrequtils-007-2 for kernels = 3.0 in mind. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1d0934.4040...@googlemail.com
Bug#654598: Please enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP
I guess this is done since 3.0.0~rc1-1~experimental.1 ? linux-2.6 (3.0.0~rc1-1~experimental.1) experimental; urgency=low * cgroups: Disable memory resource controller by default. Allow it to be enabled using kernel parameter 'cgroup_enable=memory'. [...] * cgroups: Enable CGROUP_MEM_RES_CTLR_SWAP but not CGROUP_MEM_RES_CTLR_SWAP_ENABLED. Swap accounting can be enabled using kernel parameter 'swapaccount' [...] You need to use a kernel parameter to active it - equal to the memory controller. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1d0aea.3060...@googlemail.com
Re: Outdated linux-2.6 backport
Am 19.10.2011 15:05, schrieb Ben Hutchings: Please keep linux-2.6 up-to-date in backports [..] Hello debian kernel maintainers, I've created a private backport of kernel 3.1.8 from testing for i386/amd64. The packages I considered are: linux-image-amd64 linux-image-i386-686-pae linux-image-i386-486 linux-headers-all (and common) linux-kbuild-3.1 (linux-tools) cpufrequtils (007-2) A separate build-container for each architecture was used to be sure, that there are only stable packages installed. I reverted the compiler back to gcc 4.4. Cpufrequtils is needed for newer kernels to have the cpufreq modules work properly. Tested (positiv): amd64-pkg+headers in my virtual box squeeze installation (some clicks, some apps, lxc-cgroups, some compiles - so far no problems) and i386-486 on my thinkpad x40 (not PAE capable, tested some browsing, rootfs on crypt device and a few apps - no probs so far). The tests included the headers (compiling vbox host module and vbox guest extensions) and cpufrequtils. Now that I finished with building up cpufrequtils_007-2~bpo60+1.debian.tar.gz cpufrequtils_007-2~bpo60+1.dsc cpufrequtils_007-2~bpo60+1_(i386|amd64).changes cpufrequtils_007-2~bpo60+1_(i386|amd64).deb cpufrequtils_007.orig.tar.bz2 libcpufreq0_007-2~bpo60+1_(i386|amd64).deb libcpufreq-dev_007-2~bpo60+1_(i386|amd64).deb linux-headers-3.1.0-1-486_3.1.8-2~bpo60+1_i386.deb linux-headers-3.1.0-1-686-pae_3.1.8-2~bpo60+1_i386.deb linux-headers-3.1.0-1-all_3.1.8-2~bpo60+1_(i386|amd64).deb linux-headers-3.1.0-1-amd64_3.1.8-2~bpo60+1_amd64.deb linux-headers-3.1.0-1-common_3.1.8-2~bpo60+1_(i386|amd64).deb linux-image-3.1.0-1-486_3.1.8-2~bpo60+1_i386.deb linux-image-3.1.0-1-686-pae_3.1.8-2~bpo60+1_i386.deb linux-image-3.1.0-1-686-pae-dbg_3.1.8-2~bpo60+1_i386.deb linux-image-3.1.0-1-amd64_3.1.8-2~bpo60+1_amd64.deb linux-kbuild-3.1_3.1.1-3~bpo60+1_(i386|amd64).deb linux-libc-dev_3.1.8-2~bpo60+1_(i386|amd64).deb linux-tools_3.1.1-3~bpo60+1.debian.tar.gz linux-tools_3.1.1-3~bpo60+1.dsc linux-tools_3.1.1-3~bpo60+1_(i386|amd64).changes linux-tools_3.1.1.orig.tar.gz linux-tools-3.1_3.1.1-3~bpo60+1_(i386|amd64).deb I wonder, if someone else like to participate in my private backporting efforts. I could provide all generated files (.diffs and .debs) if someone with a DD-trusted key likes to compile and upload linux-image-3.1.8+supplements. It's unclear if gcc 4.4 is acceptable for a backport (original from wheezy takes 4.6 - so there may arise problems just because of the different compiler version while kernel version remains identical). Regards, Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1606d8.3010...@googlemail.com
Re: [Fwd: Latest kernel stable/longterm status]
Am 10.01.2012 02:42, schrieb Ben Hutchings: We need to make a decision soon on whether we will use Linux 3.2 for wheezy or wait for a later release. Whichever one we choose, we need to make sure someone (possibly one of us) maintains a longterm branch for it. I am strongly disinclined to choose a version that puts us on our own, and therefore I would prefer to use Linux 3.2 along with Ubuntu. Hi, I'm just a user, but using 3.2 along with Ubuntu LTS looks more than reasonable to me. Unfortunatly, upstream maintains only 3.0. Is there any longterm version beyond 3.0 in sight, which might be an adequate alternative for Wheezy? If not, the sum of Debian/UbuntuLTS installations should have a critical mass to justify the maintenance of a 3.2-DEBline on their own without offcial support from upstream. Regards, Marcus Forwarded Message From: Greg KHg...@kroah.com To: linux-ker...@vger.kernel.org Cc: sta...@vger.kernel.org Subject: Latest kernel stable/longterm status Date: Mon, 9 Jan 2012 16:37:05 -0800 As 3.2 is now out, here's a note as to the current status of the different stable/longterm kernel trees. First off, please everyone remember to mark any patch that you want to have applied to the stable kernel trees with a simple: Cc: stablesta...@vger.kernel.org marking in the Signed-off-by: area. Once the patch hits Linus's tree, I will automatically be notified of it and it will be applied if possible. If it does not applied, you will be notified of that. Note that the address is sta...@vger.kernel.org, not the older address that used to be used before October of 2011. At this time, all stable and longterm kernel trees are being maintained in one big git tree, located at: git.kernel.org:/pub/scm/linux/kernel/git/stable/linux-stable.git There are different branches for every different major kernel version. Here's the different active kernel versions that I am maintaining at the moment: 3.2.y - this will be maintained until 3.3 comes out 3.1.y - there will be only one, maybe two, more releases of this tree 3.0.y - this is the new longterm kernel release, it will be maintained for 2 years at the minimum by me. 2.6.32.y - this is the previous longterm kernel release. It is approaching it's end-of-life, and I think I only have another month or so doing releases of this. After I am finished with it, it might be picked up by someone else, but I'm not going to promise anything. All other longterm kernels are being maintained in various forms (usually quite sporadically, if at all), by other people, and I can not speak for their lifetime at all, that is up to those individuals. If anyone has any questions about any of this, please let me know. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f0cbfb2.20...@googlemail.com
Bug#468114: Please apply the loopbackfs patch
The loopback is not only suitable for installing on a windows FS. I use it to put an ext3 image on a vfat sd card in my Wii, since homebrew apps are only able to handle vfat. So I'm not forced to change the sdcard or partition it. http://gitorious.org/dockstar/emdebian-multistrap/blobs/master/patches/initramfs-tools_loopbackrootfs.patch I could image other cases: Embedded world: create RO images, mount them for fallback, different versions of a firmware (behaviour charaterized by the rootfs) Servers: mount several versions of an installation, test new installations without reorganizing the hosting FS -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed6a685.3000...@googlemail.com
Bug#649211: Boot failure on Thinkpad X40
@Jonathan: Thanks for the hint. @Ben: Take my excuses, I didn't notice the cloning step. This bug could be marked as a duplicate of bug#637395. I installed cpufreq-utils 007-2 from testing and the problems went away. The kernel itself booted fine, so I won't send the output of the netconsole. With cpufreq-utils 007-1 (not -2), I get the module insertion FATAL errors as described earlier. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed236e9.2020...@googlemail.com
re-rename Bug#649211 to its origin title - X40 cpufreq-info problems
Hi Ben, The original Bug#649211 described an issue with missing sysfs/cputopology in the 486 kernel. Since the problem still exists, I prefer to keep it open as its origin. Basically I see two solutions: The 486 kernel varaint should publish cputopology in sysfs, too. (Someday more 686 users will recognize, that they are not able to use the PAE variant and they have to fall back to 486) Or the the virt-manager shouldn't fail if it doesn't find cputopology (and assume processorno=1 for 486, which seems logical, too) Anyway, regarding the X40 boot issue with 3.1.0 kernel: The kernel itself boots fine, but I got a bunch of FATAL module insertions beginning with powernow_k8 followed by speedstep_ich and some more. I was able to rdirect the boot messages of the kernel via netconsole, but how to do the same with early init process? After the fatal module insertions, the cpufreq-info command shows suspicious output [1]. 75 Mhz min to 600 Mhz max. (My X40 showed the correct 600Mhz min and 1400 Mhz max with 2.6.39bpo before). Furthermore, it uses the p4-clockmodule instead of centrino (which failed during init). Regards, Marcus [1] root@thinkpad:~# cpufreq-info cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009 Bitte melden Sie Fehler an cpuf...@vger.kernel.org. analysiere CPU 0: Treiber: p4-clockmod Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0 Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0 Maximale Dauer eines Taktfrequenzwechsels: 10.00 ms. Hardwarebedingte Grenzen der Taktfrequenz: 75.0 MHz - 600 MHz mögliche Taktfrequenzen: 75.0 MHz, 150 MHz, 225 MHz, 300 MHz, 375 MHz, 450 MHz, 525 MHz, 600 MHz mögliche Regler: conservative, powersave, userspace, ondemand, performance momentane Taktik: die Frequenz soll innerhalb 75.0 MHz und 600 MHz. liegen. Der Regler performance kann frei entscheiden, welche Taktfrequenz innerhalb dieser Grenze verwendet wird. momentane Taktfrequenz ist 600 MHz (verifiziert durch Nachfrage bei der Hardware). Statistik:75.0 MHz:0,00%, 150 MHz:0,00%, 225 MHz:0,00%, 300 MHz:0,00%, 375 MHz:0,00%, 450 MHz:0,00%, 525 MHz:0,00%, 600 MHz:100,00% -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecd7b16.8020...@googlemail.com
Bug#649211: linux-image-486: /sys/devices/system/cpu/cpu0/crash_notes and no topology
Am 18.11.2011 23:55, schrieb Ben Hutchings: On Fri, Nov 18, 2011 at 10:25:39PM +0100, Marcus Osdoba wrote: Package: linux-image-486 Version: 3.1.1 Severity: important Hi, I have tested virt-manager on my Debian Squeeze on several installations. Unfortunatly it does not work with 486 variant of the kernel [1]. When running the 686 variant, the topology is found in /sys/devices/system/cpu/cpu0/ , but not with 486 [2]. The 486 flavour only supports a single processor (since all SMP- capable processors also support PAE) so the CPU topology is never very interesting and the code to expose it in sysfs is not built. Maybe it should be, for consistency. Beyond Squeeze, one is forced to use 486 for systems without PAE (physically not available or not choosen to be activated for some reason). On these 32bit systems it is still possible to test and create qemu-vms and lxc-containers with virt-manager. But the standard kernel is not able to do so. If possible, please enable memory_cgroup controller in Squeeze kernel (activated with kernel commandline like in 2.6.39+) - so it is possible to use 686 from Squeeze then. I think, one should know, that the 486 does not provide cputopology anymore (for consistency it should, yes). Since some of my boxes are not able/not want to use 686-PAE, I'm in a gap. Marcus P.S.: Booting version 3.1.1-486 on X40 is another bug for me ;-) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec8db3c.2010...@googlemail.com
Bug#649211: linux-image-486: /sys/devices/system/cpu/cpu0/crash_notes and no topology
Package: linux-image-486 Version: 3.1.1 Severity: important Hi, I have tested virt-manager on my Debian Squeeze on several installations. Unfortunatly it does not work with 486 variant of the kernel [1]. When running the 686 variant, the topology is found in /sys/devices/system/cpu/cpu0/ , but not with 486 [2]. In some situtuations the user is not able or does not want to use the 686-pae version (e.g. my lovely testing platform X40 has no PAE capable processor and in VirtualBox the performance suffers when activating PAE and one does usually not need PAE for 32bit testing vms). I have found and old bugreport, which describes a similar problem. https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/66812 When crawling the net, most of this errors were solved by choosing the 686 variant of the kernel, which is not available anymore (not beyond Squeeze). The Squeeze kernel does not have cgroup_memory built in, which prevents virt- manager from working with LXC. The 486 kernel from wheezy and sid (3.0.0 and 3.1.1) didn't boot proper on my X40, but in VirtualBox, I was able to verify, that these versions still don't show cputopology in /sys/devices/system. Regards, Marcus [1] Error polling connection 'qemu:///system': cannot open /sys/devices/system/cpu/cpu0/topology/physical_package_id: No such file or directory Error polling connection 'lxc:///': cannot open /sys/devices/system/cpu/cpu0/topology/physical_package_id: No such file or directory [2] root@thinkpad:/home/ossy# ls -l /sys/devices/system/cpu/cpu0/ insgesamt 0 drwxr-xr-x 3 root root0 18. Nov 21:34 cpufreq drwxr-xr-x 7 root root0 18. Nov 21:34 cpuidle -r 1 root root 4096 18. Nov 21:38 crash_notes root@thinkpad:/home/ossy# cat /sys/devices/system/cpu/cpu0/crash_notes 377f1e5c -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.39-bpo.2-486 Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2018212539.3304.56929.report...@thinkpad.fritz.box
Re: Bug#636123: kernel panic after installing 2.6.39 from backports on squeeze
Am 06.09.2011 06:38, schrieb Ben Hutchings: I've now tested upgrading from squeeze to squeeze-backports kernel package in a VM, with the results: # apt-get install linux-image-2.6.39-bpo.2-pae Fails, complaining that initramfs-tools will be broken. # apt-get install linux-image-2.6.39-bpo.2-pae initramfs-tools/squeeze-backport Succeeds and builds an initramfs automatically as expected. # aptitude install linux-image-2.6.39-bpo.2-pae Offers to install dracut and remove initramfs-tools! # aptitude install linux-image-2.6.39-bpo.2-pae initramfs-tools/squeeze-backport Succeeds and builds an initramfs automatically as expected. So my best theory is that aptitude is leading some people astray. Do you use aptitude? Did you get dracut installed, even though you don't intentionally use it? I always used apt-* and never aptitude. But my upgrade path was a bit different from yours. - Install vanilla Squeeze (from 6.0.2.1 netinstcd) - Add backports to sources.list as described on the Wiki page - install with # apt-get install -t squeeze-backports linux-image-2.6.39-bpo.2-amd64 (I don't remember exactly, but initramfs-tools were updated, too in this step; so I guess this was initramfs-tools from backports) I've never noticed a dracut installation... I did the same steps in a virtual machine now and I was NOT able to reproduce the problem (dracut not installed, kernel 2.6.39bpo boots fine with the generated ramdisk). The original bug report mentions an lvm. I've discovered the problem with an installation on a dm-raid device. Finally, I need to recheck it on the real hardware. Regards, Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e667aa6.9040...@googlemail.com
Re: Bug#636123: kernel panic after installing 2.6.39 from backports on squeeze
Am 22.08.2011 20:32, schrieb Ben Hutchings: On Mon, Aug 22, 2011 at 06:55:12PM +0200, Valentijn Scholten wrote: I am running into a similar isue with 2.6.39.2. amd64. I decided to install 2.6.39.2 from backports (apt-get install ...) I rebooted, and got a kernel panic about not being able to find the root file system. No filesystem could mount root, tried: Kernel panic = not syncing: VFA: Unable to mount root fs on unkown-block(0,0). [...] Hi, Im running Squeeze on an Intel S1200BTS (quite new hardware with i3-2100T and two NICs). Because only one NIC was supported by the recent stable kernel, I decided to install the newest kernel from squeeze-backports. I've made positive experiences with 2.6.38bpo on other systems. The root systems resides on a bios backed softraid (dm-raid) level 1. After installing the 2.6.39bpo I run into the same trap as described above. I rebooted with the default stable kernel kernel. Because installing the system on the dm-raid device wasn't that straight forward, I thought it had to do something with the generated device name in /dev/mapper/generatedid for the dm-raid (thesis: different behaviour with UUID for dmraids in newer kernels?). So I changed the kernel commandline in grub.cfg and reconfigured grub (replace UUID with /dev/mapper/id which regenerated a ramdisk, too). The newer kernel booted fine now. But after reading, that other people experienced the same problem with installing 2.6.39bpo (in devmapperlib context), I now know, that a missing update-initramfs after installing might be the problem (which I triggered unconciously by reconfiguring grub). I do not use dracut, just stable with kernel from backports. So I like to state, that there is a known workaround: Make sure to regenerate the initramfs before rebooting and do not uninstall the stable kernel ;-) I'm not in front of the mentioned hardware right now, so I cannot reproduce it reliably. Therefore I don't want to spam the bug history. Regards, Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5d2a4b.5080...@googlemail.com
Re: preferred solution for building kernel.deb and defining Entry point address
Am 13.07.2011 03:41, schrieb Ben Hutchings: On Tue, 2011-07-12 at 23:05 +0200, Marcus Osdoba wrote: Am 12.07.2011 01:43, schrieb Ben Hutchings: The commands on a recent amd64 Squeeze were: linux-src#sudo make-kpkg --initrd --cross-compile powerpc-linux-gnu- --arch powerpc --append-to-version +mikep5 kernel_image linux-src#sudo make KDEB_PKGVERSION=upstreamdebpkgcreatorNOINITRD.1.0 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- deb-pkg linux-src#sudo make ARCH=powerpc CROSS32_COMPILE=powerpc-linux-gnu- CROSS_COMPILE=powerpc-linux-gnu- zImage I think the problem may be that make-kpkg and make deb-pkg use the vmlinux file and not the zImage file which is what you need. True. The default for powerpc seems to be vmlinux in any case. I tried to override it. make deb-pkg: KBUILD_IMAGE=zImage - That worked. The image inside the generated deb had the desired entry point of 0x60. make-kpkg: I tried the equivalent here (--zimage or IMAGE_TYPE=zImage). But that didn't work. The image inside the deb package still had 0xc000. So it is still possible to use the generate-deb-scripts (at least the recommended one) for creating bootable Wii kernels. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1f5b60.3070...@googlemail.com
Re: preferred solution for building kernel.deb and defining Entry point address
Am 12.07.2011 01:43, schrieb Ben Hutchings: Please explain exactly how you are building the kernel with a different entry point (config changes and commands). Hi Ben, many thanks for the answer. I'm working with the debian sources on patchlevel 31 as base and applied the mikep5 patch [1]. I also tried to use the default powerpc-config (I grepped it from a powerpc-kernel-deb). The commands on a recent amd64 Squeeze were: linux-src#sudo make-kpkg --initrd --cross-compile powerpc-linux-gnu- --arch powerpc --append-to-version +mikep5 kernel_image linux-src#sudo make KDEB_PKGVERSION=upstreamdebpkgcreatorNOINITRD.1.0 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- deb-pkg linux-src#sudo make ARCH=powerpc CROSS32_COMPILE=powerpc-linux-gnu- CROSS_COMPILE=powerpc-linux-gnu- zImage All commands were launched within the same linux-src-tree. readelf -h image out of deb generated by make-kpkg -- 0xc000 readelf -h image out of deb generated by make deb-pkg -- 0xc000 readelf -h arch/powerpc/boot/zImage -- desired 0x60 I know, that 0x60 works for my Wii. And I know, that the powerpc images of the official packages have an Entry point address of 0xc000. Nevertheless, I don't understand, why make-kpkg/make deb-pkg are producing an image with a different address than using plain make commands. Regards, Marcus [1] http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel_%28ARCH%3Dpowerpc%29 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1cb70a.8010...@googlemail.com
