Differences

This shows you the differences between two versions of the page.

--- system:32-bit_to_64-bit [2014-05-07T19:32:24+0000] – $PS2 --> PS2 michael_paoli
+++ system:32-bit_to_64-bit [2018-02-26T22:28:31+0000] (current) – michael_paoli
@@ Line 59: / Line 59: @@
 (I did that to avoid all the insert/remove CD stuff, and if I needed
 packages from either, to generally go much lighter on the mirrors).
-I then updated my /etc/apt/sources.list so it's active lines contained:
+I then updated my /etc/apt/sources.list so its active lines contained:
 deb [arch=amd64] file:/media/cdrom9 wheezy main
 deb [arch=i386] file:/media/cdrom8 wheezy main
@@ Line 71: / Line 71: @@
 # apt-get update
-One should be sure one's package are in a clean state before proceeding, e.g. see:
+One should be sure one's packages are in a clean state before proceeding, e.g. see:
 http://www.debian.org/releases/wheezy/i386/release-notes/ch-upgrading.en.html#system-status
 and especially:
@@ Line 122: / Line 122: @@
 dependencies have already been met, or not or if any conflicts or other
 problems show up.  If/when you encounter any predepends, those need to
-be installed first, not a the same time with dpkg.
+be installed first, not at the same time with dpkg.
 You'll want to be able to use dpkg fairly well, it's lower-level than
@@ Line 219: / Line 219: @@
 {{system:32to64.script.bz2}}
 {{32to64.time.bz2}}
+<file>
+Also, what was captured mostly just shows actual changes done.
+For the most part I used a separate session for doing things like
+simulation runs, e.g.:
+# apt-get -s ...
+# dpkg --simulate ...
+downloads:
+# apt-get download ...
+and working out various dependencies (typically from the simulations
+above), and statuses (typically via use of
+$ COLUMNS=200 dpkg -l
+and sometimes also:
+# apt-get -s install
+and picking over the resultant data).
+For the most part, when
+# dpkg --simulate -i ...
+came back looking clean, the corresponding
+# dpkg -i ...
+worked fine, but not always - sometime the latter would expose
+additional dependencies or other (relatively minor) issues.  Most
+commonly, if not always, such issues were resolved just by bringing in
+another package to a few packages or so, and then a:
+# dpkg --configure --pending
+and all was then fine.
+Seems the whole process could (almost?) be automated by some
+higher-level script/program (e.g. perl) to work all that stuff out and
+implement it.  The only part that might be a bit more tricky, is in some
+cases, there wasn't a precise correspondence between i386 and amd64
+packages.  E.g., in almost all cases, it was simply matter of same
+package and version number in i386 architecture being replaced with
+same from amd64 architecture.  But not always - there were some
+exceptions.  But at least where I encountered such, it was easy enough
+to figure out from the dependencies and/or lack thereof, or from the
+names and descriptions, etc.
+</file>
+And one issue that was found a little bit later (2014-06-13) and corrected, from our [[http://www.archive.balug.org/log.txt|system log]] file:
+<file>
+Noticed bug/issue with spell, e.g.:
+$ echo foo | spell
+/usr/bin/ispell: Illegal format hash table
+Tried:
+# (cd / && umask 022 && dpkg-reconfigure spell)
+# (cd / && umask 022 && dpkg-reconfigure dictionaries-common)
+# (cd / && umask 022 && dpkg-reconfigure ispell)
+Those didn't correct it, but this did:
+# (cd / && umask 022 && dpkg-reconfigure iamerican)
+That updated:
+/var/lib/ispell/american.hash
+Guessing this may have been issue left over from i386 to amd64 conversion
+</file>
+See also: [[https://wiki.debian.org/CrossGrading|CrossGrading]] (a Debian system - on the Debian wiki)