[opensuse] upgrade disaster 9.3 > 10.3
It was an older machine that I had just migrated off of so I didn't loose anything, but it was not able to complete. Just getting a report out in case anyone else is wondering if it might work. It did not accept the password on the encrypted partition it did not recognize /boot as ext2 it did not recognize the /opt /usr /tmp /var that were reiser it was unable to resolve numerous packages, it recommend deleting them it was unable to update the grub boot menu on /boot -- Collector of vintage computers http://www.ncf.ca/~ba600 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun November 11 2007 10:10:01 am Mike wrote:
It was an older machine that I had just migrated off of so I didn't loose anything, but it was not able to complete. Just getting a report out in case anyone else is wondering if it might work.
It did not accept the password on the encrypted partition it did not recognize /boot as ext2 it did not recognize the /opt /usr /tmp /var that were reiser
it was unable to resolve numerous packages, it recommend deleting them
it was unable to update the grub boot menu on /boot
Hi Mike, Your experience isn't surprising since 9.3 and 10.3 are significantly different. In fact, there were three full releases *between* them. You'd probably have had much better luck trying it incrementally: 9.3 to 10.0 10.0 to 10.1 10.1 to 10.2 10.2 to 10.3. The reason I'd expect greater success doing it incrementally is each release is designed to recognize and cope with idiosyncracies of the prior release... not /all/ prior releases. Personally, I've only ever had success doing "fresh" installations on truly clean partitions (not just "formatted" during installation, but wiped first.) My /home lives on a separate partition that I select to *not* be formatted during installation. Instead, I create another user like 'carl2' to ensure a completely contemporary and fresh user environment at the start. After I've confirmed there are no 'show stoppers,' I gradually migrate documents and custom settings, etc., over to the new environment. I do this part one application at a time. regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carl Hartung wrote:
Personally, I've only ever had success doing "fresh" installations on truly clean partitions (not just "formatted" during installation, but wiped first.)
But wiped too? That's just overkill. The only report I've heard recently of anything approaching needing a "wipe" was when the Windows NTFS formatter left a reiserfs superblock intact on disk. Even then, zeroing out a single block fixed the problem. Otherwise, as far as the installer and kernel are concerned, the file system is gone if it's been formatted over. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHNyorLPWxlyuTD7IRAjUAAJ42R+mZ7WfXvKGgCj65eBEPPICi9ACgiaqg btF4DiN7A2fDhFsp5j++X08= =0iIE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun November 11 2007 11:13:31 am Jeff Mahoney wrote:
Carl Hartung wrote:
Personally, I've only ever had success doing "fresh" installations on truly clean partitions (not just "formatted" during installation, but wiped first.)
But wiped too? That's just overkill. The only report I've heard recently of anything approaching needing a "wipe" was when the Windows NTFS formatter left a reiserfs superblock intact on disk. Even then, zeroing out a single block fixed the problem. Otherwise, as far as the installer and kernel are concerned, the file system is gone if it's been formatted over.
Hi Jeff, I've been 'doing computers' and electronics since 1986 and lived and worked in the industry in Silicon Valley for over a dozen years. That time was split roughly equally between software and hardware manufacturing :-) Your understanding and assertion is logical to both of us but it is only a design ideal/objective. Empirically, over the past three years, I know of three circumstances where exceptions have surfaced -- 'ghost' files from prior installations appeared alongside expected, current data. Since much of the logic has migrated down into the drives, themselves, and each manufacturer and production release carries it's own 'flavor' of hardware and firmware... since this also causes drivers to be moving targets... we will *always* be contending with 'special cases.' I don't consider it "overkill" to guard against these eventualities when the extra steps do not consume much time and are free. If we had to send drives out to specialists to be 'wiped' for a price, I'd probably conclude differently. :-) This, of course, is dependent upon existential variables such as 'Is this a test or hobby or production system?' and 'How 'fresh' vs. 'mature' is the hardware I'm installing on?' and so on. Anyway, I appreciate your comments and I hope this sheds some new light on the topic for you. regards, Carl P.S. Please reply only to the list. I don't need two copies of your posts. :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 11 Nov 2007, Mike wrote:-
It was an older machine that I had just migrated off of so I didn't loose anything, but it was not able to complete. Just getting a report out in case anyone else is wondering if it might work.
As a counterpoint, I very recently (yesterday) upgraded a 9.3 system to 10.3 and it did work. However, I did take some precautions while performing the install, including manually editing /etc/fstab to handle the changes from hdx to sdx, and the remapping of what were sda and sdb onto sdc and sdd. For the curious, I even wrote about it here: <URL:http://www.davjam.org/lifetype/index.php?op=ViewArticle&articleId=17&blogId=1> <URL:http://www.davjam.org/lifetype/index.php?op=ViewArticle&articleId=18&blogId=1> <URL:http://www.davjam.org/lifetype/index.php?op=ViewArticle&articleId=19&blogId=1>
It did not accept the password on the encrypted partition
That I don't have, so can't say whether it would have worked or not.
it did not recognize /boot as ext2
Whereas it was recognised on mine. The only problem I found was when it came to mount the different partitions, I had to tell the installer that the /boot partition was on /dev/sda1 and not on /dev/hda1 where it thought it was. It also required changing the mount points for partitions on /dev/hdb to /dev/sdb.
it did not recognize the /opt /usr /tmp /var that were reiser
I didn't have any separated partitions, apart from /boot and the Windows partitions, so can't say if they would have been recognised.
it was unable to resolve numerous packages, it recommend deleting them
That I noticed as well. When I performed my upgrade, there were a total of 480 packages to delete. Despite this, the only package dependency problem I had was with the upgrade of the libpano packages, where the dependency checker couldn't sort the dependencies out. Eventually, I just deleted the libpano12, libpano-devel and libpano-tools packages, and there were no dependency problems.
it was unable to update the grub boot menu on /boot
Again, I didn't have a problem here. This could have been because, during the installation I edited /etc/fstab and /boot/grub/device.map to correct the device names, or the editing may have been unnecessary. I don't know either way. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys | SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit | RISC OS 3.11 | RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 11 November 2007 11:25:59 am David Bolt wrote:
it was unable to update the grub boot menu on /boot
Again, I didn't have a problem here. This could have been because, during the installation I edited /etc/fstab and /boot/grub/device.map to correct the device names, or the editing may have been unnecessary. I don't know either way.
Hi David, One of things about not supported old versions is that fstab and boot loader update are dropped out for such versions. It may succeed, but there is no workarounds for differences. You can look, for instance, in post install scripts of kernel update 2.6.22.12-0.1 and see the lines: # handle 10.2 and SLES10 SP1 # handle 10.1 and SLES10 GA but there is no reference on 10.0 like before. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 11 Nov 2007, Rajko M. wrote:-
On Sunday 11 November 2007 11:25:59 am David Bolt wrote:
it was unable to update the grub boot menu on /boot
Again, I didn't have a problem here. This could have been because, during the installation I edited /etc/fstab and /boot/grub/device.map to correct the device names, or the editing may have been unnecessary. I don't know either way.
Hi David,
One of things about not supported old versions is that fstab and boot loader update are dropped out for such versions.
Maybe so. In theory, it should work since there's no real difference between menu.lst, device.map and fstab between 9.3, 10.0 and 10.2. It's only with 10.3 do the device mapping change and again, in theory, this should be handled as if the upgrade was from 10.2. I edited /etc/fstab and /boot/menu/device.map because the installer wanted to mount the /boot partition and a couple of Windows partitions. I don't know why it wanted the Windows partitions, but it referred to them as hdb1 and hdb5 when they should have been sdb1 and sdb5. My guess, after reading Carlos' reply, and then looking at the Most Annoying Bugs page, is that the confusion over the device names was related to bug #330705. While it mentions a separate /var causing problems, I think having the mixed PATA and SATA configuration confused the upgrade code and so needed the manual assistance to sort it out.
It may succeed, but there is no workarounds for differences.
I think that the procedure detailed here: <URL:http://en.opensuse.org/How_To_Upgrade_System_with_Separate_/var_Partition> should work. I'll have to try that method out the next time I have a huge version jump to perform. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys | SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit | RISC OS 3.11 | RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-11-12 at 01:07 -0000, David Bolt wrote: ...
I think that the procedure detailed here:
<URL:http://en.opensuse.org/How_To_Upgrade_System_with_Separate_/var_Partition>
should work. I'll have to try that method out the next time I have a huge version jump to perform.
That method can apply even from 10.2 to 10.3 if you have a mixture of disks and the system is spread. Ie, anytime that the device naming can be confusing, labels remain where they should be. IMO, I think we should all be moving our fstab and perhaps menu.lst to that scheme. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHN7JKtTMYHG2NR9URAqBHAJ9FwebP2wn404FExWPkN4Wzi9XIPgCeLCvL wMtGR9aE2Qf9r8dV8/V9rSA= =ThTH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-11-11 at 17:25 -0000, David Bolt wrote:
On Sun, 11 Nov 2007, Mike wrote:-
it did not recognize the /opt /usr /tmp /var that were reiser
I didn't have any separated partitions, apart from /boot and the Windows partitions, so can't say if they would have been recognised.
<http://en.opensuse.org/Bugs:Most_Annoying_Bugs_10.3> ] * Upgrading from openSUSE 10.2 (or older) fails on systems with a ] separate /var partition (Bug #330705). Workaround: Change the way ] how /var gets mounted before starting the upgrade. So... The only thing I can say is that that page is not listed right in the download page, nor the release notes (<http://software.opensuse.org/>), and both should be. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHN2KRtTMYHG2NR9URAsVLAKCKME1+D5hAfiziURc52zgJ6V9TzACffhZ5 Z7xz/6NfKI+wVHSrQEiVen0= =Z1P1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (6)
-
Carl Hartung -
Carlos E. R. -
David Bolt -
Jeff Mahoney -
Mike -
Rajko M.