On Tue, 2013-01-01 at 13:18 +0100, Hanno Hecker wrote: > On Tue, 1 Jan 2013 10:37:17 +0100 > Hanno Hecker <hah+deb...@uu-x.de> wrote: > > I'm not sure what happened, but I had to use the recovery boot to get a > > running system again. The watchdog did not trigger, so it stayed up, > > but it did not boot full, IIRC the only open port was 111/tcp > > (portmapper). No fsck was running. > I gave it another try, this time with dropbear in the initrd, same > problem... and dropbear seems to be started too late for this, i.e. I > could not connect to port 22.
I'm at a bit of a loss to explain this one, especially since the sid version apparently works OK (the initramfs hooks are identical between the test version and sid). Is there any chance that the issue comes from regenerating the initramfs and not specifically from the qcontrol change? Can you try regenerating the initramfs without actually changing qcontrol? I'm going to try and dig out an old SATA drive that I can stick in my 419PII so I can experiment without moving my actual production NAS over. Might take me a while to find one though (I recently recycled all my old disks, doh!). What method did you use to get dropbear into your initrd? It might be worth editing /usr/share/initramfs-tools/hooks/qcontrol and adding dropbear as a prereq to ensure it gets run first? (you'll need to regen the initramfs after) If you unpack the initrd then you should find /scripts/init-bottom/ORDER lists the order things will happen in. Going one step further and adding "exit 0" to the top of /usr/share/initramfs-tools/scripts/init-bottom/qcontrol and regenerating the initramfs. Hopefully that will stop it interfering with dropbear! Ian. -- Ian Campbell Current Noise: Fu Manchu - Downtown In Dogtown * knghtbrd can already envision: "Subject: [INTENT TO PREPARE TO PROPOSE FILING OF BUG REPORT] Typos in the policy document" -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
