Help test the next Debian image (wheezy)

[asb]

Does this image have IPv6?

I was quite surprised to see the April version has no IPv6:

It does.

1) The LXDE task panel along the bottom no longer displays.

I got the panels back by "rm -r lxpanel" from ~/.config/ followed by a reboot "sudo reboot" so that on restart it grabbed the default settings.

http://wiki.lxde.org/en/LXPanel

If the config files are missing, lxpanel loads system-wide config in /usr/share/lxpanel/profile/<Profile name> instead.

I'm not having any good ideas about what the problem could be here (I can not reproduce locally, and it clearly is not a problem for many other people). Does anyone have any ideas?

Same thing (& same cure) happened to my in Raspbian (also Wheezy) a couple of times. I think Mike commented it was an issue after an update to lxde.

ETA link:
viewtopic.php?p=95088#p95088

Yes, it will be appending to config.txt and for some reason this is clearly resulting in junk...but only sometimes. Hmm.

Does it necessarily have to be appending the file? I would have thought it would make more sense to use sed to uncomment the existing relevant line.

[asb]

Yes, it will be appending to config.txt and for some reason this is clearly resulting in junk...but only sometimes. Hmm.

Does it necessarily have to be appending the file? I would have thought it would make more sense to use sed to uncomment the existing relevant line.

Yes, that would be a sensible enhancement (at the time I did that I didn't include an existing config.txt). I'd still like to understand what is going on though.

1) The LXDE task panel along the bottom no longer displays.

I got the panels back by "rm -r lxpanel" from ~/.config/ followed by a reboot "sudo reboot" so that on restart it grabbed the default settings.

http://wiki.lxde.org/en/LXPanel

If the config files are missing, lxpanel loads system-wide config in /usr/share/lxpanel/profile/<Profile name> instead.

I'm not having any good ideas about what the problem could be here (I can not reproduce locally, and it clearly is not a problem for many other people). Does anyone have any ideas?

Are you connecting the keyboard directly via USB or via terminal program ? - I, I saw stability problems resulting in some things not displaying / working when the link was active

Direct by USB to powered hub with mouse and keyboard.

[asb]

If you downloaded, please do a `sudo apt-get update && sudo apt-get upgrade` to upgrade to rebuilt firmware with SD card performance improvements (viewtopic.php?p=98987#p98987). Note that unfortunately, this will change the default start.elf to the 128MB memory split one. You can change this with `sudo raspi-config`. Please do test.

Thanks to plugwash for assistance in working around dpkg's hatred of FAT filesystems.

Does this image have IPv6?

I was quite surprised to see the April version has no IPv6:

It does.

Cool. I installed this image onto my Raspi, and it indeed does IPv6. Great.

BTW:
1) miredo is installable, so that gives an automatic IPv6 tunnel in case your ISP doesn't provide IPv6. (This is a tip if you want to have IPv6 on your Raspi)
2) The tool raspi-config and its auto-startup is great!

Im glad to see the bash-completion package has made it in. I think it'll be a great help for novice users trying to find packages and commands.

I don't tend to use X, but i havent yet run into any issues on the command line.

The first boot assistance menu is a great addition too.

Sad news: I got the image yesterday, just a day after my RPi arrived, and tested it... worked perfectly, which is good. I also did "sudo apt-get update" and "sudo apt-get upgrade", and it upgraded some packages.

The bad thing is that today I did the same... but it won't boot any more. So I re-flashed the image, all the same, after update and upgrade, no more boot. Just red led on, RPi used as headless so no monitor to check. What info do you need for fixing it?

[asb]

Sad news: I got the image yesterday, just a day after my RPi arrived, and tested it... worked perfectly, which is good. I also did "sudo apt-get update" and "sudo apt-get upgrade", and it upgraded some packages.

The bad thing is that today I did tehe same... but it won't boot any more. So I re-flashed the image, all the same, after update and upgrade, no more boot. Just red led on, RPi used as headless so no monitor to check. What info do you need for fixing it?

Sounds like a problem with the firmware update (which incorporates sd card fixes). If you are able to get output so you can see if there are any kernel messages at all, that would be helpful. What SD card are you using?

[dom]

@typhoon
A display (at least temporarily) would be helpful to work out how far it gets.
Can you do a quick check. Watch the OK led very closely when you apply power. Any flashes?
If it flashes, how long for?

My Raspberry PI also got Cooked by wheezy **(solution an end of post)

I downloaded your wheezy image last night and put it on a 4GB card (class 6).
Booted it all went well, went through the install front-end enable sshd and
resize to fill card, tried something else but it gave an error, which I forgot
to note.

Then rebooted, watched the reboot and resizing happen. Then login and
su'ed to root.

Then did:
# apt-get update
(it downed a load of stuff)
# apt-get update
(it actual downloaded about another 27k ! which I did not expect)
# apt-get upgrade
(it upgraded a load of debian packages)
(it then also UPDATED FIRMWARE from packages)
# sync
# init 6

DEAD Raspberry Pi
Nothing at all on the screen, power it off, same, powered it off for 20 mins
still dead, tried inserting my previously working debian squeezy card, it
showed a coloured square on the screen, but would go no further.
Unplugged everything but my HDMI connection power cycled
same colour block. tried switching cards back forth (powering
off before pulling card and inserting another) nothing fixed it.
Colour block on old debian, blank on wheery (updated).
(the RED LED is only light on since the fail)

All this was last night about 23:30 to 01:00.

SOLUTION
=========
I unplugged this morning *everything* (including the HDMI) except the power and
turned it on, nothing (as expected), turned it off inserted *ONLY* the old working
debian (squeezy patched to 4-5 days ago including rpi-update) card turned power
on and the red and then green light started flashing!!!! so insert the HDMI cable
(while it waqs till powered) and could see my Pi booting!!!

My Raspberry Pi lives!!!

However putting my wheezy card back in, nothing just black screen, so powered
off then I unplugged HDMI again booted my debian squeezy card and plugged in HDMI.

======

QUESTIONS
==========
So ..... any thoughts about what the firmware changes are?
ANyone else successfully upgraded this way and have a working card/raspberry?

Sad news: I got the image yesterday, just a day after my RPi arrived, and tested it... worked perfectly, which is good. I also did "sudo apt-get update" and "sudo apt-get upgrade", and it upgraded some packages.

The bad thing is that today I did the same... but it won't boot any more. So I re-flashed the image, all the same, after update and upgrade, no more boot. Just red led on, RPi used as headless so no monitor to check. What info do you need for fixing it?

I know it is difficult without using a monitor, but do you have another SD card which you could try containing just the 'standard' Debian image from the download section on here?

I experienced a similar problem when I tried to update my 'squeeze', but it all worked fine again when I started again from scratch.

A bit of a pain I know, but it might just help to check that your Pi itself is OK... or you could even try the solution just posted above!

FWIW:

I regularly use mtr, lsusb and lshw (mainly to analyze network problems), and I saw they are not installed on the image. So I installed them via:

Code: Select all

sudo apt-get install mtr
sudo apt-get install usbutils
sudo apt-get install lshw


I'm quite sure lsusb was available on the April image. So, it is by design or a bug that lsusb is not available on this image?

[asb]

I'm quite sure lsusb was available on the April image. So, it is by design or a bug that lsusb is not available on this image?

An oversight, will be fixed in the next download. https://github.com/asb/spindle/issues/43

Notes on previous post "My config"

card was a TRANSCEND 4GB class 6
USB Keyboard (standard cheap keyboard, but back lite)
no mouse was attached
Network fixedwire
power was adapter from RS (the one they say for a raspberry Pi)

[asb]

So ..... any thoughts about what the firmware changes are?
Anyone else successfully upgraded this way and have a working card/raspberry?

Well, I do and just tested again. After update, the boot partition contains the correct files with expected sha1sums (would be interesting if people having problems could take a look at their boot partition, which is FAT and so can be read easily even on a windows machine).

Code: Select all

pi@raspberrypi ~ $ sha1sum /boot/*
0cca4303890b6181f2db58ec3bccbea719ba627a  /boot/arm128_start.elf
9c83f88ac2f251a2eb6c3dafec802331c5e84e19  /boot/arm192_start.elf
278722d06c9231553c6b34bbf22b60a5b70e4b3a  /boot/arm224_start.elf
41e2ae48b430beab3b3f0370c8002d971402a13a  /boot/bootcode.bin
82517aa4f1876f1df6723744becd7461c2e38683  /boot/cmdline.txt
32476166696c0a3357ad2ed2d02ca476d66cca27  /boot/config.txt
5588e14d43b3b832cf14f16da373577fbbd93408  /boot/kernel_cutdown.img
d5124846f66cd03169e746a2f88e36f104304758  /boot/kernel_emergency.img
3759ede6b4bc3ee0261ed07871e5c4b993768014  /boot/kernel.img
ec8c1d3b0f8430c4d8a667026d0d1fa7416a46fb  /boot/loader.bin
0cca4303890b6181f2db58ec3bccbea719ba627a  /boot/start.elf


If you were to ctrl-c mid-way through an upgrade and don't finish configuration, it is possible the machine could be left in an unbootable state (unfortunately the hack to work around dpkg's hatred of FAT means that the boot partition files are deleted until the postinst script is run).

I'm using a 4GB SDHC class B from Samsung, MB-SP4G, MBSP4GMBDDCA, D FD6S0000 939 KOREA. I can't check output on a monitor right now, later I should be able to. Right now only the red led lits, no blinking, and the "ok" led is so faint you could think it's off.

[dom]

If you were to ctrl-c mid-way through an upgrade and don't finish configuration, it is possible the machine could be left in an unbootable state (unfortunately the hack to work around dpkg's hatred of FAT means that the boot partition files are deleted until the postinst script is run).

Also removing power before the syncing to sdcard has occurred would likely leave the system unbootable.
After the update might be worth typing sync.
sync will be called by halt/reboot/shutdown, but sometimes shutdown doesn't compete, so it may be safest to call it manually.
(Alex, does firmware package update cause a sync, or could it? I'm sure it shouldn't be needed but that would rule it out, and provide a little more safety for premature power cable unpluggers.)

[dom]

I'm using a 4GB SDHC class B from Samsung, MB-SP4G, MBSP4GMBDDCA, D FD6S0000 939 KOREA. I can't check output on a monitor right now, later I should be able to. Right now only the red led lits, no blinking, and the "ok" led is so faint you could think it's off.

Are you referring to LEDs just after applying power?

[asb]

(Alex, does firmware package update cause a sync, or could it? I'm sure it shouldn't be needed but that would rule it out, and provide a little more safety for premature power cable unpluggers.)

Good idea, I'll err on the side of caution and stick it in the postinst script for the package providing the /boot files (though dpkg-divert may well be syncing already anyway). I also don't like the fact this dpkg hack leaves /boot in an unsafe state mid-installation and will look for an alternative. There's obviously always going to be a window where you can leave your system unbootable by cutting power during an update, but we can try to keep that window as small as possible.

yes, just after applying power. usually after applying power all of them are on, just the OK is off.

btw: I noticed my /boot is empty, boot partition (60MB one) is like in the screenshot. Troubles updating?

[dom]

@typhoon
You won't boot if you have no bootcode.bin visible to windows (in FAT partition).

Are you saying every time you "apt-get upgrade" you end up with no bootcode.bin ?

[asb]

yes, just after applying power. usually after applying power all of them are on, just the OK is off.

btw: I noticed my /boot is empty, boot partition (60MB one) is like in the screenshot. Troubles updating?

/boot being empty is fine (when the Raspberry Pi boots, it mounts the boot partition there). The contents of your boot partition is worrying as you've somehow lost a number of files. Did you have any error messages during the apt-get upgrade process? This is the part which is critical it completes properly:

Code: Select all

Setting up raspberrypi-bootloader (1.20120614-1) ...
Removing 'diversion of /boot/arm128_start.elf to /usr/share/rpikernelhack/arm128_start.elf by rpikernelhack'
Removing 'diversion of /boot/arm192_start.elf to /usr/share/rpikernelhack/arm192_start.elf by rpikernelhack'
Removing 'diversion of /boot/arm224_start.elf to /usr/share/rpikernelhack/arm224_start.elf by rpikernelhack'
Removing 'diversion of /boot/bootcode.bin to /usr/share/rpikernelhack/bootcode.bin by rpikernelhack'
Removing 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack'
Removing 'diversion of /boot/kernel_cutdown.img to /usr/share/rpikernelhack/kernel_cutdown.img by rpikernelhack'
Removing 'diversion of /boot/kernel_emergency.img to /usr/share/rpikernelhack/kernel_emergency.img by rpikernelhack'
Removing 'diversion of /boot/loader.bin to /usr/share/rpikernelhack/loader.bin by rpikernelhack'
Removing 'diversion of /boot/start.elf to /usr/share/rpikernelhack/start.elf by rpikernelhack'


Note that files will be processsed in exactly this order, which makes it extra strange that you have start.elf (the last one to be updated) but not bootcode.bin