Bug#904926: cryptroot-unlock: timeout waiting for askpass
Am Sonntag, 29. Juli 2018, 18:46:20 CEST schrieb Guilhem Moulin: > readlink -f /lib/cryptsetup/askpass readlink returns: /lib/cryptsetup/askpass Regards, C. Dominik Bódi signature.asc Description: This is a digitally signed message part.
Bug#800445: nf_conntrack: table full, dropping packet
severity: grave I've got the same problem on my debian unstable system. I'm running shorewall, as well. 4.1 kernels seem to run fine but the latest 4.2 kernel in unstable shuts the firewall completely. I'm seeing the same error messages in dmesg, as well. This makes a server unusable, as the firewall effectively shuts down all networking. Thus the severity of this bug report should be raised to "grave" Regards, C. Dominik Bódi signature.asc Description: This is a digitally signed message part.
Bug#790249: [Re:] mysql-server: Upgrade 5.5 to 5.6 fails
Indeed, after installing systemd on that machine and booting with init=/bin/systemd the upgrade was successful. The error does seem to get triggerred by /etc/init.d/mysql when starting manually, the script complains somewhat cryptically about not finding the HOME dir and setting HOME=/ The daemon does start, though but I guess apt sees it as an error and thinks mysql was not started successfully. When using systemd, the init script is not used and mysql_safe is started directly using the provided systemd service file /lib/systemd/system/mysql.service It seems the upgrade path doesn't work when there is the old sysvrc init installed, so mysql-server-5.6 should either explicitly depend on systemd or the init script needs to be modified. Regards, Dominik signature.asc Description: This is a digitally signed message part.
Bug#790249: [Re:] mysql-server: Upgrade 5.5 to 5.6 fails
I've got the same problem. One one machine, the upgrade was successful, on the other it failed. The machine failing the upgrade, old sysvinit was still the installed init system. On the machine that did the upgrade successfully, systemd is the installed init system. Regards, Dominik signature.asc Description: This is a digitally signed message part.
Bug#783986: ifupdown does ignore post-up lines for static ipv6
Am Samstag, 6. Juni 2015, 23:12:14 schrieb Guus Sliepen: > The post-up lines are executed for static ipv6 interfaces, but not if > something went wrong while configuring the interface. One issue is that > ifupdown assumes the kernel is performing Duplicate Address Detection in > a timely fashion, and only considers the interface properly up if the > kernel completes DAD. It could be that at boot time this doesn't work. > Try adding "dad-attempts 0" to the iface eth0 stanza, and see if that > makes a difference. Sorry about the late reply, I had been away on a trip abroad and did not have access to that machine. I've tried your hint setting dad-attempts 0 in /etc/network/interfaces. That did not change anything, however. One thing i forgot to add, though, is, that this machine has its disk encrypted with luks and I am using mandos-client to unlock the disks during early userspace (i.e. mandos-client is run from initrd). mandos-client brings up the network interface in question to receive the password for the luks volume. Having looked at the logs, it seems that the interface is not taken down before early userspace is finished. The system still manages to set up the static addresses right, but the additinal "up" stanza does not get executed. I've also tried the other way of configuring additional addresses as described in the debian wiki, by adding eth a third time, configuring the additional ULA address in the third interface config section. The result was the same, though, the additional address did not get set up at boot time. Regards, Dominik signature.asc Description: This is a digitally signed message part.
Bug#707831: UUID detection code broken, wrongly uses UUID
This bug affects wheezy as well. I just had trouble booting a wheezy system after adding a second Physical Volume to my LVM setup. The workaround is setting GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub That will make boot again as it will use the root=/dev/mapper/nameofrootlv for the kernel cmdline in /boot/grub/grub.cfg I'm still getting those errors when doing an update-grub: "physical volume pv0 not found" (many of them) Not using the workaround in advance will kill remote servers, if you don't have access to a KVM console, spice or anything to fix the kernel cmdline in grub's boot menu manually, though. The machine affected is a KVM/quemu VM instance. That machine is using virtio disks, thus I'm having /dev/vda, /dev/vdb and so on. I've noticed that udev does not generate devices nodes for virtio disks in /dev/disk/by-id nor /dev/disk/by-uuid . Perhaps this is why grub is having trouble finding those disks. Additionally, this might be a corner case when one is using a complete unpartitioned disk as LVM Physical Volume, as the second PV I've added to the system is an unpartitioned virtio disk. Strangely enough, on another KVM/qemu VM running unstable (acutally running on the same host as the wheezy VM), but having a similar virtio disk setup, everything is fine. I'm seeing the virtio disk nodes in /dev/disk/by-id and grub is not complaining about not having found PVs, either. I'd likt to ask to re-open this bug, as this still affects wheezy. I'd kindly request a fix backported to wheezy, as well. Thank you. Regards, Dominik Bódi signature.asc Description: OpenPGP digital signature
Bug#766376: [dma] dma does not remove /var/spool/dma after purging package
Package: dma Version: 0.9-1 Severity: minor After purging dma I discovered that /var/spool/dma did still exist. dma should remove that directory after being purged. Regards, C. Dominik Bódi signature.asc Description: OpenPGP digital signature
Bug#764258: mandos-client loops forever waiting for server
Package: mandos-client Version: 1.6.9-1 Severity: grave Justification: renders package unusable Hello, mandos-client stopped working after having updated to mandos-client 1.6.9-1. Running the client as described in READE.Debian.gz, with --debug enabled shows that the client actually seems to communicate with the server, but then shows the following debug messages: Mandos plugin mandos-client: Check current_server if we should run it, or wait Mandos plugin mandos-client: Blocking for 1 ms It then waits for 10 seconds, talks with the server again, shows the same "waiting" message again and thus loops around forever. The mandos-monitor on the server never says that the client "received its secret", though. The server runs 1.6.9-1 , as well. I can provide detailed logs if you need those, I'm hesitant to post those here, as they might contain private key data. Regards, C. Dominik Bódi -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0-monster-1 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mandos-client depends on: ii adduser3.113+nmu3 ii cryptsetup 2:1.6.6-1 ii dpkg-dev 1.17.16 ii gnupg 1.4.18-4 ii initramfs-tools0.118 ii libavahi-common3 0.6.31-4 ii libavahi-core7 0.6.31-4 ii libc6 2.19-11 ii libgnutls-deb0-28 3.3.8-2 ii libgpgme11 1.5.1-6 Versions of packages mandos-client recommends: pn ssh mandos-client suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760988: linux-image-3.16-1-amd64 fails to boot with lvm luks - kernel panic
I've tried the new 3.16-2 kernel today. That one works without problems. Feel free to close this bug report. Regards, Dominik signature.asc Description: OpenPGP digital signature
Bug#760988: linux-image-3.16-1-amd64 fails to boot with lvm luks - kernel panic
Unfortunately, I did not think of making a foto of the messages. I've tried that new kernel on my "real" machines at home, there it booted without problems. Both machines are using luks and lvm. One is unlocked manually, the other via mandos in my LAN. Both machines booted the 3.16-1 kernel without problems. It seems that this specific VM setup might somehow play into this. All I know it is a ganeti/kvm setup running with -cpu host. Thus I'm not seeing the "qemu" cpu in /proc/cpu info but the real one. Unfortunately, I cannot contact the admin of the vm's host computer 24/7. I'll BCC'ed him this email and perhaps he has an idea what might be causing this. We might be able to retry this in a few days. Then I'll try to get a screenshot of the messages. Regards, Dominik Am 09.09.2014 um 20:10 schrieb Ben Hutchings: > Control: severity -1 import > Control: tag -1 moreinfo > > On Tue, 2014-09-09 at 19:43 +0200, C. Dominik Bodi wrote: >> Package: src:linux >> Version: 3.16.2-2 >> Severity: critical >> Justification: breaks the whole system >> >> I've got a debian unstable system running in a ganeti/kvm vm that runs >> with lvm. The physical volume the root file system resides on is >> encrypted with luks. I've installed dropbear to unlock the luks volume >> via ssh, using a kernel cmdline ip=... in /etc/grub/default >> >> Up and including linux-image-3.14-2-amd64 this worked flawlessly. >> >> However, having installed and booted from 3.16-1, the kernel panics >> after unlocking the luks volume. There were some error messages about >> /dev/pts and/or /dev not being mounted successfully, but as the kernel >> panicked, the busybox console (accessed via spice) was frozen and I had to >> ask the admin >> admin to hard-reset the machine for me. >> >> The 3.14-2 kernel continues to boot normally, >> >> I'm a bit at loss what might cause 3.16 to panic but 3.14 to boot >> successfully. Unfortunately I cannot hard-reset the machine myself >> (spice remote-viewer does not to support hard-reset signals to the vm) >> and I wasn't able to deduce anything from the few kernel panic lines >> on the console. > [...] > > But we might be able to. > > Ben. > signature.asc Description: OpenPGP digital signature
Bug#745554: php5-json is missing /usr/lib/php5/20121212/json.so
Package: php5-json Version: 1.3.4-2 Severity: grave php5-json 1.3.4-2 is missing /usr/lib/php5/20121212/json.so, completely breaking the package and making everything dependent on this package unusable. This effectively breaks php5 with apache on Debian sid. Downgrading to 1.3.3-1 fixes this problem. Regards, C. Dominik Bodi signature.asc Description: OpenPGP digital signature
Bug#742218: [burp] burp initscript is missing exit 0 statement at end of file
Package: burp Version: 1.3.48-2 Severity: grave --- Please enter the report below this line. --- /etc/init/burp used to have a colon ":" at the last line of the file, which seems to be a short form for "exit 0" in sh. That line with the colon went missing in burp-1.3.48-2. When VERBOSE is set to no or commented out in /etc/default/rcS, this makes invoke-rc.d think that the init script failed. This leads to apt-get failing to configure the package, which will rest in a half-installed state. Regardless of that, the burp server will start successfully if configured accordingly in /etc/default/burp. I'm not familiar with the debian policy on initscripts, but should an init script not have an exit 0 at the end of the file? Regards, C. Dominik Bódi signature.asc Description: OpenPGP digital signature
Bug#665441: mp3splt-gtk: Refuses to start for mixing GTK+ 2.x and 3 libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I've got the same problem with debian unstable amd64. The reason for that behaviour is a link conflict between the mp3splt-gtk binary and its dependency, libaudcore1. mp3splt-gtk is linked against libgtk-2.0-0 and libaudcore1. However, libaudcore1 is linked against libgtk-3-0. Gtk does not permit linking against 2.0 and 3.0 in the same executable, though. Either mp3splt-gtk should link against libgtk-3-0, or there should be a version of libaudcore that links against libgtk-2.0-0. Regards, Dominik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPgcS/AAoJEH57oErWeAO10C8QAIn6Ilq5nmIoEEpKrJ0lmUfc 6osPQ8vGUbvr48w22X/sK3kt9rttILlX5jWF9t80mXbHa/b7/BBZLYCqWdOJM4Hl PzvyXMxtw5WByeNSlVFqB1npEVKPsiHBTni3KHErOTCh7tGMP8c83ZWq/oxlzq3T IlBp/dWOlpGLK2j46C9t8R9zuubBxU7mCvguTHYac8Y5Xikg2RbcRSSqwSwrieiN UKbo1kc6FQYqIsK+mQLDRyGZV1p92vqUEUu9NxwjeCT36duci7mU4adWQgXueva2 gtbY81jn7BsK6GbHTNPsyFPXLZ7fWOzOxFviaWOQoCzolJZdsl8uVN6HEQ+/TkG6 ZN3Jool/GQJQfyL1trpvyYQuZ6PrhAenZA99AYad3Ti+oNYWFHdLSKgLqt9B+734 uLemRYDmVZWHavcdYHvSTdjSCn4jEAe8z1yE2WWXx2pYaaZuOAem54I8JJdcEm/7 /T4npLtbzofnDDBqyYXproM9llrGnbcHBd1nKGBD9EvSlIz7O9lBPQE8qdqaKv5z swMbPJZVe0ap4snHtdgQflTfkeLPBDja6jpo7Y4ls8hL5qPC1NQ/vvvqI9pPeSGp O/PgJ8lfAkHIQhshrgMzecpuO4vMmPhFjslUCoTChWWi4gxWxzP91192aSKxaeL8 Z5O7kce/FId5w4hiQi3+ =/Xwo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619424: [avahi-daemon] avahi-daemon does not use IPv6 anymore
Package: avahi-daemon Version: 0.6.29-1 Severity: normal --- Please enter the report below this line. --- Starting with 0.6.29-1, avahi-daemon stopped supporting IPv6. Checking the log files, I noticed that 0.6.28 joined mDNS multicast groups for IPv6 addresses, whereas 0.6.29 does not do so anymore. However, in /etc/avahi/avahi-daemon.conf the use-ipv6 option is set to yes by default. This breaks the mandos server package, as it used IPv6 by default. With the defective avahi daemon, the mandos server will not advertise its availability anymore, making the mandos service useless. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.38-hengst-1 Debian Release: wheezy/sid --- Package information. --- Depends(Version) | Installed -+- libavahi-common3 (>= 0.6.16) | 0.6.29-1 libavahi-core7 (>= 0.6.24) | 0.6.29-1 libc6 (>= 2.4) | 2.11.2-13 libcap2(>= 2.10) | 1:2.20-1 libdaemon0 (>= 0.13) | 0.14-2 libdbus-1-3 (>= 1.1.1) | 1.4.6-1 libexpat1(>= 1.95.8) | 2.0.1-7 adduser | 3.112+nmu2 dbus (>= 0.60) | 1.4.6-1 lsb-base (>= 3.0-6) | 3.2-27 bind9-host | 1:9.7.3.dfsg-1 OR host | Recommends (Version) | Installed ==-+-=== libnss-mdns| 0.10-3.1 Suggests (Version) | Installed -+-=== avahi-autoipd| signature.asc Description: This is a digitally signed message part.
Bug#556968: [Pkg-openssl-devel] Bug#556968: libssl: please enable padlock engine for libssl on amd64
the output of "openssl engine padlock" is: 9385:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:162:filename(/usr/lib/ssl/engines/libpadlock.so): /usr/lib/ssl/engines/libpadlock.so: cannot open shared object file: No such file or directory 9385:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 9385:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 9385:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:415:id=padlock "openssl engine" show just one line: (dynamic) Dynamic engine loading support Regards, Dominik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549585: mandos-client: fails with: fatal: no entropy gathering module detected.
After having enabled the debug mode via plugin-runner.conf as you suggested. The "fatal" error occurs immediately after the first debug messages, which is: "Initializing GNUTLS" Then I booted the kernel with the break option and ran "sh scripts/init- premount/udev". Indeed, it seems that both /dev/random and urandom are readable only by user and group, respectively. Regards, Dominik Bodi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539270: [kdemultimedia] kde audio player software does not play files with whitespace in their filenames
Package: kdemultimedia Version: 4:4.2.4-1 Severity: important When a kde audio player program opens an audio file with a whitespace in a filename, the file does not get played. Depending on the player program, error messages vary or the song simply gets skipped. Amarok for instance, says the file was not found. Steps to reproduce the problem: 1. Run a program using the kde phonon backend to play audio, for instance amarok, juk, dragonplayer, kalarm 2. Open an audio file with a whitespace in its filename, the format does not matter, for instance: test file.flac, test file.ogg, test_file.mp3 If one renames the test file.ogg to test_file.ogg or testfile.ogg, the song plays normally. Programs not using the Phonon audio backend, e.g. smplayer or mpg123, do not suffer from this problem. This means, all audio files with whitespace in their filenames do not play in kde, not even in apps like kalarm etc. his severely hampers the audio playback capabilities of kde4. I wasn't sure which package is causing this problem, that's why I reported the bug report against kdemultimedia, although it might better to assign the report to phonon or qt4 instead. My system is a freshly in installed HP 6830s laptop. I've installed a minimal stable, upgraded to sid and installed desktop-base and kde4 afterwards. Don't hesitate to email me if you need any more information about my system. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.30-1-amd64 Debian Release: squeeze/sid 990 unstableftp.at.debian.org 850 unstabledebian-mirrors.sdinet.de --- Package information. --- Depends(Version) | Installed -+-=== dragonplayer (>= 4:4.2.4-1) | 4:4.2.4-1 kdemultimedia-kio-plugins (>= 4:4.2.4-1) | 4:4.2.4-1 juk (>= 4:4.2.4-1) | 4:4.2.4-1 kmix (>= 4:4.2.4-1) | 4:4.2.4-1 kscd (>= 4:4.2.4-1) | 4:4.2.4-1 Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#428669: dbus upgrade stops network-manager, drops network for the duration
I've got a laptop running network-manager with kde. Apt sources are nfs mounts with file:// urls. Upgrading dbus disconnects the cabled network, aptitude will then be unable to load and unpack packages from the network. A workaround exists: running dhclient eth0 re-starts the cabled network connection, one can re-start aptitude and resume the upgrade. Regards, C. Dominik Bodi signature.asc Description: This is a digitally signed message part.
Bug#433483: sun-java6-jre 6-01-1 uninstallable on amd64
I realise I made a mistake, I should have filed against version 6-00-2, because that's been completed by buildd n weeks ago and your explanation would be irrelevant. sun-java6-jre_6-00-2 was perfectly installable before the incomplete upgrade of 6-01-1. Now that the upgrade to 6-01-1 has only been uploaded into unstable incompletely, both the old and the new versions are broken. One can neither install 6-00-2 because deps are missing nore 6-01-1 because deps are missing. D'oh. I know "its only unstable" and such and one could get stuff from testing or experimental. However, in this case the new version isn't even in experimental. Same problem applies to sun-java5 and the new java-package simply sucks. Therefore at the moment there's no sane way to get java5/6 to work in amd64 unstable at all, and all that's caused by some rushed uploads. You should have a look at popcon, you might find that unstable actually is the version of debian used most often. Careless uploads like these do break packages in unstable all the time. What makes it annoying is that these kinds of breakages are easily preventable e.g. by delaying uploads and letting the stuff stay in experimental or incoming or wherever until all the binaries of one given source package have finished building. Regards, C. Dominik Bodi signature.asc Description: This is a digitally signed message part.
Bug#431123: aptitude: Initializing package states takes very much longer than before +b1
My three boxes running unstable have all been experiencing the same symptoms. Possibly, this might have something to do with the new 0.4.4-4+b1 having been built against the new apt 0.7.2 which recently entered unstable. Regards, C. Dominik Bodi signature.asc Description: This is a digitally signed message part.
Bug#427514: linux-image-2.6.21-1-amd64: System does not boot with 2.6.21-4
Since the same symptoms started to appear with the older 2.6.20 kernel as well, I have done some more investigation. Booting the kernel without initramfs: Mounting the root filesystem fails, although the hard disk with the root filesytem was recognised correctly. That is probably ok since the ext3fs drivers are built as a module I guess. Booting with initramfs: After some obscure error the initramfs shell pops up. Now, doing a mount /dev/hda8 /root fails with "invalid argument" Doing a mount -t ext3 /dev/hda8 /root worked and the root filesystem got mounted correctly. I simply exit'ed the shell and the system continued to boot normally. I've manually updated the initramfs using update-initramfs -k all -u but it did not help, booting still fails. Therefore the problem seems to be either some initramfs creation/update stuff or the mount program doesn't automatically recognise the filesystem type anymore. Regards, Dominik Bodi signature.asc Description: This is a digitally signed message part.
Bug#427514: (no subject)
Hi, I have a similar symptom with that kernel version on my laptop which might be caused by the same problem. I don't have any lvm/md/raid stuff on the laptop's disk, it boots from a normal partition. Booting without the initial ramdisk, the kernel prints the following error: VFS: cannot open root device "hda8" or unknown-block(0,0) Booting with the initial ramdisk I get error messages similar to those Jack reported. 2.6.20 works without problems. With kind regards, Dominik Bodi signature.asc Description: This is a digitally signed message part.
Bug#397936: (no subject)
1. According to the debmirror manpage pdiffs are used by default. 2. No, debmirror does not recover gracefully when pdiffs are used and ed is missing. It will fail with an error when it tries to patch the packages list. Sorry for the long delay, I did not receive your email, it got sent to "C. Dominik <[EMAIL PROTECTED]>"@informatik.uni-tuebingen.de instead. Regards, Dominik pgpXfoGQADxjv.pgp Description: PGP signature
Bug#397936: debmirror depends on ed
Package: debmirror Version: 20060907.1 Severity: important debmirror's pdiff processing ability depends on the package ed being installed. Patching the Packages list files will fail otherwise. Regards, Dominik -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.2-monster-1 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Versions of packages debmirror depends on: ii bzip2 1.0.3-6 high-quality block-sorting file co ii libcompress-zlib-perl 1.42-1 Perl module for creation and manip ii libdigest-sha1-perl 2.11-1 NIST SHA-1 message digest algorith ii liblockfile-simple-perl 0.2.5-7 Simple advisory file locking ii libwww-perl 5.805-1 WWW client/server library for Perl ii perl [libdigest-md5-perl] 5.8.8-6.1 Larry Wall's Practical Extraction ii perl-modules [libnet-perl] 5.8.8-6.1 Core Perl modules ii rsync 2.6.9-1 fast remote file copy program (lik Versions of packages debmirror recommends: ii gnupg 1.4.5-2 GNU privacy guard - a free PGP rep ii patch 2.5.9-4 Apply a diff file to an original -- no debconf information pgpoPvxXWUvLY.pgp Description: PGP signature
Bug#362631: linux-image-2.6.16-1: fails to mount root device
Yes, booting that kernel gets me into the rescue shell. All /dev/hda? partitions that should exist do so, as well. Here's a list of modules that are loaded: usbhid 8139too ide_cd cdrom ide_disk generic ohci1394 ieee1394 8139cp mii ehci_hcd ohci_hcd atiixp ide_core usbcore thermal processor fan I am using grub, with an extra partition /dev/hda7 set up as /boot. /proc/cmdline is root=/dev/hda8 ro lapic I did install debian again, once I had upgraded it to unstable, the same bug happened. I did keep the kernel from testing this time (see original report for version), which boots without having this problem. I tried something in the rescue shell: I mounted /dev/hda8 to /root manually using the following command: mount -t ext3 /dev/hda8 /root Then I exited the rescue shell and the system did boot normally. Regards, Dominik pgp4fKFzT5pkQ.pgp Description: PGP signature
Bug#362631: linux-image-2.6.16-1: fails to mount root device
Package: linux-2.6 Version: 2.6.16-6 Severity: critical Justification: breaks the whole system *** Please type your report below this line *** The kernel seems to boot up normally, but then fails to mount the root device with a message "failed to mount root on /dev/hda8 - no such device" according to dmesg logs I can see that hda gets initialised normally. I could not find any errors related to the initalisation of the ide controller or hard disk, either. Booting the kernel without the initial ramdisk fails with a kernel panic. The system used to work with version 2.6.16-5 or earlier. However, since the last upgrade was done on April 3rd 2006, I cannot remember the exact version of the linux-image package I upgraded from. Due to not having a backup kernel installed, I had to re-install the box from scratch and lost all apt/dpkg logfiles. I tried booting the linux-image-2.6.16-1-686 instead but bot the same error. -- System Information: Debian Release: testing/unstable APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-image-2.6.16-1-k7 depends on: ii initramfs-tools [linux-initra 0.59b tools for generating an initramfs ii module-init-tools 3.2.2-2tools for managing Linux kernel mo Versions of packages linux-image-2.6.16-1-k7 recommends: ii libc6-i6862.3.6-6GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.16-1-k7/preinst/initrd-2.6.16-1-k7: linux-image-2.6.16-1-k7/postinst/bootloader-test-error-2.6.16-1-k7: linux-image-2.6.16-1-k7/postinst/bootloader-error-2.6.16-1-k7: linux-image-2.6.16-1-k7/preinst/lilo-initrd-2.6.16-1-k7: true linux-image-2.6.16-1-k7/preinst/abort-overwrite-2.6.16-1-k7: linux-image-2.6.16-1-k7/preinst/bootloader-initrd-2.6.16-1-k7: true linux-image-2.6.16-1-k7/postinst/kimage-is-a-directory: linux-image-2.6.16-1-k7/postinst/old-initrd-link-2.6.16-1-k7: true linux-image-2.6.16-1-k7/postinst/depmod-error-2.6.16-1-k7: false linux-image-2.6.16-1-k7/prerm/would-invalidate-boot-loader-2.6.16-1-k7: true linux-image-2.6.16-1-k7/preinst/elilo-initrd-2.6.16-1-k7: true linux-image-2.6.16-1-k7/preinst/lilo-has-ramdisk: linux-image-2.6.16-1-k7/preinst/already-running-this-2.6.16-1-k7: linux-image-2.6.16-1-k7/prerm/removing-running-kernel-2.6.16-1-k7: true linux-image-2.6.16-1-k7/postinst/depmod-error-initrd-2.6.16-1-k7: false linux-image-2.6.16-1-k7/postinst/old-dir-initrd-link-2.6.16-1-k7: true linux-image-2.6.16-1-k7/preinst/overwriting-modules-2.6.16-1-k7: true linux-image-2.6.16-1-k7/postinst/create-kimage-link-2.6.16-1-k7: true linux-image-2.6.16-1-k7/postinst/old-system-map-link-2.6.16-1-k7: true linux-image-2.6.16-1-k7/preinst/failed-to-move-modules-2.6.16-1-k7: linux-image-2.6.16-1-k7/preinst/abort-install-2.6.16-1-k7: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
