STICKY: How to upgrade a Wheezy image to Jessie (both defunct and replaced versions of Raspbian) [thus obsolete]

[Kratos]

Can you send it over to me? Would save me a lot of time (downloading Raspbian Jessie image, installing it in a VM, grabbing the file, ...)

I'm actually using the Jessie image. You might save yourself a lot of heartache by just using the Jessie image here.
https://downloads.raspberrypi.org/raspbian_latest
Good luck!

Kratos

[jojopi]

I´m only missing the ejecter.so.

That file is included in the current "lxpanel" package in jessie, but was absent in wheezy. Are you sure you have upgraded correctly?

Also there is something strange about your keyboard configuration (which may not be on the Pi). Somehow you have typed the contraction of "I am" with an acute accent ´ instead of an apostrophe ' or right single quotation mark ’. I mention this not because it is typographically inelegant, but because such errors will cause problems in most programming languages.

[gkreidl]

Can you send it over to me? Would save me a lot of time (downloading Raspbian Jessie image, installing it in a VM, grabbing the file, ...)

I'm actually using the Jessie image. You might save yourself a lot of heartache by just using the Jessie image here.
https://downloads.raspberrypi.org/raspbian_latest
Good luck!

Kratos

This thread is about upgrading not about using a fresh image. And there might be a lot of good reasons why people want to do this.

[Trixster]

Followed the instructions in the op to upgrade from wheezy to Jessie and it worked perfectly, thanks!

There was an issue with Jessie not mounting my nfs shares from my nas but a quick search on the forum provided the fix.

[bartgrefte]

Last night I did this upgrade on another Pi and besides the problems mentioned before, I came across a new one. This started after the 1st reboot after the upgrade and keeps returning after each reboot:

Code: Select all

pi@Tara ~ $ ping 8.8.4.4
connect: Network is unreachable

pi@Tara ~ $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

pi@Tara ~ $ sudo /sbin/route add -net 0.0.0.0 gw 192.168.1.1 eth0
pi@Tara ~ $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

pi@Tara ~ $ ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=49 time=10.4 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=49 time=10.5 ms
^C
--- 8.8.4.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.408/10.473/10.538/0.065 ms
pi@Tara ~ $ 

Any idea why the route to the gateway keeps disappearing? Happened since the upgrade, didn't have this problem last time.

edit: Only happens with IPv4, IPv6 works just fine.

edit2: .... auto eth0 was removed from /etc/network/interfaces somewhere during the upgrading

[welshgeekboy]

Note for those following this guide: Don't copy and paste the instructions to type into the terminal for after the first boot. Or if you do, make sure you edit them so that whenever you see a long '-' replace it with the standard minus symbol.
So...

Code: Select all

cp –ax /usr/share/themes/PiX ~/.themes
sudo rm /etc/xdg/autostart/clipit-startup.desktop
sudo rm /etc/xdg/autostart/wicd-tray.desktop
sudo rm –rf /var/lib/menu-xdg
sudo raspi-config nonint do_boot_behaviour_new B4
sudo rm /usr/share/applications/obconf.desktop

should instead read this:

Code: Select all

cp -ax /usr/share/themes/PiX ~/.themes
sudo rm /etc/xdg/autostart/clipit-startup.desktop
sudo rm /etc/xdg/autostart/wicd-tray.desktop
sudo rm -rf /var/lib/menu-xdg
sudo raspi-config nonint do_boot_behaviour_new B4
sudo rm /usr/share/applications/obconf.desktop

To the human eye there is almost no difference (the 'rf' and 'ax' have a different prefix) but the Pi (or mine at least) will not accept the commands if they are not how I said.
This fixes bartgrefte's problem where they state:

“sudo rm –rf /var/lib/menu-xdg” also doesn't work.
rm: cannot remove '-rf': no such file or directory
rm: cannot remove '/var/lib/menu-xdg': is a directory

I had the same problem but noticed the incorrect command. Perhaps the post owner ought to edit their instructions?

[ibic]

This is very helpful, thanks.

[e-raser]

Note for those following this guide: Don't copy and paste the instructions to type into the terminal for after the first boot. Or if you do, make sure you edit them so that whenever you see a long '-' replace it with the standard minus symbol.
So...

Code: Select all

cp –ax /usr/share/themes/PiX ~/.themes
sudo rm /etc/xdg/autostart/clipit-startup.desktop
sudo rm /etc/xdg/autostart/wicd-tray.desktop
sudo rm –rf /var/lib/menu-xdg
sudo raspi-config nonint do_boot_behaviour_new B4
sudo rm /usr/share/applications/obconf.desktop

should instead read this:

Code: Select all

cp -ax /usr/share/themes/PiX ~/.themes
sudo rm /etc/xdg/autostart/clipit-startup.desktop
sudo rm /etc/xdg/autostart/wicd-tray.desktop
sudo rm -rf /var/lib/menu-xdg
sudo raspi-config nonint do_boot_behaviour_new B4
sudo rm /usr/share/applications/obconf.desktop

To the human eye there is almost no difference (the 'rf' and 'ax' have a different prefix) but the Pi (or mine at least) will not accept the commands if they are not how I said.
This fixes bartgrefte's problem where they state:

“sudo rm –rf /var/lib/menu-xdg” also doesn't work.
rm: cannot remove '-rf': no such file or directory
rm: cannot remove '/var/lib/menu-xdg': is a directory

I had the same problem but noticed the incorrect command. Perhaps the post owner ought to edit their instructions?

Do you see a chance this could be the root cause for my described "graphical issues" (see my posts above)?

[davep]

I decided to upgrade a Jenkins CI cum wifi bridge access point to Jessie last night.

The wifi persistently failed to work (even though I went through all the settings and they worked). It also worked when I launched hostapd manually.

This helped me to whittle down to systemd, which tries to parallelise all the startup services. Wlan0 isn't ready when hostapd tries to run, despite setting the priority of /etc/init.d/hostapd to 5 (rather than 2 3 4 5). I ended up also modifying the start case in hostapd to add a wait so that it runs after wlan0 is started. What a horrible but educational experience that was!

Code: Select all

# Default-Start:        5

Code: Select all

case "$1" in
  start)

        sleep 5

        log_daemon_msg "Starting $DESC" "$NAME"
        start-stop-daemon --start --oknodo --quiet --exec "$DAEMON_SBIN" \
                --pidfile "$PIDFILE" -- $DAEMON_OPTS >/dev/null
        log_end_msg "$?"
        ;;

Which does the job.

[DirkS]

What a horrible but educational experience that was!

If you want another interesting educational experience you could convert it to a systemd service.

I found https://bbs.archlinux.org/viewtopic.php?id=154846 while googling for 'hostapd systemd'

[davep]

What a horrible but educational experience that was!

If you want another interesting educational experience you could convert it to a systemd service.

I found https://bbs.archlinux.org/viewtopic.php?id=154846 while googling for 'hostapd systemd'

Is that syntax possible using Debian rather than archlinux? Also, I thought all the services started in /etc/init.d at startup were systemd services (but I may be confused after a lack of sleep...). Or are you referring to new options available to services under systemd?

Edit: just saw this https://www.digitalocean.com/community/ ... unit-files and my head hurts.

[DirkS]

Is that syntax possible using Debian rather than archlinux? Also, I thought all the services started in /etc/init.d at startup were systemd services

I think you already know, but yes, that's the new systemd syntax introduced in Debian Jessie (and used for a while longer in Arch).
The init.d scripts are still processed by systemd, not sure how it's done to be honest.
I'm still learning... slowly

my head hurts.

I did say it would be an interesting educational experience

[AlxAuckland]

Hi everyone!

I've finally got to trying to upgrade to Jessie, following the method described in the first post.

Can you please confirm whether running

Code: Select all

cat /etc/os-release

should return

Code: Select all

PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
NAME="Raspbian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

after the upgrade?

When following the tutorial I ran

Code: Select all

sudo apt-get -y dist-upgrade

it returned

Code: Select all

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

This could be because, a few months ago, I followed this plex tutorial and added some Jessie repos (have a look at paragraph "Upgrade libc6 to 2.19 on Raspbian").

Now this would I think explain why I'm getting no updated with dist-upgrade.

My question then is why I see PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)" in /etc/os-release?

I'd think I've already got Jessie installed... Is there another way of checking?

Hope this makes sense.

Thanks heaps in advance!

Update: Nevermind... pinning in /etc/perefences.d/ is what was blocking the other dependences to be downloaded

Code: Select all

Package: * 
Pin: release n=jessie 
Pin-Priority: -1

[/b]

[minos]

Is it a problem if I've missed the "ui" at the end of the line ?

If I put it now, after some months withtout, will it be a mess ?
The RPi is only used with console, no GUI... I think about GUI when I see "ui" ?

Thx!

[DougieLawson]

Without the ui some packages won't get updates. Add it now and it will "just work".

[minos]

Thx Dougie for confirmation,
no problem after adding this

[holderbp]

I successfully upgraded using this method on my headless RP2. I have a persistent problem which started after the upgrade, however. My wired ethernet connection will not reconnect after a network disconnect (e.g., unplugging the cable, or a router reboot). I don't have a wireless adapter and I have /etc/network/interfaces configured to use a static IP for eth0. When this first happened, I had to unplug the machine to reboot it whenever the network connection was broken. I have since installed an every-5-minutes cron job to check the connection and restart manually with ifup, following these instructions:

https://samhobbs.co.uk/2013/11/fix-for- ... spberry-pi

I have fiddled with uninstalling and reinstalling ifplugd, commenting/uncommenting the "auto eth0" and the "allow-hotplug eth0" in /etc/network/interfaces but nothing has worked yet. I do have a non-standard entry in /etc/dhcpcd.conf saying "denyinterfaces eth0" that I manually added months ago (and re-added after this upgrade) on this suggestion:

viewtopic.php?p=810461#p810461

in order to remove a second IP given to the machine by my router (one static and one dhcp, despite the "iface eth0 inet static" entry in /etc/network/interfaces).

When an ethernet disconnect happens, I see this in the syslog

Code: Select all

Mar 25 11:32:29 pi225 kernel: [   63.395730] smsc95xx 1-1.1:1.0 eth0: link down
Mar 25 11:32:33 pi225 dhcpcd[828]: sending commands to master dhcpcd process
Mar 25 11:32:33 pi225 dhcpcd[423]: control command: /sbin/dhcpcd -k eth0
Mar 25 11:32:33 pi225 avahi-daemon[400]: Withdrawing address record for 192.168.2.2 on eth0.
Mar 25 11:32:33 pi225 avahi-daemon[400]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.2.2.
Mar 25 11:32:33 pi225 avahi-daemon[400]: Interface eth0.IPv4 no longer relevant for mDNS.
Mar 25 11:32:33 pi225 kernel: [   67.431247] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:33 pi225 kernel: [   67.507021] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:33 pi225 dhcpcd[874]: sending commands to master dhcpcd process
Mar 25 11:32:33 pi225 dhcpcd[423]: control command: /sbin/dhcpcd -k eth0
Mar 25 11:32:33 pi225 kernel: [   67.922302] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:33 pi225 kernel: [   67.996920] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:35 pi225 ntpd[640]: Deleting interface #3 eth0, 192.168.2.2#123, interface stats: received=29, sent=29, dropped=0, active_time=61 secs
Mar 25 11:32:35 pi225 ntpd[640]: 216.218.254.202 interface 192.168.2.2 -> (none)
Mar 25 11:32:35 pi225 ntpd[640]: 173.230.144.178 interface 192.168.2.2 -> (none)
Mar 25 11:32:35 pi225 ntpd[640]: 209.208.79.69 interface 192.168.2.2 -> (none)
Mar 25 11:32:35 pi225 ntpd[640]: 207.224.49.219 interface 192.168.2.2 -> (none)
Mar 25 11:32:35 pi225 ntpd[640]: peers refreshed
Mar 25 11:32:37 pi225 kernel: [   71.919866] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Mar 25 11:32:39 pi225 dhcpcd[917]: sending commands to master dhcpcd process
Mar 25 11:32:39 pi225 dhcpcd[423]: control command: /sbin/dhcpcd -k eth0
Mar 25 11:32:39 pi225 kernel: [   73.576232] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:39 pi225 kernel: [   73.656956] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:39 pi225 kernel: [   73.823011] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:39 pi225 dhcpcd[939]: sending commands to master dhcpcd process
Mar 25 11:32:39 pi225 dhcpcd[423]: control command: /sbin/dhcpcd -k eth0
Mar 25 11:32:39 pi225 kernel: [   73.917075] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:41 pi225 kernel: [   75.360006] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Mar 25 11:32:41 pi225 dhcpcd[944]: sending commands to master dhcpcd process
Mar 25 11:32:41 pi225 dhcpcd[423]: control command: /sbin/dhcpcd -h pi225 --noipv4ll eth0
Mar 25 11:32:46 pi225 dhcpcd[1000]: sending commands to master dhcpcd process
Mar 25 11:32:46 pi225 dhcpcd[423]: control command: /sbin/dhcpcd -k eth0
Mar 25 11:32:46 pi225 kernel: [   80.604219] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:46 pi225 kernel: [   80.687858] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Mar 25 11:32:48 pi225 kernel: [   82.347484] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Mar 25 11:35:01 pi225 CRON[1048]: (root) CMD (bash /home/pi/local/bin/network-monitor.sh)
Mar 25 11:35:01 pi225 avahi-daemon[400]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.2.2.
Mar 25 11:35:01 pi225 avahi-daemon[400]: New relevant interface eth0.IPv4 for mDNS.
Mar 25 11:35:01 pi225 avahi-daemon[400]: Registering new address record for 192.168.2.2 on eth0.IPv4.
Mar 25 11:35:02 pi225 systemd[1]: Stopping User Manager for UID 1000...
Mar 25 11:35:02 pi225 systemd[718]: Stopping Default.
Mar 25 11:35:02 pi225 systemd[718]: Stopped target Default.
Mar 25 11:35:02 pi225 systemd[718]: Stopping Basic System.
Mar 25 11:35:02 pi225 systemd[718]: Stopped target Basic System.
Mar 25 11:35:02 pi225 systemd[718]: Stopping Paths.
Mar 25 11:35:02 pi225 systemd[718]: Stopped target Paths.
Mar 25 11:35:02 pi225 systemd[718]: Stopping Timers.
Mar 25 11:35:02 pi225 systemd[718]: Stopped target Timers.
Mar 25 11:35:02 pi225 systemd[718]: Stopping Sockets.
Mar 25 11:35:02 pi225 systemd[718]: Stopped target Sockets.
Mar 25 11:35:02 pi225 systemd[718]: Starting Shutdown.
Mar 25 11:35:02 pi225 systemd[718]: Reached target Shutdown.
Mar 25 11:35:02 pi225 systemd[718]: Starting Exit the Session...
Mar 25 11:35:02 pi225 systemd[718]: Received SIGRTMIN+24 from PID 1125 (kill).
Mar 25 11:35:02 pi225 systemd[1]: Stopped User Manager for UID 1000.
Mar 25 11:35:02 pi225 systemd[1]: Stopping user-1000.slice.
Mar 25 11:35:02 pi225 systemd[1]: Removed slice user-1000.slice.
Mar 25 11:35:02 pi225 systemd[1]: Reloading OpenBSD Secure Shell server.
Mar 25 11:35:02 pi225 systemd[1]: Reloaded OpenBSD Secure Shell server.
Mar 25 11:35:02 pi225 sSMTP[1149]: Creating SSL connection to host
Mar 25 11:35:03 pi225 ntpd[640]: Listen normally on 4 eth0 192.168.2.2 UDP 123
Mar 25 11:35:03 pi225 ntpd[640]: peers refreshed
Mar 25 11:35:03 pi225 sSMTP[1149]: SSL connection using RSA_AES_128_CBC_SHA1

Could anyone suggest what is occuring here and how I might fix it? Thanks!

[ts_meyer]

When I follow the instructions, everything goes as expected including the "Calling CRDA to update world regulatory domain". This continues until there is a message saying: "Exceeded CRDA call max attempts. Not calling CRDA" The system then freezes. It does not respond to any keystrokes. When rebooted the identical problem occurs.

This occurs whether connected by bluetooth or hardline.

Any ideas?

Thanks,
Tom

[dgordon42]

@ts_meyer, try:

Code: Select all

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install crda

This will install CRDA, which should automatically install iw and wireless-regdb also.
At boot up, Jessie uses these applications to get and set the WiFi rules (frequencies, channels, power levels, etc.) for your country.
You can set your WiFi country using an up to date:

Code: Select all

sudo raspi-config

or you can add the line:

Code: Select all

country=XX

to your /etc/wpa_supplicant/wpa_supplicant.conf file, where XX is your country's ISO 3166 code.
Some WiFi dongle drivers don't need all this stuff to work, but the built in WiFi in the Pi 3 does.
I have also found that having CRDA installed in Jessie reduces boot times by about 20 secs on a Pi B+!

Hope this helps,
Dave.

[Abe_Stew]

Planning on upgrading my pi that runs wordpress. However, whenever I run apt-get upgrade it always breaks my site as the wordpress version on the repository is always behind whatever version is currently running on the site. Is there a way to remove wordpress from the list of packages apt-get thinks are installed on my pi? Tried googling for a solution but only getting results for how to uninstall a package which isn't what I want to do.

[dgordon42]

You can try:

Code: Select all

sudo apt-mark hold wordpress

This should prevent apt-get from upgrading wordpress.
See 'man apt-mark' for more details.

Hope this helps,
Dave.

[Abe_Stew]

You can try:

Code: Select all

sudo apt-mark hold wordpress

This should prevent apt-get from upgrading wordpress.
.

Thanks for the reply. Unfortunately that results in:

The following packages have unmet dependencies:
php5 : Depends: libapache2-mod-php5 (>= 5.4.45-0+deb7u2) but it is not going to be installed or
libapache2-mod-php5filter (>= 5.4.45-0+deb7u2) but it is not going to be installed or
php5-cgi (>= 5.4.45-0+deb7u2) but it is not going to be installed or
php5-fpm (>= 5.4.45-0+deb7u2) but it is not going to be installed
udev : Breaks: plymouth (< 0.9.0-7) but 0.8.5.1-5 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Is there any way round this?

[Abe_Stew]

Decided to remove the hold and go ahead with the upgrade. Christ almighty it was a headache to get everything working again after. Manually updating wordpress ended up being the easiest issue to solve. Apache 2.4 changed some of the config options you need to set for virtual hosts; had to play about in few config files for few other programs to get them started again; while 'upgraded' a number of dependencies for php and mysql were missing preventing other programs from working (a forced reinstall of those that werent working helped me find a few but rest was through google); squirrelmail for some reason was automatically uninstalled when I tried to reinstall apache - no prompt was given, just got message that apt-get was removing squirrelmail; and webdav was broken requiring a forced reinstall of the package to provide a prompt to allow non-root users to mount webdav shares. Managed to get everything working again except redirecting https to http on my website. However, I've given up on that as planning to get round to sorting ssl certificates on it soon anyway.

[_Annie_]

I did the update today on my RPi2. It's a headless running machine used for several services.

For this task I used a keyboard and monitor just for once in order to avoid any troubles using ssh.

I always chose to keep the configuration files and ran into the error message that apache2 couldn't restart due to the following error:

Code: Select all

May 14 16:29:55 RPI2 phpmyadmin: apache2_reload: AH00526: Syntax error on line 89 of /etc/apache2/apache2.conf:
May 14 16:29:55 RPI2 phpmyadmin: apache2_reload: Invalid command 'LockFile', perhaps misspelled or defined by a module not included in the server configuration

For those who encounter the same error, edit your /etc/apache2/apache2.conf and replace

Code: Select all

LockFile ${APACHE_LOCK_DIR}/accept.lock

with

Code: Select all

Mutex file:${APACHE_LOCK_DIR} default

then restart apache2:

Code: Select all

sudo /etc/init.d/apache2 restart

[andrewjs18]

hi all,

admittingly I didn't read this thread prior to starting my upgrade from wheezy to jessie...I searched online as I don't do too many dist-upgrades with *nix and forgot how to properly run one...

basically, I ran these commands and the upgrade was off:

Code: Select all

sudo apt-get update
sudo apt-get upgrade
sed -i 's/wheezy/jessie/g' /etc/apt/sources.list
sudo apt-get dist-upgrade

the upgrade was running for about an hour before hitting these errors then stopping:

Code: Select all

Errors were encountered while processing:
 gvfs-backends
 gvfs-daemons
 gvfs:armhf
 xpdf
 console-setup-linux
 gvfs-fuse

any help would be greatly appreciated!