Upgrade with losing settings?

None of those things is part of the kernel configuration. Don't think of Linux as a monolithic mess like Windows; it's a collection of parts which communicate through standard interfaces, so replacing one with a newer version rarely affects others.

Of course if you're using a closely-coupled desktop environment like Gnome all bets are off.

Did you try apt-get update && apt-get upgrade ? Of course you'll take a backup copy of your memory card first.

You can also edit the apt-get configuration by replacing reference wo 'wheezy' with 'stable'. I'm told that this means that when the current stable version, wheezy, is replaced with a new stable version you'll get a seamless transition, though (surprise!) the first upgrade after the switch will be rather large.

I've set my RPi up this way.

This is apparently a unique feature of the Debian package management and may not for distros that use other package management systems, e.g SUSE and RedHat - it certainly doesn't work for Redhat and its yum-using clones and descendents.

This is possible, but it's caused problems in the past, which is why it's no longer the default. Better in my experience to do the upgrade explicitly, with the upgrade notes to hand.

Thanks for that encouragement, Rob. Yes, I did the backup and the upgrade, and almost everything was left intact. There was one minor change I had made to /etc/dhcp/dhcpclient.conf, but it was insignificant. I was then able to add my own compiled 3.6.11 kernel with PPS support, and the upgrade had even left my own more recent NTP intact.

Impressed and encouraged!

Also you need to have drivers for the hardware. There are at least two major driver changes (in the interface driver-linux) in that range of versions.

The actual mechanics of the upgrade would depend on the installation, which distribution is this?

If it is debian or debian-related it may be as simple as "apt-get update; apt-get upgrade".

-- mrr

Thanks for the warning. However, I'll leave the mod in place to see what happens. I won't loose anything except time. The stuff I really care about is under version control in my house server's CVS repository. In addition, I make a weekly rsync backup of the entire RPi filing system and hold two generations of this offline in a fire safe.

IMO its a good idea to make copies of any config files that you've explicitly changed and keep them somewhere where they can't be overwritten by clean reinstalls, etc.

I keep them in a user directory (my pi is called 'rpi', so all this stuff lives in ~/rpi/etc/* in my usual login. This way, you can use diff if you suspect a config file has been referted to factory state and, depending on the scale of the changes, either flop your saved file back or edit and re-save the new version.

I also move /usr/local to /home/local and replace /usr/local with a symlink to /home/local - again, this preserves locally generated scripts and programs from destruction by a clean install: /usr/local* is an empty directory structure, so after a fresh install, if /home is in its own partition all you need is to do this:

rm -rf /usr/local; ln -s /home/local local

and your locally developed stuff is back in business.

If /home is just a directory in a single partition, you'd need to pull /home/* off your last backup before setting up the symlink. If this looks like a good idea to you, there is a more comprehensive description here:

The likely problem you'll encounter is that the next stable release (jessie) is likely to be some time away - probably a year or more. By then you'll have forgotten what you did, and unless you keep an eagle eye open, you'll suddenly be inundated by an upgrade, when you're least expecting it, and which may take several hours. You may not even immediately realise it's happened, until the changes come to bite you.

Some package upgrades may be incompatible with existing code (I had a nasty problem with mySQL upgrade from squeeze to wheezy), Some packages may have subtly different features.

You should always read the release notes, and prepare for an upgrade, before doing it.

My advice, from experiencing several dist-upgrades since etch is to let others sort out the teething troubles, and do an ordered upgrade, when you're ready and prepared for it.

Alternatively, go for "testing", at least the changes will be gradual, and breakages likely to be short-lived and confined to single packages. I think you currently have the worst of all worlds there.

Cheers, Tony

Point, though it seems not to be an issue with Fedora, though I admit that I've never gotten its package upgrade to work. As a result I always do a clean reinstall. That said, I've been using RedHat since 6.2 and Fedora since version 1, the only package glitch I've seen over several years is with PostgreSQL and its well-known requirement to dump and restore the database if there's a major point version upgrade and consequent change in the physical database structure.

I was really hoping that this would allow me to avoid Fedora's (too) regular need to reinstall the whole schmeer, but from what you say this isn't possible without getting closer to the bleeding edge with 'stable'.

Oh well, any suggestions on how to set up the RPi with /home in its own partition (so it can survive a clean reinstall) would be useful. I don't understand how to do that, since new versions seem to come as partition images rather than something you'd install onto a pre-existing set of partitions.

Debian-descended distros are much better at upgrading than RH-descended distros. I've never had to do a scratch reinstall on any Debian box, and I've been running them for 15+ years.

So, are you saying that I should just stick with apt-get pointing at wheezy until the whistle blows and then point it to the next version, grit teeth and run the massive upgrade?

If so that seems like quite a reasonable plot.

That's what I do. The advantage over pointing at stable is that you can choose when the massive upgrade happens (you get about a year of security updates on what's now oldstable), arm yourself with the release notes (which have an upgrade procedure section that'll mention any strangenesses), and so on.

If you're worried about the upgrade going sour it's often easy to take a backup of the sd card

?ebian if very good at spotting changes made to configuration files if the new version has the same default configuration file your version will be kept else you'll be prompted.

Well, I've mostly been running Debian Testing for the past 8 years or so and only occasionally hit a problem where I've had to regress any update. Mostly I've had issues where I've had to pull in a later version of a package from Sid/Unstable when some service (like MSN) have changed protocols and the old software can't connect.

Major upgrades have been pretty painless.

(rp)Dom Essex, UK

Thanks guys.

I just switched apt back to using wheezy rather than stable.

On 16/11/2013 14:30, Morten Reistad wrote: []

They are both standard Raspberry Pi Linux - based on Debian. Yes, the apt-get update/upgrade sequence worked with very little configuration lost, and I was then able to install my improved 3.6.11 kernel & modules for NTP.

That alone wont migrate you from one major release to another.

You need - at least on a desktop - to point apt at a new repository.

Now if the apt people have d0one their work, that works, but you can run into trouble if a whole subsystem has been replaced from one major release to another, or packages dropped altogether.

Which is why the general advice is to back up everything, and reinstall from scratch, and then replace home directories and hand edit such configuration files are as are needful to restore as much of what was there as you need to.

To put it succinctly: apt copes very well with evolution, but not so well with revolution.

In my case major upgrades of this sort are generally a good excuse to clear all sorts of clutter off the machine - stuff I installed and found not ft for purpose, custom installs of stuff hoping to fix a problem, that didnt, and the like.

Here the last time the machine went into guru meditation mode and the desktop failed to load correctly, I bit the bullet and wiped its disk and went up a version with a clean install. The whole process took less than 4 hours, because I have everything backed up nightly, and could maintain the 'old machine's' archive for selective harvesting of config files to build the new one with.

Most tellingly restoring the previous home directory made about 90% of all the user configuration magically reappear.

It was the content of /usr/local* and the crontabs and a bit of mailer config** that took the rest of the time.

• that's where I put custom icons scripts code and generally stuff I have 'added' to the system.

** my system is set to (exim) mail root error messages and daemon errors messages to my pop style email account.

You certainly _can_ do that, but it's rather more work than a straight upgrade, and to claim that a scratch reinstall is "the general advice" for Debian-based distributions is at best a misrepresentation.