[oe-issues] [Bug 1723] New: Dropbear keeps regenerating machine rsa key

[bugzilla-daemon at tinman.treke.net]

http://bugs.openembedded.org/show_bug.cgi?id=1723

           Summary: Dropbear keeps regenerating machine rsa key
           Product: Openembedded
           Version: OpenZaurus 3.5.4.x
          Platform: ARM
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Distributions
        AssignedTo: openembedded-issues at lists.openembedded.org
        ReportedBy: Dr.Graef at t-online.de
         QAContact: tinderbox-oe at gmx.net


The relevant section of the /etc/init.d/dropbear script:

readonly_rootfs=0
for flag in `awk '{ if ($2 == "/") { split($4,FLAGS,",") } }; END { for (f in
FLAGS) print FLAGS[f] }' </proc/mounts`; do
 case $flag in
  ro)
    readonly_rootfs=1
   ;;
 esac
done

Symptom: When my Z C1000 is booted from SD using altboot, readonly_rootfs gets
set to 1 even though / is actually mounted rw when the script is run during
startup. Consequently, a new machine key is generated at each boot and placed
into /var/lib/dropbear, instead of using the existing key in /etc/dropbear.

Immediate cause: When booting from SD using altboot, / is actually mounted
thrice. On my system, cat /proc/mounts gives:

rootfs / rootfs rw 0 0
/dev/root /media/ROM jffs2 ro 0 0
/proc /proc proc rw 0 0
/sys /sys sysfs rw 0 0
ramfs /dev ramfs rw 0 0
ramfs /dev ramfs rw 0 0
/dev/mmcblk0p1 / ext2 rw,nogrpid 0 0
ramfs /dev/.static/dev ramfs rw 0 0
tmpfs /dev tmpfs rw 0 0
/dev/mmcblk0p1 /media/card ext2 rw,nogrpid 0 0
/dev/mtdblock2 / jffs2 ro,noatime 0 0
/dev/mtdblock3 /home.flash jffs2 rw,noatime 0 0
tmpfs /var tmpfs rw 0 0
tmpfs /media/ram tmpfs rw 0 0
devpts /dev/pts devpts rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0

The awk command in the script picks up the last mount (/dev/mtdblock2 / jffs2
ro,noatime 0 0), thus readonly_rootfs gets set to 1.

Possible fix/workaround: Change the awk command to:

awk '{ if ($2 == "/") { split($4,FLAGS,","); for (f in FLAGS) print FLAGS[f];
nextfile } }' </proc/mounts

This returns the options of the first mount of /.

This works for me right now, but I'm not sure whether this workaround is really
foolproof. Maybe the reported issue is actually a problem with altboot or
somewhere else in the boot sequence?


-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.