User Tools

Site Tools


system:32-bit_to_64-bit

Differences

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

Link to this comparison view

Next revision
Previous revision
system:32-bit_to_64-bit [2014-04-27T16:55:50+0000]
michael_paoli created
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 (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). 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=amd64] file:/​media/​cdrom9 wheezy main
 deb [arch=i386] file:/​media/​cdrom8 wheezy main deb [arch=i386] file:/​media/​cdrom8 wheezy main
Line 71: Line 71:
 # apt-get update # 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 http://​www.debian.org/​releases/​wheezy/​i386/​release-notes/​ch-upgrading.en.html#​system-status
 and especially: and especially:
Line 122: Line 122:
 dependencies have already been met, or not or if any conflicts or other 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 problems show up.  If/when you encounter any predepends, those need to
-be installed first, not 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 You'll want to be able to use dpkg fairly well, it's lower-level than
Line 196: Line 196:
 http://​linuxmafia.com/​pipermail/​sf-lug/​2014q2/​010408.html http://​linuxmafia.com/​pipermail/​sf-lug/​2014q2/​010408.html
 </​file>​ </​file>​
 +
 +<​file>​
 +And a much cleaner run at it.
 +The files linked below are bzip2(1) -9 compressed from
 +script(1) with -t option.
 +One may want to shorten up some of the longer
 +(idle/​waiting/​inactive) times in the time file, e.g.:
 +(where here, our leading $ is PS1, and leading > is PS2)
 +$ bzip2 -d < 32to64.time.bz2 |
 +> > 32to64.shorter_wait_times \
 +> sed -e '​s/​^[0-9]\{2,​\}\.[0-9]\{1,​\} /3.000000 /'
 +And uncompress the script file:
 +$ bzip2 -d 32to64.script.bz2
 +And one can then review it with scriptreplay(1),​
 +e.g. to see that at triple speed:
 +$ scriptreplay 32to64.shorter_wait_times 32to64.script 3
 +That was captured connecting via serial console (virtually),​
 +as for terminal type, one would probably want to do that in an 80x24
 +vt100, or xterm, screen, or ANSI terminal or emulation, for best
 +reproduction/​viewing results.
 +</​file>​
 +{{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)
system/32-bit_to_64-bit.1398617750.txt.bz2 ยท Last modified: 2014-04-27T16:55:50+0000 by michael_paoli