Bug#332824: missing ide-generic
On Fri, 2005-12-23 at 14:34 +0100, maximilian attems wrote: > please try the attached patch, > should load ide-generic even if udev didn't yet bring it up: > patch -p1 /usr/share/initramfs-tools/scripts/init-premount/udev < > ide-generic.udev.patch > > for this trial please remove any ide-generic or ide-disk > out of /etc/mkinitramfs/modules, then update-initramfs -u > and reboot, > if it doesn't work out you still need to modprobe manually > ide-generic and disc.. > > thanks for your feedback. The patch works for me. -Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332824: synlink strangeness with chroot
On Fri, 2005-12-23 at 01:17 +0100, Goswin von Brederlow wrote: > Jonathan Brandmeyer <[EMAIL PROTECTED]> writes: > > When you follow the FAQ directions to add an ia32 chroot's lib > > directories to /etc/ld.so.conf[1], ldconfig causes vgchange's dependency > > on libncurses.so.5 to appear to be satisfied using > > $(chroot_path)/usr/lib/libncurses.so.5[2], which is itself a symlink. > > Is that symlink absolute and thereby broken? Eventually, yes. (identical in ia32 or amd64) /usr/lib/libncurses.so.5 -> libtermcap.so /usr/lib/libtermcap.so -> libncurses.so /usr/lib/libncurses.so -> /lib/libncurses.so.5 /lib/libncurses.so.5 -> libncurses.so.5.5 > > Weirdly, file -L /mnt/root32/usr/lib/libncurses.so.5 prints > > ... ELF 64-bit LSB shared object, AMD x86-64 ... > > Which would indicate it links to /lib/libncurses.so* instead of > ../../lib/libncurses.so*. This might be a more common problem. This isn't fully comprehensive, but it looks like only a handful of core libraries are affected in this way. This is from a desktop system, running GNOME with a few extra GTK and QT apps. $ for i in /mnt/root32/usr/lib/* ; do file -L $i | grep AMD ; done /mnt/root32/usr/lib/libanl.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libBrokenLocale.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libcidn.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libcom_err.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libcrypt.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libcurses.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libdl.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libe2p.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libext2fs.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libm.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libncurses.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libncurses.so.5: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libnsl.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libnss_compat.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libnss_dns.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libnss_files.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libnss_hesiod.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libnss_nisplus.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libnss_nis.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libpamc.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libpam_misc.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libpam.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libpopt.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libresolv.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/librt.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libtermcap.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libthread_db.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /mnt/root32/usr/lib/libutil.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332824: synlink strangeness with chroot
Cross-posting to the BTS since its relevant to this bug, and might lead to closing it out. I am running a Debian Sid AMD64 root partition alongside a full Sid i386 partition. Right now, the 32-bit partition is used mostly as a chroot to run openoffice and mplayer, using the directions on the Debian AMD64 howto. I also use it as a full desktop install as a backup. All of my "partitions" are managed using LVM. vgchange, which is used to initialize LVM in an initramfs, depends on libncurses.so.5 (the binary for vgchange is actually located at /lib/lvm-200/lvm). When you follow the FAQ directions to add an ia32 chroot's lib directories to /etc/ld.so.conf[1], ldconfig causes vgchange's dependency on libncurses.so.5 to appear to be satisfied using $(chroot_path)/usr/lib/libncurses.so.5[2], which is itself a symlink. When mkinitramfs builds the initramfs, it dereferences that symlink and places the dereferenced file into the same location in the initramfs image (eg, /mnt/root32/usr/lib/libncurses.so.5). Since that location is not on the library search path in the initramfs, vgchange fails to run, the root fs cannot be found, and the system fails to boot. There's a whole lot of strangeness going on here (at least to me), so I ask the experts: Which package(s) is/are at fault? Should the HOWTO be changed to not recommend adding the chroot's libs to /etc/ld.so.conf? Thanks, -Jonathan [1] Mine looks like this: /usr/X11R6/lib # chroot i386 libs /mnt/root32/lib /mnt/root32/usr/lib /mnt/root32/usr/X11R6/lib [2] ldd /lib/lvm-200/lvm returns: libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x2abc3000) libreadline.so.5 => /lib/libreadline.so.5 (0x2acd4000) libselinux.so.1 => /lib/libselinux.so.1 (0x2ae13000) libdl.so.2 => /lib/libdl.so.2 (0x2af26000) libncurses.so.5 => /mnt/root32/usr/lib/libncurses.so.5 (0x2b029000) libc.so.6 => /lib/libc.so.6 (0x2b186000) /lib64/ld-linux-x86-64.so.2 (0x2aaab000) Weirdly, file -L /mnt/root32/usr/lib/libncurses.so.5 prints ... ELF 64-bit LSB shared object, AMD x86-64 ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332824: fixed udev -> fixed initramfs-tools?
On Wed, 2005-12-21 at 10:07 +0100, David Härdeman wrote: > Jonathan Brandmeyer wrote: > > /dev/mapper is empty except for control > > Does running "vgscan" Does not exist in the initramfs. > and/or "vgchange -ay" from the initramfs shell create > any nodes in /dev/mapper? Yes it does. However, to get it to run, I had to manually copy libncurses.so.5 from /mnt/root32/usr/lib/. /mnt/root32 is the path to my normally mounted 32-bit chroot environment. The version of libncurses.so.5 that is present in the initramfs is built for AMD64 (according to file). By moving the file in the initramfs image itself, the system could successfully boot! So, there is some kind of bug that mismanages libncurses.so.5 when building the initramfs. -Jonathan
Bug#332824: fixed udev -> fixed initramfs-tools?
On Tue, 2005-12-20 at 16:22 +0100, David Härdeman wrote: > Jonathan Brandmeyer wrote: > > So, what do I need to edit to fix this? Alternatively, > > what command should I try to run after modprobing in > > ide-disk and ide-generic? > > The problem is that ide-disk and ide-generic are not loaded when dm-mod is > loaded so when it performs its initial device scan it skips the ide discs. Using the still-working 32-bit side of the system, I managed to find what the difference is between having and not having ide-disk and ide-generic in /etc/mkinitramfs/modules. Modules in that list are added to /conf/modules in the ramfs image. So, that is what I did to /conf/modules in the 64-bit initramfs image. The boot still fails, but in a different manner. The last few messages includes a modprobe usage error followed by: mount: Cannot read /etc/fstab: No such file or directory Begin: Running /scripts/log-bottom ... Done. Done. Begin Running /scripts/init-bottom mount: Mounting /root/dev on /dev/.static/dev failed: No such file or directory (more failures to mount /sys and /proc) Target filesystem doesn't have /sbin/init (enters Busybox ash) mount returns: none on /sys none on /proc udev on /dev /dev/mapper is empty except for control /proc/modules includes forcedeth ehci_hcd ohci_hcd thermal processor fam ide_cd cdrom dm_mod sd_mod ide_generic ide_disk sata_nv libata scsi_mod amd74xx ide_core According to dmesg the IDE cdroms (hdc, hdd) and SATA hard drives (sda, sdb) are all detected before dm_mod is loaded. All of the relevant partitions for the hard drives show up under /dev > The easiest workaround until the bug is properly fixed is the one suggested by > Maximilian (i.e. add the modules to /etc/initramfs/modules and regenerate the > image). The devices should then be present when dm-mod is loaded which should > generate the lvm nodes. Except that I CANNOT DO THIS because the system is unbootable. -Jonathan
Bug#332824: fixed udev -> fixed initramfs-tools?
On Tue, 2005-12-13 at 00:12 +0100, Maximilian Attems wrote: > On Mon, Dec 12, 2005 at 11:33:06AM -0500, Jonathan Brandmeyer wrote: > > On Wed, 2005-11-30 at 19:18 +0100, maximilian attems wrote: > > > please retest with latest initramfs-tools in unstable aka version 0.41. > > > it needs latest udev 0.76-3 too. > > > the various seen timing bugs should be fixed thanks to newer udev. > > > > 0.41 with udev 0.076-4 works. However, the latest upgrade to 0.42 with > > udev 0.076-6 rendered my AMD64 partition unbootable, so I am avoiding > > the upgrade on my IA32 partition. > > > > 0.42 fails to find the root fs, and kicks me out to a busybox > > shell. /dev/mapper/control exists (recall that I'm running root on > > LVM), but none of the logical volumes are available. > > > > As a wishlist item, this shell doesn't have either "halt", "reboot", or > > "shutdown" - you have to Ctrl-Alt-Del to restart the system. > > latest udev might not bring up ide-disk or/and ide-generic, > due to a debian kernel bug. > add them to /etc/initramfs/modules and update-initramfs -u > > also an output of the loaded modules from the shell would help > to tell what your trouble is aka cat /proc/modules. I can confirm that ide-disk and ide-generic are not being loaded, however they are present in the initrd. I can modprobe them in manually from the busybox shell (however, /dev/mapper/ does not get populated when I do so). I can also edit any file in the initrd using g[un]zip and cpio. However, I cannot simply run update-initramfs since I cannot boot the 64-bit system. So, what do I need to edit to fix this? Alternatively, what command should I try to run after modprobing in ide-disk and ide-generic? Thanks, -Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332824: fixed udev -> fixed initramfs-tools?
On Wed, 2005-11-30 at 19:18 +0100, maximilian attems wrote: > please retest with latest initramfs-tools in unstable aka version 0.41. > it needs latest udev 0.76-3 too. > the various seen timing bugs should be fixed thanks to newer udev. 0.41 with udev 0.076-4 works. However, the latest upgrade to 0.42 with udev 0.076-6 rendered my AMD64 partition unbootable, so I am avoiding the upgrade on my IA32 partition. 0.42 fails to find the root fs, and kicks me out to a busybox shell. /dev/mapper/control exists (recall that I'm running root on LVM), but none of the logical volumes are available. As a wishlist item, this shell doesn't have either "halt", "reboot", or "shutdown" - you have to Ctrl-Alt-Del to restart the system. -Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332824: linux-image-2.6.13-1-686: Cannot find LVM root fs
On Sun, 2005-10-09 at 10:20 +0200, Sven Luther wrote: > On Sat, Oct 08, 2005 at 08:30:42PM -0400, Jonathan Brandmeyer wrote: > Well, it works very well, and booted out of the box > > yaird-built pre-init image worked as well, and was smaller than the > > initramfs image (1.6 MB vs 5.4 MB). > > He nice, comparison, i suppose you need to drop the default "MODULES=most" > option of initramfs-tools and use MODULES=dep. Can we now please try to > default to MODULES=dep ? If we don't do it we will again be saddled with > MODULES=most for etch. When I tried that, I got a bunch of errors: ln: `/tmp/mkinitramfs_IJobWs/./modprobe': File exists ln: `/tmp/mkinitramfs_IJobWs/./modprobe': File exists ln: `/tmp/mkinitramfs_IJobWs/./modprobe': File exists ln: `/tmp/mkinitramfs_IJobWs/./modprobe': File exists ln: `/tmp/mkinitramfs_IJobWs/./modprobe': File exists cpio: ./modprobe: Too many levels of symbolic links Working files in /tmp/mkinitramfs_IJobWs and overlay in /tmp/mkinitramfs-OL_loyqMq and an image that was still 5.1 MB. -Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332824: linux-image-2.6.13-1-686: Cannot find LVM root fs
On Sat, 2005-10-08 at 23:04 +0200, Frederik Schueler wrote: > Hello, > > can you please try building the initrd with initramfs-tools and see if > that works? I manually built an initramfs with: # mkinitramfs -o /boot/initrd.img-2.6.13-1-686 2.6.13-1-686 && lilo and rebooted. The system successfully booted with the exception that udev did not setup the nvidia /dev entries, and X would not start. This was successfully worked around using the solution presented in http://lists.debian.org/debian-amd64/2005/09/msg00827.html > And if you have the time, do the same check with an initrd > built using yaird? The double-zero version number and package comment "At the moment, yaird is lightly tested" are not confidence-inspiring. Nonetheless the yaird-built pre-init image worked as well, and was smaller than the initramfs image (1.6 MB vs 5.4 MB). > 2.6.13 has no devfs anymore, which breaks initrd in some cases, like > yours. OK. Thanks, -Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332824: linux-image-2.6.13-1-686: Cannot find LVM root fs
Package: linux-image-2.6.13-1-686 Version: 2.6.13-1 Severity: important When booting this kernel image, the kernel cannot find the LVM2 partitions and fails to find the root fs. The Debian 2.6.12-1-686 kernel boots normally. The last few console messages are: mkdir: cannot create director '/devfs/vg0': Read-only filesystem mount: unknown filesystem type 'devfs' Unable to find volume group "vg0" umount: /dev: not mounted umount: devfs: not mounted mount: unkonwn filesystem type 'devfs' NTFS driver 2.1.23 [Flags: R/W MODULE]. umount: devfs: not mounted pivot_root: No such file or directory /sbin/init: 432: cannot ope dev/console: No such file Kernel panic - not syncing: Attempted to kill init! -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6.13-1-686 depends on: ii initrd-tools 0.1.82 tools to create initrd image for p ii module-init-tools 3.2-pre9-1 tools for managing Linux kernel mo linux-image-2.6.13-1-686 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
