Help test the next Debian image (wheezy)

A few remarks about "overscan":

raspi-config has an option for overscan, but only to enable/disable it. It think it would be nice if you could set the overscan number(s). Maybe just one number to use on all sides (which is now by default "16"), or two numbers (horizontally and vertically).

Because this does not yet exist, I had to manually edit /boot/config.txt. And again I had the same old problem: after editing ("sudo vi /boot/config.txt) and saving and rebooting, config.txt contained strange characters from some point in the file. I've experienced this earlier. Work around: shutdown raspi, put SD card in Ubuntu system, edit config.txt, umount, mount, check, re-check, everything OK, umount, put it back into the raspi and boot ... everything all right.
So: is "sudo vi /boot/config.txt" causing problems for others too?

[asb]

Because this does not yet exist, I had to manually edit /boot/config.txt. And again I had the same old problem: after editing ("sudo vi /boot/config.txt) and saving and rebooting, config.txt contained strange characters from some point in the file. I've experienced this earlier. Work around: shutdown raspi, put SD card in Ubuntu system, edit config.txt, umount, mount, check, re-check, everything OK, umount, put it back into the raspi and boot ... everything all right.
So: is "sudo vi /boot/config.txt" causing problems for others too?

It is very concerning that there still seem to be some lingering SD card corruption issues (on FAT partitions at least)...

I agree more control over overscan would be neat, and it's a feature request I'm tracking.

Because this does not yet exist, I had to manually edit /boot/config.txt. And again I had the same old problem: after editing ("sudo vi /boot/config.txt) and saving and rebooting, config.txt contained strange characters from some point in the file. I've experienced this earlier. Work around: shutdown raspi, put SD card in Ubuntu system, edit config.txt, umount, mount, check, re-check, everything OK, umount, put it back into the raspi and boot ... everything all right.
So: is "sudo vi /boot/config.txt" causing problems for others too?

It is very concerning that there still seem to be some lingering SD card corruption issues (on FAT partitions at least)...

I agree more control over overscan would be neat, and it's a feature request I'm tracking.

My guess is that it is not only FAT that is causing this problem: when I edit boot/config.txt in my ubuntu, it's still the same FAT. So is it caused by the fact the raspi is using / accessing / holding the FAT partition or even boot/config.txt?


#overscan: I can try to write it and post the patched raspi-config here. However, some time ago, I 'enriched' raspi-config with PAL/NTSC selection and uploaded the patch here, but never heard back.

[asb]

#overscan: I can try to write it and post the patched raspi-config here. However, some time ago, I 'enriched' raspi-config with PAL/NTSC selection and uploaded the patch here, but never heard back.

Apologies and thank you for sharing a patch, I did see that and intend to integrate something based on it. I need to dedicate a little more time to enhancing raspi-config but have been rather busy lately.

I have two raspi's. The only visible difference is the "CE" and the "FC" logo's on the back: one Raspi has negative logo's (white surrounding, letters are green), the other Raspi has positive logo's (normal green surrounding, letters in white). So it might be different hardware.

Anyway: the problem is that a Kingston 16GB SDcard boots very well in the negative-logo-Raspi, but not in the positive-logo-Raspi: it just shows the Raspi logo, and that's it. The same Raspi perfectly boots from a 4GB-SDcard (don't know the brand).

So ... differences in Raspi hardware? And: is there a way to get the 16GB booting in the positive-logo-Raspi?

[asb]

I have two raspi's. The only visible difference is the "CE" and the "FC" logo's on the back: one Raspi has negative logo's (white surrounding, letters are green), the other Raspi has positive logo's (normal green surrounding, letters in white). So it might be different hardware.

Anyway: the problem is that a Kingston 16GB SDcard boots very well in the negative-logo-Raspi, but not in the positive-logo-Raspi: it just shows the Raspi logo, and that's it. The same Raspi perfectly boots from a 4GB-SDcard (don't know the brand).

So ... differences in Raspi hardware? And: is there a way to get the 16GB booting in the positive-logo-Raspi?

Have you tried updating to the latest firmware? (from github.com/raspberrypi/firmware, you could use rpi-update). Dom has added some fixes which may help. I haven't put out a new package update yet as I'm somewhat concerned about the FAT corruption some people are seeing.

Have you tried updating to the latest firmware? (from github.com/raspberrypi/firmware, you could use rpi-update). Dom has added some fixes which may help. I haven't put out a new package update yet as I'm somewhat concerned about the FAT corruption some people are seeing.

Hi

I was editing my config.txt (changing overscan values) yesterday and ended up losing the last seven lines from the file. These were replaced with a single line of random characters and I assumed at the time it was something I had done.

Firmware was updated prior to this at around 11am yesterday morning.

The SD card is 8Gb Kingston class 4 and apart from this slight hiccup seems to be working ok.

Cheers

Paul

Have you tried updating to the latest firmware? (from github.com/raspberrypi/firmware, you could use rpi-update). Dom has added some fixes which may help. I haven't put out a new package update yet as I'm somewhat concerned about the FAT corruption some people are seeing.

Do you mean I should download rpi-update from https://github.com/Hexxeh/rpi-update/bl ... rpi-update, put it on the raspi, run it with sudo and point it at https://github.com/raspberrypi/firmware ... aster/boot ?

FYI: "sudo rpi-update" does not work, and "sudo apt-get install rpi-update" gives "E: Unable to locate package rpi-update"..

[asb]

Have you tried updating to the latest firmware? (from github.com/raspberrypi/firmware, you could use rpi-update). Dom has added some fixes which may help. I haven't put out a new package update yet as I'm somewhat concerned about the FAT corruption some people are seeing.

Do you mean I should download rpi-update from https://github.com/Hexxeh/rpi-update/bl ... rpi-update, put it on the raspi, run it with sudo and point it at https://github.com/raspberrypi/firmware ... aster/boot ?

FYI: "sudo rpi-update" does not work, and "sudo apt-get install rpi-update" gives "E: Unable to locate package rpi-update"..

Yes, or else you could edit /etc/apt/sources.list.d/raspi.list so it contains:

deb http://asbradbury.org/tmp/raspi/staging_repo/ wheezy main

Then sudo apt-get update && sudo apt-get upgrade which will upgrade your firmware.

Have you tried updating to the latest firmware? (from github.com/raspberrypi/firmware, you could use rpi-update). Dom has added some fixes which may help. I haven't put out a new package update yet as I'm somewhat concerned about the FAT corruption some people are seeing.

Do you mean I should download rpi-update from https://github.com/Hexxeh/rpi-update/bl ... rpi-update, put it on the raspi, run it with sudo and point it at https://github.com/raspberrypi/firmware ... aster/boot ?

FYI: "sudo rpi-update" does not work, and "sudo apt-get install rpi-update" gives "E: Unable to locate package rpi-update"..

Yes, or else you could edit /etc/apt/sources.list.d/raspi.list so it contains:

deb http://asbradbury.org/tmp/raspi/staging_repo/ wheezy main

Then sudo apt-get update && sudo apt-get upgrade which will upgrade your firmware.

Can I ignore the

W: GPG error: http://asbradbury.org wheezy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 82B129927FA3303E

How can I check the firmware version that's in the raspi hardware?

THanks

The firmware method worked! The 16GB SD Card is now booting in both Raspi's!

Thank you!

As of proof of concept, I've two scripts for overscan:

enable-overscan.sh.
Run it with sudo, and a value after it (something between -40 and 40):

Code: Select all

#!/bin/sh

SHIFTVALUE=$1
echo $SHIFTVALUE
# It should be an integer ... we should check that ...

sed /boot/config.txt -i -e "s/.*overscan_left=.*$/overscan_left=${SHIFTVALUE}/"
sed /boot/config.txt -i -e "s/.*overscan_right=.*$/overscan_right=${SHIFTVALUE}/"
sed /boot/config.txt -i -e "s/.*overscan_top=.*$/overscan_top=${SHIFTVALUE}/"
sed /boot/config.txt -i -e "s/.*overscan_bottom=.*$/overscan_bottom=${SHIFTVALUE}/"
# Alas, the result in $? is always 0 ... both with found and not found. So not checking possible


disable-overscan.sh
run it with sudo

Code: Select all

#!/bin/sh

sed /boot/config.txt -i -e "s/^overscan_/#overscan_/g"


This works for me.

My idea for raspi-config: an overscan menu like this:
- disable overscan
- make text / computer output a bit smaller (because it falls of the screen) -> enable_overscan 20
- make text / computer output much larger -> enable_overscan 50
- make text / computer output larger (remove black borders) -> enable_overscan -20
- make text / computer much larger (remove big black borders)-> enable_overscan -50

I'm bad a script programming, so I could not yet get this into raspi-config

Update: I created a full script for setting overscan_ values. It is on http://www.appelboor.com/dump/raspi-handle-overscan.sh . Or go to http://www.appelboor.com/dump/ and then select the script.

It works, including a whiptail menu to choose from ...

I seem to have a problem with the wheezy image. When booting, it hangs on "configuring network interfaces" for a long time. When it has finished it says "mount.nfs: Connection timed out". I don't have any network cable plugged in, but it was connected to the internet yesterday when I did the first boot. Once it finally gets past this stage it seems fine, but it's a long wait.

Never mind, problem solved (though I can't seem to edit my first post, weird).

Ok, got my Raspberry Pi last week, and got it going nicely with the "official" squeeze version. All smooth, but some issues with powered hub and wifi (another story)

Found the wheezy beta, so have given that a go, and so far, so good!
Booted up no problem (although didn't want to go into raspi-config automatically on first boot, so did it manually). I ran apt-get update and apt-get upgrade, and a note to others, this took about 1.5 hours to complete.

I found that rpi-update doesn't want to work: it hangs on the line "this may take a few minutes" (although I noted occasional network activity, so something may have been happening).
I got bored after 1 hour, and forced a restart, expecting problems as others have reported, however, booted fine.

After all this, the dining room table was needed, so more fun later (retrying the wifi set up (Netgear WG111v3 dongle) with the improved firmware etc on wheezy - anybody got experience of this?)

Thanks for the work on this, I look forward to further updates...

Just a quick, and possibly silly question, but do the firmware updates actually change anything on the Raspberry Pi itself, of just on the SD card... and I assume that they are 'permanent'?

Thanks!

Just a quick, and possibly silly question, but do the firmware updates actually change anything on the Raspberry Pi itself,

Just the SD Card. Nothing permanent.

I think this is the right place to post this, as it's on the latest Wheezy beta and it looks to me like an OS issue rather than a software one.

I am getting a "Can not open /dev/mem" error when calling the svgalib Bochs extension (don't ask... ). Googling suggets it's likely to be a function of the kernel rather than of Bochs or SVGAlib. Can anyone shed any light on the problem perchance?

I expect this is failing because CONFIG_STRICT_DEVMEM is enabled in our kernel (which is the case for all kernel configs commonly used by distributions these days).

Sorry, been away for a few days. Thanks for the reply, a feature not a bug then. Guess I'll have to use one of the other libraries.

Having installed a new Wheezy image to my SD card I then decided to perform an update (and upgrade) by doing a 'sudo apt-get update && sudo apt-get upgrade' which took about an hour!

Some way through it first asked me if I wished to update some files, to which I replied 'y' and on it went.

A bit further on I was advised that a configuration file xxx.conf had been modified since the installation and asked if I wished to install the new file, or keep my old one (or words to that effect), so I told it to install the new file, effectively overwriting my old one (whatever that was!) and off it went again.

On completion, and after a reboot the text is definitely sharper & clearer (and probably a bit larger!) and the image is centered on the screen, but with a bit too much 'black space', top and bottom. Also my clock is running one hour slow (I am in the U.K. if that makes any difference).

I just thought I would record my experiences here in case anyone wishes to comment.... I do think that a large warning about the length of time an update & upgrade will take wouldn't have gone amiss though!

[asb]

Having installed a new Wheezy image to my SD card I then decided to perform an update (and upgrade) by doing a 'sudo apt-get update && sudo apt-get upgrade' which took about an hour!

Some way through it first asked me if I wished to update some files, to which I replied 'y' and on it went.

A bit further on I was advised that a configuration file xxx.conf had been modified since the installation and asked if I wished to install the new file, or keep my old one (or words to that effect), so I told it to install the new file, effectively overwriting my old one (whatever that was!) and off it went again.

Thanks for the report, I'll have to check our what config files get updated. The rate of updates to wheezy packages should slow drastically now that the 'release freeze' is in effect. I did see one machine today took forever to apt-get update as it downloaded a ridiculous number of pdiff files (I had tested if this was an issue, but when I tried didn't get that behaviour - presumably it depends on the mirror). I expect I'll disable pdiffs by default to avoid this problem.

Yes, I was watching the screen for most of the time, and I seem to recall seeing more than a few pdiff files being downloaded.

Presumably when things have quietened down a bit more you will be releasing an updated image file which will incorporate a lot of the updates etc.?

[asb]

Yes, I was watching the screen for most of the time, and I seem to recall seeing more than a few pdiff files being downloaded.

Presumably when things have quietened down a bit more you will be releasing an updated image file which will incorporate a lot of the updates etc.?

Most definitely.

Sorry,
I'm a bit confused about rpi-update! Does it run on the Wheezy image?

Greetings,
Thomas

Sorry,
I'm a bit confused about rpi-update! Does it run on the Wheezy image?

If I understand correctly, you don't need to rpi-update on the Wheezy image because it has been changed.

If you want the firmware updates:

Code: Select all

edit /etc/apt/sources.list.d/raspi.list so it contains:
deb http://asbradbury.org/tmp/raspi/staging_repo/ wheezy main
Then 'sudo apt-get update && sudo apt-get upgrade' which will upgrade your firmware.