Bug#597751: linux-image-2.6.32-5-amd64: /etc/kernel/postinst.d/zz-update-grub exits with return code 139
inst/ignoring-do-bootloader-2.6.32-5-amd64: shared/kernel-image/really-run-bootloader: true linux-image-2.6.32-5-amd64/postinst/depmod-error-initrd-2.6.32-5-amd64: false linux-image-2.6.32-5-amd64/prerm/removing-running-kernel-2.6.32-5-amd64: true linux-image-2.6.32-5-amd64/postinst/bootloader-test-error-2.6.32-5-amd64: -- Moshe Yudkowsky * mo...@pobox.com * www.pobox.com/~moshe -- 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/4c9a476c.1020...@pobox.com
Bug#466754: linux-image-2.6.24-1-amd64: AMD64 Dual-Core clock skew of 2.5%
I have discovered that /etc/default/adjtimex contained a TICK value of 9750, which exactly accounts for the 2.5% loss of time exactly. I continue to investigate how the file obtained this value -- an error in either the ntp or the adjtimex packages comes to mind -- but this bug can be closed. I highly recommend that anyone who is investigating clock skew use the README and tools available with ntpclient, <http://doolittle.icarus.com/ntpclient/>. -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe "The sharpest knives are also the quietest." -- John M. Ford, _The Final Reflection_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466754: linux-image-2.6.24-1-amd64: AMD64 Dual-Core clock skew of 2.5%
on: ii debconf [debconf-2.0]1.5.19 Debian configuration management sy ii initramfs-tools [linux-initr 0.91e tools for generating an initramfs ii module-init-tools3.3-pre11-4 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-25 Yet Another mkInitRD linux-image-2.6.24-1-amd64 recommends no packages. -- debconf information: linux-image-2.6.24-1-amd64/preinst/abort-overwrite-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/postinst/old-dir-initrd-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/failed-to-move-modules-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/postinst/bootloader-test-error-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/postinst/create-kimage-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/depmod-error-initrd-2.6.24-1-amd64: false linux-image-2.6.24-1-amd64/preinst/overwriting-modules-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/bootloader-error-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/postinst/old-initrd-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/kimage-is-a-directory: linux-image-2.6.24-1-amd64/preinst/bootloader-initrd-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/initrd-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/prerm/removing-running-kernel-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/depmod-error-2.6.24-1-amd64: false shared/kernel-image/really-run-bootloader: true linux-image-2.6.24-1-amd64/preinst/lilo-initrd-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/old-system-map-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/lilo-has-ramdisk: linux-image-2.6.24-1-amd64/preinst/abort-install-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/prerm/would-invalidate-boot-loader-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/elilo-initrd-2.6.24-1-amd64: true -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe "You can lead a yak to water, but you can't teach an old dog to make a silk purse out of a sow's ear." -- Opus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375418: linux-image-2.6-k7: unmet dependency causes package to be removed
Package: linux-image-2.6-k7
Severity: normal
During a dist-upgrade, the linux-{image,headers}-2.6-k7 virtual packages are
removed because of an unmet dependency:
# apt-get -s install linux-image-2.6-k7
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
linux-image-2.6-k7: Depends: linux-image-2.6.16-2-k7 (= 2.6.16-14) but
2.6.16-15 is to be installed
Please let me know if you require additional information.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355580: Bug 355580: output of fdisk
maximilian attems wrote: On Wed, 15 Mar 2006, Moshe Yudkowsky wrote: I added this line to make certain that sata_promise loads before md loads. At one time I had trouble with getting the system to boot, and that line seemed to help by making certain the serial ATA drive module was loaded before md loaded. yes initrd-tools needed that workaround, i'm happy you managed to boot sata with it. please try to remove it, initramfs-tools should load sata_promise just fine. Ok, I've tried that, see below. However, if anyone ever has a legitimate reason to use "install," they will suffer a boot failure and they won't be able to figure out why there has been a failure. Device Boot Start End Blocks Id System /dev/sda1 * 124902893+ fd Linux raid autodetect /dev/sda224912614 996030 fd Linux raid autodetect /dev/sda32615973357183367+ fd Linux raid autodetect /dev/sda49734 1459639062047+ fd Linux raid autodetect from your previous sent fstab the forth entry is false could you please set it to linux 83 that could potentially confuse mdrun, can you retry if fixing that works? I set it to linux 83, took out all my modifications, and mdrun does work. After I end up in busybox, I looked at /proc/mdstat, and I saw that mdrun had created /dev/md/[012]. So mdrun continues to be confused by my configuration. cat /proc/mdstat would be even cooler. Of course! Here it is: Personalities : [linear] [raid0] [raid1] md3 : active raid1 hda3[0] sda3[1] 57183296 blocks [2/2] [UU] md2 : active linear hda2[0] sda2[1] 1991808 blocks 64k rounding md1 : active raid1 hda1[0] sda1[1] 2768 blocks [2/2] [UU] unused devices: and as a bonus, the current fdisk: fdisk -l /dev/sda Disk /dev/sda: 120.0 GB, 120060444672 bytes 255 heads, 63 sectors/track, 14596 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 124902893+ fd Linux raid autodetect /dev/sda224912614 996030 fd Linux raid autodetect /dev/sda32615973357183367+ fd Linux raid autodetect /dev/sda49734 1459639062047+ 83 Linux Thanks again for your help, and please let me know if you need further tests by me. -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe "You may fire when ready, Gridley." -- Commodore George Dewey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355580: Bug 355580: output of fdisk
eiserfsdefaults0 1 proc/proc procdefaults0 0 /dev/fd0/floppy autouser,noauto 0 0 /dev/cdroms/cdrom0 /cdrom iso9660 ro,user,noauto 0 0 /dev/cdroms/cdrom1 /cdrom2 iso9660 ro,user,noauto 0 0 # /dev/sdb /umsvfatuser,noauto 0 0 # test of ability to mount old file systems /dev/hda3 /mnt/hdaext3defaults,noauto 0 0 # /dev/hda1 /mnt/hda1 ext2defaults,noauto 0 0 mount: /dev/md/1 on / type reiserfs (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) usbfs on /proc/bus/usb type usbfs (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/md/3 on /home type reiserfs (rw) /dev/scsi/host0/bus0/target0/lun0/part4 on /backup type reiserfs (rw) tmpfs on /dev type tmpfs (rw,size=10M,mode=0755) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /dev/scsi/host2/bus0/target0/lun0/disc on /iriver type vfat (rw,noexec,nosuid,nodev,umask=) //sluggy/c$ on /pc/sluggy/moshe type smbfs (rw) (the iriver mp3 player is not actually on the system right now -- a udev script error that I need to correct didn't umount /iriver when I unplugged it from USB) fdisk -l /dev/hda Disk /dev/hda: 80.0 GB, 80060424192 bytes 255 heads, 63 sectors/track, 9733 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 124902893+ fd Linux raid autodetect /dev/hda224912614 996030 fd Linux raid autodetect /dev/hda32615973357183367+ fd Linux raid autodetect fdisk -l /dev/sda Disk /dev/sda: 120.0 GB, 120060444672 bytes 255 heads, 63 sectors/track, 14596 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 124902893+ fd Linux raid autodetect /dev/sda224912614 996030 fd Linux raid autodetect /dev/sda32615973357183367+ fd Linux raid autodetect /dev/sda49734 1459639062047+ fd Linux raid autodetect Why, yes, I do have a mixed RAID array of /dev/hda and /dev/sda. Unusual, but it's what I have to play with at the moment. You didn't ask, but: cat /etc/mdadm/mdadm.conf: # MY 20041227 # does not work on reboot without conf file # try telling it to look for /dev/sda DEVICE /dev/sda* /dev/hda* # if this doesn't work, try ARRAY as well # ARRAY /dev/md1 devices=/dev/sda1,/dev/hda1 # ARRAY /dev/md2 devices=/dev/sda2,/dev/hda2 # ARRAY /dev/md3 devices=/dev/sda3,/dev/hda3 ARRAY /dev/md/1 devices=/dev/sda1,/dev/hda1 ARRAY /dev/md/2 devices=/dev/sda2,/dev/hda2 ARRAY /dev/md/3 devices=/dev/sda3,/dev/hda3 Ugly, but once it started working, I was reluctant to touch it. Please let me know if you need any additional information or need me to perform any testing. -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe "There was an crash on the expressway this morning. Fortunately, all the traffic was backed up." -- Eli Yudkowsky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355580: initramfs-tools: fails to load required modules, boot fails
Package: initramfs-tools
Version: 0.53
Severity: important
Tags: patch
Three problems: no installation of module; no loading of "linear" module in md;
using mdrun in scripts/local-top/md give incorrect md modules.
The hook function "manual_add_modules" uses modprobe to find the actual module
to load. Unfortunately, possibly due to an error in modprobe, this leads to
modules not being loaded.
My RAID1 and LINEAR-based system had the following line in /etc/modprobe.d/md:
install md_mod /sbin/modprobe sata_promise; /sbin/modprobe --ignore-install
md_mod
When I run
# modprobe --set-version=2.6.15-1-k7 --show-depends md_mod
I get the result
install /sbin/modprobe sata_promise; /sbin/modprobe --ignore-install md_mod
but *no* insmod. Therefore, when this is run during mkinitramfs, the module
md_mod is not installed. I realize that although modprobe documentation leads
one to believe that there will be an insmod line printed, in fact there is not
such line printed.
The patch: add "--ignore-install" to the modprobe line in manual_add_modules:
modprobe --ignore-install --set-version="${version}" --show-depends "${1}"
this produces a line with "inmod".
The next problem wtih initramfs-tools is for md specifically. First of all,
some mischevious person has renamed the "md" module to "md-mod". This means the
distribution hook hooks/md is out of date, because it attempts to load md.
Secondly, that script also failes to load "linear".
Current fragment:
for x in md raid0 raid1 raid5 raid6; do
manual_add_modules ${x}
done
New fragment:
for x in md_mod linear raid0 raid1 raid5 raid6; do
manual_add_modules ${x}
done
Now, as for scripts/local-top/md, I have found that "mdrun" attempts to start
/dev/md/0, even though there is no such device on my system. I have /1, /2, and
/3, but not /0. I have not been able to debug mdrun.
Instead of using mdrun, I use the following:
In scripts/local-top/md:
mkdir /dev/md # --auto requires this directory pre-exist
/sbin/mdadm --assemble --scan --auto=md --config=/etc/mdadm/mdadm.conf
And in hooks/md I add the line:
cp /etc/mdadm/mdadm.conf ${DESTDIR}/etc/mdadm/mdadm.conf
This has the added advantage that *only* the devices that are actually needed
are created in /dev/md, instead of dozens of devices that aren't used. udev
automatically creates the link between /dev/mdN and /dev/md/N.
Please feel free to write for clarifications or further tests.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages initramfs-tools depends on:
ii busybox 1:1.01-4 Tiny utilities for small and embed
ii cpio 2.6-10 GNU cpio -- a program to manage ar
ii klibc-utils 1.2.2-3small statically-linked utilities
ii udev 0.086-1/dev/ and hotplug management daemo
initramfs-tools recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340486: Unable to compile modules, fixdep.c required
At 23:04 2005-12-03, Jurij Smakov wrote: Hi, After a discussion with kernel-package maintainer, we came to the conclusion that it's a kernel-package problem. It was trying to run oldconfig target for the kernel in the linux-headers directory, which does not contain enough files for this to succeed. The fixed kernel-package (10.012) has appeared in unstable today, and should take care of the problems you are encountering. Please give it a spin and post the results to the bug trail. Jurij, I downloaded the lastest kernel-package from unstable today, and I was able to compile for both 2.6.12-1-k7 and 2.6.14-2-k7. In both cases, I used "ln -s 2.6. linux; cd linux; make-kpkg modules" to perform the compilation. And the compliations result in usable, working copies of the modules I tried to compile. In short, all's well and this bug can be closed. Regards, and thanks, Moshe -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA www.Disaggregate.com www.PebbleAndAvalanche.com [EMAIL PROTECTED] +1 773 764 8727 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341152: initrd-tools: unable to boot after replacing devfs with udev: kernel panic, unable to create null, no console
At 14:01 2005-11-28, Maximilian Attems wrote: On Mon, Nov 28, 2005 at 12:59:34PM -0600, Moshe Yudkowsky wrote: > I cannot get 2.6.12 or 2.6.12 to boot because of the transition from > devfs to udev, and the problem seems to lie with initrd. > initrd-tools is phasing out, if you use testing and udev 0.74 pick initramfs-tools 0.40 from unstable. if you use newer udev you need initramfs-tools 0.41 from debian mentors -> http://mentors.debian.net/debian/pool/main/i/initramfs-tools/ Ok, the answer turns out to be quite simple: I didn't have the correct console and null files in my /dev directory. IMO, this is a documentation problem, so let me document the fix. Here's how to transition from devfs to udev -- at least as far as booting. Introduction: There's a difference between devfs and udev. Devfs makes the "console" and "null" files available by the time the files are needed during the boot. udev starts later, so you must supply your own copy of /dev/console and /dev/null. Action: Therefore, before trying to boot using udev only, make certain you have a "console" and "null" file in /dev. Of course, if your system is running, you have these files now -- but the question is, were they part of the /dev directory, or did devfs put it there? Here's how to check. * First, mount the root directory someplace other than /, so that the /dev directory can be examined as a standalone -- so it can be seen as it looks without stuff that devfs puts there. As root, issue the command: # mount -o bind / /mnt (where /mnt is some random mouting point). * Next, look at /mnt/dev. You need to have two special files there, console and null: crw--- root root 5, 1 Nov 28 16:50 console crw-rw-rw- root root 1, 3 Nov 28 16:51 null If you have them already, you're all set. On my system, I had "null" and it was *not* a "c" (special character) file; it was an ordinary file. I got rid of that file and issued the following commands to create console and null: # mknod -m 660 console c 5 1 # mknod -m 660 null c 1 3 * Unmount the / file system: # umount /mnt. * Make certain you have udev! 2.6.14-2 requires udev to boot, but you are responsible for actually installing udev. * Once /dev/console and /dev/null exist, you can boot using udev only. (For example, on my system, a boot using udev only is done by removing the "devfs=mount" command from lilo.) There's other stuff to do to convert completely to udev, but this gets you started. -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA www.Disaggregate.com www.PebbleAndAvalanche.com [EMAIL PROTECTED] +1 773 764 8727 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341152: initrd-tools: unable to boot after replacing devfs with udev: kernel panic, unable to create null, no console
Package: initrd-tools Version: 0.1.84 Severity: important I cannot get 2.6.12 or 2.6.12 to boot because of the transition from devfs to udev, and the problem seems to lie with initrd. The symptom: * when I boot using devfs=mount, the boot succeeds. I get a "cannot umount /proc/mount" message but the boot continues. * when devfs is not running, at about the same point I get a "cannot create null," followed by a "cannot open dev/console," followed by a "Kernel panic" and "Attempting to kill init" message. Notes: When I look at the initrd-img, I notice that there's a "devfs" directory as well as a dev directory. The contents pf the /dev directory are: lrwxrwxrwx 1 root root 14 Dec 31 1969 cciss -> ../devfs/cciss crw--- 1 root root 5, 1 Dec 31 1969 console lrwxrwxrwx 1 root root 12 Dec 31 1969 ida -> ../devfs/ida drwx-- 1 root root 20 Dec 31 1969 ide lrwxrwxrwx 1 root root 15 Dec 31 1969 mapper -> ../devfs/mapper drwx-- 1 root root 32 Dec 31 1969 md crw-rw-rw- 1 root root 1, 3 Dec 31 1969 null drwx-- 1 root root 20 Dec 31 1969 scsi so the console should be available on init, if I understand what's going on (and perhaps I do not). There's nothing in the /devfs directory in the initrd-img. Now, it's entirely possible that this is all a stupid user trick: I got udev running by adding it into my system, but I didn't do anything else, such as a "rm -r" on my /dev directory. I have the compatibility rules package for udev running, so I see "vc/*" and the tty packages when I boot using devfs=mount. If anyone has any hints or tricks that might fix this problem, or needs further data, please let me know. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.93-5 The GNU core utilities ii cpio 2.6-9 GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.2-8The Debian Almquist Shell ii fileutils 5.93-5 The GNU file management utilities ii util-linux2.12p-8Miscellaneous system utilities initrd-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337293: Problem is with udev and with 2.6.14
I've been working with this problem over the weekend, and I have the following facts to add to the mix. (1) As far as I can tell, this is a problem with udev, not with 2.6.14 only. I tried to boot my machine using udev on 2.6.12, and ran into what seems to be the same problem: /sbin/init: 432 cannot create /dev/null /sbin/init: 433 cannot open dev/null Kernel-panic etc. I view this as a migration problem from devfs to udev. If there's clear instructions on how to accomplish a migration, I don't know what they are. (2) I was able to install 2.6.14 *without* having udev installed! Since 2.6.14 seems to rely on udev and yaird, I believe udev should be a depedency of 2.6.14. (3) I thought that perhaps the problem was DELAY=10 in my mkinitrd.conf; but I tried building 2.6.12 using DELAY=0, and I still bomb out. I frankly am perplexed by this problem. My /dev is completely cluttered with everything that devfs created, I have a /dev/.static directory with console, null, and zero present, yet I can't seem to boot under udev. I wonder if the problem is that devfs is attempting to come up before udev? -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA www.Disaggregate.com www.PebbleAndAvalanche.com [EMAIL PROTECTED] +1 773 764 8727 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340486: linux-headers-2.6.14-2-k7: Unable to compile modules, fixdep.c required
Jurij, I am re-sending this email because I just checked the bug report and I do not see it listed -- so I assume it went astray. That's probably my fault, even though I would think that if Makefile would be written correctly, and fixdep binary already present (and it is present), then it would not try to rebuild it. Can you please confirm that it builds fine if you remove scripts/basic/Makefile? I should have included this in the original report -- that's the first thing I tested. When I remove "Makefile" from the script/basic directory, the "make-kpgk" fails with a complaint that there's "no fule to make target" scripts/basic/Makefile. I just tried this again with the latest linux-headers release, 2.6.14-4, and I have the same problem: complilation fails with or without the script/basic/Makefile. Please let me know if you need any further information. -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA www.Disaggregate.com www.PebbleAndAvalanche.com [EMAIL PROTECTED] +1 773 764 8727 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340486: linux-headers-2.6.14-2-k7: Unable to compile modules, fixdep.c required
Package: linux-headers-2.6.14-2-k7 Version: 2.6.14-3 Severity: serious Justification: no longer builds from source I am attempting to build my modules for 2.6.14-2-k7, and this fails. The failure is because the Makefile in /scripts/basic attempts, incorrectly (AFAICT) to build "fixdep" instead of using the "fixdep" that is already in the directory: linux# make-kpkg modules /usr/bin/make\ ARCH=i386 oldconfig make[1]: Entering directory `/usr/src/linux-headers-2.6.14-2-k7' HOSTCC scripts/basic/fixdep gcc: scripts/basic/fixdep.c: No such file or directory gcc: no input files make[2]: *** [scripts/basic/fixdep] Error 1 make[1]: *** [scripts_basic] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.14-2-k7' make: *** [stamp-kernel-configure] Error 2 I am attempt this build with /usr/src/linux as an alias for linux-headers-26.14-2-k7, but the build itself is being carried out under 2.6.12. Please note that I'm simply following the same procedure I've always followed to build modules. Previous versions of linux-headers did NOT have a Makefile in the scripts/basic directory. I realize that there's probably a simple fix for this, but unravelling the *intent* of a Makefile is a little tricky at times... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-headers-2.6.14-2-k7 depends on: ii linux-headers-2.6.14-22.6.14-3 Common header files for Linux kern linux-headers-2.6.14-2-k7 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337293: Same problem with linux-image-2.6.14-2-k7
I attempted to use linux-image-2.6.14-2-k7, and I have the same problem others reported. Here's the symptoms: After a normal install of the kernel, the system built an appropriate initrd.img -- using yaird, which installed along with the new kernel. I rebooted the system. I got the same message as Bruno did, to the best of my recollection: /usr/lib/yaird/exec/run_init: opening console: No such file or directory Kernel panic _ not syncing: Attempted to kill init Ok, I figured it was a problem with RAID, SATA, or something similar, so I rebuilt /boot/initrd.img.2.6.14-2-k7 using mkinitrd. When I tried that image, boot also failed, this time with a complaint about dev/console. I am using devfs. (Until I have an opportunity to figure out how that udev replacement technology works; I haven't seen a conversion how-to yet.) I read the notes in the bug report response that state: Underneath the tmpfs mounted on /dev is the /dev/ that is part of your root device. but I don't understand this at all. How does remounting / under /mnt help me find /dev/.static? What tmpfs fs -- the devfs fs? In any case, I get "null" under /mnt/dev when I attempt to mount, and no .static directory. I am currently running 2.6.12-1-k7, which is that I used to build initrd.img (both mkinitrd and yaird versions). Jonas, if you would like me to rebuild initrd.img using yaird and place it online somewhere, please let me know and I shall. And I'd appreciate any help. -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe "He will win who knows when to fight and when not to fight." -- Sun Tzu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
