beta and final release question

[newbie1]

If you install Natty daily release now.....

What is the upgrade procedure with beta and final releases?

Can it be updated through command line or update manager or do you have to do complete iso install?

Thanks.

[kapil]

Re: beta and final release question

plain "sudo apt-get dist-upgrade" in konsole would upgrade 10.10 or natty to the latest version.
you need not download the .iso file.

[GreyGeek]

Re: beta and final release question

What Kapil says.

I usually start with the Alpha of a release, as I did with my current Lucid installation, and continue with the update/upgrade procedure. However, I won't cross version lines with a dist-upgrade. I prefer to being a new version with a fresh install.

[kapil]

Re: beta and final release question

@GG: please can you elaborate, "..i won't cross version lines.."
if you are using sudo apt-get upgrade then, it won't upgrade to the latest version.
so, how will the os upgrade from say alpha to beta or release candidate?

[GreyGeek]

Re: beta and final release question

http://www.ghacks.net/2010/03/11/wha...on-of-apt-get/

But doesn’t it upgrade my distro?

Not necessarily. Although, by itself, dist-upgrade, will prepare your system for a distribution upgrade, the only way it will actually perform the upgrade to a new release is if you have changed your /etc/apt/sources.list file to reflect the change. In other words, you have to add the repositories for the new distribution in the sources.list file before this can happen.

Well that sounds simple. Yes it is. But it is not the recommended plan of attack for upgrading to a new distribution ...
...
Distribution upgrades are always tricky. I have had them go exceedingly well and I have had them go very awry.

One problem I have encountered when doing an dist-upgrade (even with changing sources.list to the new repository) is that I am frequently asked if I want to keep an old config file or use the developer's new one. How should I know without examining the each and every config file to see if its change date means I have changed it, and then determine how I have changed it and if I want to keep those changes or just let the install replace it with the new config file.

Having tried both a dist-upgrade many times, and a fresh install, it is my experience that saving my data, always a good practice, doing a fresh install from a verified LiveCD, and installing those additional applications and those parts of my old data that I think I'll need generally results in a desktop which is all-around better, IME, than a dist-upgrade with the new sources.list file. A dist-upgrade with the old version's sources.list file *might* work but often when you hear about an application that works in the newest version and you attempt to install it, you find it is not in your sources.list repositories, which confuses some folks.

I am running Lucid 10.04.2. Here is what sudo do-release-upgrade -d showed me:

jerry@sonyvgnfw140e:~$ sudo do-release-upgrade -d
[sudo] password for jerry:
Checking for a new ubuntu release
Done Upgrade tool signature
Done Upgrade tool
Done downloading
extracting 'maverick.tar.gz'
authenticate 'maverick.tar.gz' against 'maverick.tar.gz.gpg'
tar: Removing leading `/' from member names

Reading cache

Checking package manager
Reading package lists... Done
Building dependency tree
Reading state information... Done
Building data structures... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Building data structures... Done
No candidate ver: lobasis3.3-calc
No candidate ver: lobasis3.3-draw
No candidate ver: lobasis3.3-core02
No candidate ver: virtualbox-3.2
No candidate ver: lobasis3.3-math
No candidate ver: lobasis3.3-impress
No candidate ver: lobasis3.3-writer
No candidate ver: lobasis3.3-base

Updating repository information
WARNING: Failed to read mirror file

Third party sources disabled

Some third party entries in your sources.list were disabled. You can
re-enable them after the upgrade with the 'software-properties' tool
or your package manager.

[100%] 1114kB/s 0s
Checking package manager
Reading package lists... Done
Building dependency tree
Reading state information... Done
Building data structures... Done

Calculating the changes

Calculating the changes
No candidate ver: lobasis3.3-calc
No candidate ver: libkfontinst4
No candidate ver: liblancelot0
No candidate ver: libplasma-applet-system-monitor4
No candidate ver: lobasis3.3-draw
No candidate ver: libprocessui4
No candidate ver: libweather-ion4
No candidate ver: lobasis3.3-core02
No candidate ver: libqt4-multimedia
No candidate ver: libktorrent1
No candidate ver: libmarble4
No candidate ver: libkonqsidebarplugin4
No candidate ver: libbrasero-media0
No candidate ver: libsolidcontrol4
No candidate ver: kmymoney2-common
No candidate ver: libprocesscore4
No candidate ver: virtualbox-3.2
No candidate ver: lobasis3.3-math
No candidate ver: libavutil49
No candidate ver: lobasis3.3-impress
No candidate ver: libtaskmanager4
No candidate ver: flashplugin64-installer
No candidate ver: kdepimlibs-data
No candidate ver: libplasmaclock4
No candidate ver: lobasis3.3-writer
No candidate ver: lobasis3.3-base
No candidate ver: libkwineffects1

Do you want to start the upgrade?

11 installed packages are no longer supported by Canonical. You can
still get support from the community.

11 packages are going to be removed. 108 new packages are going to be
installed. 1344 packages are going to be upgraded.

You have to download a total of 1493M. This download will take about
22 minutes with your connection.

Fetching and installing the upgrade can take several hours. Once the
download has finished, the process cannot be cancelled.

It's looks pretty grim for doing a release upgrade, primarily because in the YEAR I have been using Lucid I have installed many packages from outside the repository, something I don't recommend that newbies do.
The install would require pulling a LOT of bytes down the wire, which is something I would do with an ETH0 connection, but not a Wifi connection which is prone to random disconnects. I could install from a LiveCD in 30 minutes, and spend the same amount of additional time installing my non-LiveCD apps -- just as fast as a network version upgrade but considerably more reliable.

[woodsmoke]

Re: beta and final release question

GG

As to whether to keep config files or do the new, I wait to view a reply also.

Excellent question and one that I am sure that a lot of people would like to know also.

Since I'm not too bright, I might have put it like this:

"Can a list be made, so that the user can print it out, which, shows, particularly, that "this or that" is something that, if the user likes it that way because the user made it that way, then keep it; otherwise it is something that the devs have made and you are on your own as to whether to keep it or not."

Or something like that.

woodsmoke

[GreyGeek]

Re: beta and final release question

Woodsmoke,
I've gotten lazy in my old age ... I generally default to replacing the old config file with the new ones. Some of them are over a Kb in size and leafing through a couple dozen config files, and their hundreds, if not thousands, of lines of settings, to decide if I want to change any is just too much, IMO. Even with the descriptive names I doubt that most folks would know what 90% of those settings mean or do.

Here are the files that end with ".conf" in or under the /etc directory:

/etc/adduser.conf
/etc/blkid.conf
/etc/ca-certificates.conf
/etc/chkrootkit.conf
/etc/debconf.conf
/etc/deluser.conf
/etc/dvdwizard.conf
/etc/fdmount.conf
/etc/ffserver.conf
/etc/fodtrack.conf
/etc/foremost.conf
/etc/fuse.conf
/etc/gai.conf
/etc/gconf
/etc/hdparm.conf
/etc/host.conf
/etc/insserv.conf
/etc/insserv.conf.d
/etc/ipfm.conf
/etc/kernel-img.conf
/etc/kerneloops.conf
/etc/ld.so.conf
/etc/lftp.conf
/etc/libao.conf
/etc/logrotate.conf
/etc/ltrace.conf
/etc/mke2fs.conf
/etc/mtools.conf
/etc/netscsid.conf
/etc/nsswitch.conf
/etc/ntp.conf
/etc/pam.conf
/etc/pnm2ppa.conf
/etc/popularity-contest.conf
/etc/resolv.conf
/etc/resolvconf
/etc/rkhunter.conf
/etc/rsyslog.conf
/etc/sensors3.conf
/etc/smi.conf
/etc/sword.conf
/etc/sysctl.conf
/etc/ts.conf
/etc/ucf.conf
/etc/updatedb.conf
/etc/wodim.conf
/etc/gconf/2/evoldap.conf
/etc/gconf/2/path
/etc/ld.so.conf.d/GL.conf
/etc/ld.so.conf.d/lib32asound2.conf
/etc/ld.so.conf.d/libasound2.conf
/etc/ld.so.conf.d/libc.conf
/etc/ld.so.conf.d/x86_64-linux-gnu.conf

Then there are the couple dozen files that reside in ~/.kde and its subdirectories and end with *.rc.

So, now you see why I just ride on automatic and let the developers make the decisions when ever I am asked. Usually, when I do a fresh LiveCD install I am not asked about conf or rc file settings.

[dibl]

Re: beta and final release question

I just ride on automatic and let the developers make the decisions when ever I am asked.

I do too, normally. I will note for the record, however, that I snarfed a system good one time when I took the developer's version of Grub and its configuration files.

But I also agree that a clean new installation brings not only a known stable system configuration, but a chance to set up things anew, maybe try the panel on top, or the side, check out new wallpapers, etc. I have seen Kubuntu version upgrades work just fine, and I've never personally experienced a failure of a version upgrade, but I usually opt for the new installation, just to make sure I'm on a deterministic task of known duration.

[Snowhog]

Re: beta and final release question

As a 'general' rule, when an update tells me that the developers file is different than what is installed, I opt to keep what's already on the system, as it is a file that I modified. The grub file is a good example, as well as the kdmrc. If you made changes to those, and you allow them to be replaced in an update, you will have problems (that can be fixed, but why go through the trouble).

[claydoh]

Re: beta and final release question

As to the OP's question, if you have installed natty in a pre-release version, you do nit have to do anything to 'update' to any future pre-release or Final. As you update your system, you are kept as up-to-date as you can be. There will be no need to reinstall unless you desire to do so

Now as to upgrading/ clean installs I do both
My desktop has been upgraded from Karmic to Lucid to Maverick without reinstall or major trouble that I can remember. The gui upgrade tool disables any ppa's added before performing the upgrade, as well as a few other things, even dealing with proprietary drivers has not been an issue for me.

On my laptops, I usually have one that I upgrade and one that I clean install so I can see how it goes on each as they are exactly identical. Now that I have a newer, third laptop, I will probably keep that one running pre-releases from about Alpha 2 onwards. With a dual boot to the previous stable version as I have plenty of disk space now so I can test upgrades as well