Help test the next Debian image (wheezy)

mmm, actually not about the keymaps thing, but something I'm experiencing right now.
I'm trying to use transmission to dl stuff, and saving it to usb drive, but as soon as there is say... 500KB/s traffic, memory usages goes up till it hits the limit. I remember reading stuff about this being a problem with the driver of the chip that does usb+eth, was that fixed/included in the next image or it's a bug yet to be solved?

sudo apt-get install debian-goodies and then use dpigs to see the largest installed packages..

The first biggest package on my system was java, which I installed.

The next biggest was dbench which I didn't install. I removed it freeing up 25MB.

I've never installed dbench on these images. Are you sure you didn't install it yourself?

No, never heard of it. Could it have been brought in as a dependency? Thanks.

Hi Thanks for the work.
Is there a list somewhere of all of the changes from the 19.4.2012 version?
In particular is I2C & DS1307/2338 drivers included?

You're right that perhaps this image is a little on the full side. I think there is value in offering an image that fits on a 2GiB card, but it does seem likely the full "educational" SD card image would require 4GiB minimum.

Wow. Ran dpigs. Where did omxplayer come from, was that in the .img? 442Mb! Surely this is not needed in an 'educational' image?

booted ok, trying the resize tool...seems hanged...it's 15mins that's not doing anything....
is it normal?

Hmm, nobody has actually reported problems with resize before. How it works is that it enlarges the root partition then and there, then on the next boot the ext4 filesystem is actually enlarged (it isn't possible to reload the root partition table). Do you get a hang immediately after selecting the enlarge root partition option, or during the next boot?

I'm seeing this too on my 8Gb Aldi card - I noticed the card was a bit sluggish writing to it in the first place so this 'hang' may just be taking a looooooooong time to fill out the 8Gb...

May be there could be an option on the raspi-config tool specify how many Gb you want expanding to...

EDIT - just come back, was just very slow, may be about 10mins to complete the resize2fs

[dom]

Wow. Ran dpigs. Where did omxplayer come from, was that in the .img? 442Mb! Surely this is not needed in an 'educational' image?

Whyever not? I can think of lots of cool programming projects that end up playing a media file.
You could just as easily say why is 3D needed in an educational image.

However it is very large. omxplayer itself is small but it relies on ffmpeg/libav.
Now we only need audio decode and container handling from this - it is going to have unneeded encoders, video decoders etc.
I guess we need a custom build to reduce the size.

[asb]

You're right that perhaps this image is a little on the full side. I think there is value in offering an image that fits on a 2GiB card, but it does seem likely the full "educational" SD card image would require 4GiB minimum.

Wow. Ran dpigs. Where did omxplayer come from, was that in the .img? 442Mb! Surely this is not needed in an 'educational' image?

The package itself is a few hundred kilobytes. I wouldn't have thought the ffmpeg deps would add up to that much. Let me check...

[asb]

No, never heard of it. Could it have been brought in as a dependency? Thanks.

Could have been brought in as a dependency. I don't have the package manifest or a copy of the released image to hand but I'm almost certain it's not there. It is 100% not on the beta image.

[asb]

The package itself is a few hundred kilobytes. I wouldn't have thought the ffmpeg deps would add up to that much. Let me check...

Just checked - the ridiculously large reported package size is due to a packaging issue. The Installed-Size field in the omxplayer package is given in bytes, when dpkg is expecting a value in kilobytes

Strange things = the issues where stuff disappeared in the boot partition, leaving the Pi unbootable.

And I still have this issue, every time (tried it 4 times) id create new image on 4GB Card
I end up with a start.elf there in /boot and the md5sum is as expected, but after an init 6
the start.elf is no longer there!

[asb]

Strange things = the issues where stuff disappeared in the boot partition, leaving the Pi unbootable.

And I still have this issue, every time (tried it 4 times) id create new image on 4GB Card
I end up with a start.elf there in /boot and the md5sum is as expected, but after an init 6
the start.elf is no longer there!

To clarify, this is after you do an apt-get upgrade rather than simply writing the image and rebooting?

Hi I downloaded this image I can report that I am having problems with the usb keyboard driver once lxde has started the keyboard gradually becomes unresponsive. I am using a very cheap key board from tesco's. I adjusted all the settings in keyboard preferences to try to correct the error. I will try another keyboard to see if this makes a difference.

the other thing,yeah, 2GB is too small and I am happy that the new version has a script to automatically expand the ext4 partition. By the time I have installed all the updates, tightvnc, wireless drivers, bluetooth stack then the 2GB partition is full. 4GB is minimal really....Either an 8GB card or an external USB drive is required

For the record and to confirm your and my "4GB required" statement: I just did a fresh install onto a 2GB card, booted it, ran sudo apt-get update and upgrade, and the result was:

Code: Select all

pi@raspberrypi ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          1.7G  1.5G   92M  95% /
/dev/root       1.7G  1.5G   92M  95% /
tmpfs            19M  208K   19M   2% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            37M     0   37M   0% /tmp
tmpfs            10M     0   10M   0% /dev
tmpfs            37M     0   37M   0% /run/shm
/dev/mmcblk0p1   58M   34M   24M  59% /boot
pi@raspberrypi ~ $


(FWIW: 1.7G is normal for a 2GB card?)

So only 92 MB left. I would thus say using 2GB is asking for trouble within a few hours or days of usage ... with very strange results.

So I really thinkg 4GB should be stated as the minimum requirement. It's 2.11 Euro here, so the money won't be the problem.

From some of the above comments I am getting the impression that a new 'beta' version has now been released, which is later than the one linked to in the first post of this thread,

If that is in fact the case, where can we download it from please?

[asb]

From some of the above comments I am getting the impression that a new 'beta' version has now been released, which is later than the one linked to in the first post of this thread,

If that is in fact the case, where can we download it from please?

No, still waiting for it to propagate to the raspberrypi.org download servers.

From some of the above comments I am getting the impression that a new 'beta' version has now been released, which is later than the one linked to in the first post of this thread,

If that is in fact the case, where can we download it from please?

No, still waiting for it to propagate to the raspberrypi.org download servers.

Thank you... that is good new which does sound quite encouraging!

Let's just hope that it doesn't take to long to reach them!

Has anyone gotten ALSA to work with a USB soundcard under the wheezy image?

I'll check my logs to pull up the error messages but it's been no go so far.

For people looking to reduce the size of the image, try to install localepurge.

Apart from that, I have also ALSA problems and cannot get a USB webcam to work (3 different models tested).

Following my previous post about ffmpeg, the compiled version from the Debian wheezy repository does not work (as opposed to the first official image based on Debian squeeze), but compiling from the sources is successful (it takes a looooooooooong time to do so).

worthwhile to try to compile ALSA on my pi?

mmm, about my usb-eth issue, I think it may be fixad in the new image... I used the raspbian image since I'm waiting the new debian weezy to be up (can't upgrade remember?), and it seems to work now.
I'll report on weezy as soon I can try it. propagate young image, propagate...

[asb]

It's up: http://www.raspberrypi.org/archives/1435

It's up: http://www.raspberrypi.org/archives/1435

Great stuff, and many thanks again to all involved with this project... I am downloading it at the moment!

Hi I downloaded this image I can report that I am having problems with the usb keyboard driver once lxde has started the keyboard gradually becomes unresponsive. I am using a very cheap key board from tesco's. I adjusted all the settings in keyboard preferences to try to correct the error. I will try another keyboard to see if this makes a difference.

nope its not the keyboard what the problem was is that I was trying to use two switched power regulators that aren't earthed. One 1 amp regulator to power the pi and another 2.5 amp regulator to power a usb hub. I think what happens is they fight each other via a ground earth feedback loop type mecanism. Powering the pi from the usb hub via a usb to micro usb cable sorted the problem out. The keyboard now works perfectly. I also noticed the pi was able to partially power itself from the hub without a power cable being plugged in I observed it starting up and shutting down when the power cable was unplugged and the powered hub was on. Therefore this error had nothing to do with wheezy.

Hi,

I've enriched the great rasp-config tool with a PAL setting options: switch between PAL en non-PAL (=NTSC) on the video RCA output

It seems to work

Code: Select all

pi@raspberrypi ~ $ sudo /usr/bin/raspi-config-with-PAL
pi@raspberrypi ~ $ grep sdtv /boot/config.txt
#sdtv_mode=2
pi@raspberrypi ~ $
pi@raspberrypi ~ $ sudo /usr/bin/raspi-config-with-PAL
pi@raspberrypi ~ $ grep sdtv /boot/config.txt
sdtv_mode=2
pi@raspberrypi ~ $



And here's the code: it's about the do_PAL, set_PAL and the PAL line in the menu option. All shamelessly stolen from the overscan functions.

Code: Select all

#!/bin/sh
# Part of raspi-config http://github.com/asb/raspi-config
#
# See LICENSE file for copyright and license details


if [ $(id -u) -ne 0 ]; then
  printf "Script must be run as root\n"
  exit 1
fi

do_info() {
  whiptail --msgbox "This tool provides a straight-forward way of doing
  initial configuration of the Raspberry Pi. Although it can be run at any
  time, some of the options may have difficulties if you have heavily
  customised your installation." 20 60 1
}

do_expand_rootfs() {
  # Get the starting offset of the root partition
  PART_START=$(parted /dev/mmcblk0 -ms unit s p | grep "^2" | cut -f 2 -d:)
  [ "$PART_START" ] || return 1
  # Return value will likely be error for fdisk as it fails to reload the
  # partition table because the root fs is mounted
  fdisk /dev/mmcblk0 <<EOF
p
d
2
n
p
2
$PART_START

p
w
EOF

  # now set up an init.d script
cat <<\EOF > /etc/init.d/resize2fs_once &&
  #!/bin/sh
### BEGIN INIT INFO
# Provides:          resize2fs_once
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5 S
# Default-Stop:
# Short-Description: Resize the root filesystem to fill partition
# Description:
### END INIT INFO

. /lib/lsb/init-functions

case "$1" in
  start)
    log_daemon_msg "Starting resize2fs_once" &&
    resize2fs /dev/mmcblk0p2 &&
    rm /etc/init.d/resize2fs_once &&
    update-rc.d resize2fs_once remove &&
    log_end_msg $?
    ;;
  *)
    echo "Usage: $0 start" >&2
    exit 3
    ;;
esac
EOF
  chmod +x /etc/init.d/resize2fs_once &&
  update-rc.d resize2fs_once defaults &&
  whiptail --msgbox "Root partition has been resized.\n\
The filesystem will be enlarged upon the next reboot" 20 60 2
}


# $1 is 0 to disable overscan, 1 to disable it
set_overscan() {
  # Stop if /boot is not a mountpoint
  if ! mountpoint -q /boot; then
    return 1
  fi

  [ -e /boot/config.txt ] || touch /boot/config.txt

  if [ "$1" -eq 0 ]; then # disable overscan
    sed /boot/config.txt -i -e "s/^overscan_/#overscan_/"
    if grep -q "^disable_overscan" /boot/config.txt; then
      sed -i /boot/config.txt -e "s/^disable_overscan.*$/disable_overscan=1/"
    else
      printf "disable_overscan=1\n" >> /boot/config.txt
    fi
  else # enable overscan
    sed -i /boot/config.txt -e "s/^disable_overscan.*$/disable_overscan=0/"
  fi
}

do_overscan() {
  whiptail --yesno "What would you like to do with overscan" 20 60 2 \
    --yes-button Disable --no-button Enable
  RET=$?
  if [ $RET -eq 0 ] || [ $RET -eq 1 ]; then
    set_overscan $RET;
  else
    return 1
  fi
}



# $1 is 0 to disable PAL, 1 to disable it

# sdtv_mode=2 means PAL
# #sdtv_mode=2 means no PAL (but NTSC)
set_PAL() {

  # Stop if /boot is not a mountpoint
  if ! mountpoint -q /boot; then
    return 1
  fi

  [ -e /boot/config.txt ] || touch /boot/config.txt

 

  if [ "$1" -eq 0 ]; then # disable PAL
    sed /boot/config.txt -i -e "s/^sdtv_mode=2/#sdtv_mode=2/"

    #if grep -q "^disable_overscan" /boot/config.txt; then
    #  sed -i /boot/config.txt -e "s/^disable_overscan.*$/disable_overscan=1/"
    #else
    #  printf "disable_overscan=1\n" >> /boot/config.txt
    #fi

  else # enable PAL
    sed /boot/config.txt -i -e "s/^#sdtv_mode=2/sdtv_mode=2/"

  fi
}

do_PAL() {
  whiptail --yesno "What would you like to do with PAL" 20 60 2 \
    --yes-button Disable --no-button Enable
  RET=$?
  if [ $RET -eq 0 ] || [ $RET -eq 1 ]; then
    set_PAL $RET;
  else
    return 1
  fi
}



do_change_pass() {
  whiptail --msgbox "You will now be asked to enter a new password for the pi user" 20 60 1
  passwd pi &&
  whiptail --msgbox "Password changed successfully" 20 60 1
}

do_configure_keyboard() {
  dpkg-reconfigure keyboard-setup &&
  printf "Reloading keymap. This may take a short while\n" &&
  invoke-rc.d keyboard-setup start
}

do_change_locale() {
  dpkg-reconfigure locales
}

do_change_timezone() {
  dpkg-reconfigure tzdata
}

do_memory_split() {
  # Stop if /boot is not a mountpoint
  if ! mountpoint -q /boot; then
    return 1
  fi
  MEMSPLIT=$(whiptail --menu "Set memory split" 20 60 10 \
    "224" "224MiB for ARM, 32MiB for VideoCore" \
    "192" "192MiB for ARM, 64MiB for VideoCore" \
    "128" "128MiB for ARM, 128MiB for VideoCore" \
    3>&1 1>&2 2>&3)
  if [ $? -eq 0 ]; then
    cp -a /boot/arm${MEMSPLIT}_start.elf /boot/start.elf
  fi
}

do_ssh() {
  whiptail --yesno "Would you like the SSH server enabled or disabled?" 20 60 2 \
    --yes-button Enable --no-button Disable
  RET=$?
  if [ $RET -eq 0 ]; then
    update-rc.d ssh enable &&
    invoke-rc.d ssh start &&
    whiptail --msgbox "SSH server enabled" 20 60 1
  elif [ $RET -eq 1 ]; then
    update-rc.d ssh disable &&
    whiptail --msgbox "SSH server disabled" 20 60 1
  else
    return $RET
  fi
}

do_finish() {
  if [ -e /etc/profile.d/raspi-config.sh ]; then
    rm -f /etc/profile.d/raspi-config.sh
    sed -i /etc/inittab \
      -e "s/^#\(.*\)#\s*RPICFG_TO_ENABLE\s*/\1/" \
      -e "/#\s*RPICFG_TO_DISABLE/d"
    telinit q
  fi
  whiptail --msgbox "Done" 20 60 1
  exit 0
}

while true; do
  FUN=$(whiptail --menu "Raspi-config" 20 80 10 --cancel-button Exit \
    "info" "Information about this tool" \
    "expand_rootfs" "Expand root partition to fill SD card" \
    "overscan" "Change overscan" \
    "PAL" "Change PAL / NTSC" \
    "change_pass" "Change password for 'pi' user" \
    "configure_keyboard" "Set keyboard layout" \
    "change_locale" "Set locale" \
    "change_timezone" "Set timezone" \
    "memory_split" "Change memory split" \
    "ssh" "Enable or disable ssh server" \
    "finish" "Finish config and don't start raspi-config at boot" \
    3>&1 1>&2 2>&3)
  if [ $? -ne 0 ]; then
    exit 0;
  else
    "do_$FUN" || whiptail --msgbox "There was an error running do_$FUN" 20 60 1
  fi
done



If this is correct, I think it would be useful to put this into the raspi-config.

HTH

Sander

snip
what the problem was is that I was trying to use two switched power regulators that aren't earthed. One 1 amp regulator to power the pi and another 2.5 amp regulator to power a usb hub. I think what happens is they fight each other via a ground earth feedback loop type mecanism. Powering the pi from the usb hub via a usb to micro usb cable sorted the problem out. The keyboard now works perfectly. I also noticed the pi was able to partially power itself from the hub without a power cable being plugged in I observed it starting up and shutting down when the power cable was unplugged and the powered hub was on. Therefore this error had nothing to do with wheezy.

Another cure for that would be to use a cable from the hub to the rpi where the power (red) lead is disconnected so that the hub is not passing power back into the rpi.