How to migrate Linux (Ubuntu 16.04) from 32 bit to 64 bit when root and encrypted home is on same partition?
IBS
Category: Software Design, Language: E, cover: SC, pages: 0, year: 2017.
How to migrate Linux (Ubuntu 16.04) from 32 bit to 64 bit when root and encrypted home is on same partition?
The necessity to migrate to 64 bit are the following:
1) There is a memory cache error in 32 bit Linux with more than 8 GB main memory installed with the effect that disk write becomes very slow* - it can go even lower than 1 MB/s!
2) The VirtualBox host, even with 64 bit guest operating systems, allows only (a bit less than) 4 GB main memory.****
3) Some applications (e.g., 'zcash' crypto mining) require 64 bit and much more than 4 GB main memory.
The migration steps below are a summary - written from my memory. Hope I didn't forget an important step. Smaller steps are not included.
I publish this artcile because I had not found elsewhere any guide which addresses 64 bit migration from 32 bit where root and (encrypted) home reside on a single partition.
To repeat, my U32 has (except for swap) a single partition*** for both root and home. It uses encrypted home(s), i.e. home/user is an encrypted file system 'ecryptfs'.
The following is what worked for me. Use at your own risk. If you plan to follow my steps, you must fully understand each step and its effects. (If you understand these, you won't probably need to read this article ;))
0. To fix stuff when something goes wrong, in order to be able to boot U32 and still login, created a (non ecryptfs) account user2 on U32 and leave this account on its /home to be able to login when booting U32. (i.e. don't touch this account in step 4 below.) If you mess things up and can no longer login in U32, you can still go to console (Ctrl-Alt-F1) and nano editor be your friend.
It also helps if there is an account user1 (with non encrypted home) with same name and pw on U64 and U32, if stuff needs to be fixed.
Attention: Once the initial installation of U64 is completed, be very careful to not confuse the new /home of U64 which will be set to the root partition of U32 by means of (U64) /etc/fstab (see step 5). The reason confusion might arise is that in U64's /home you'll then see U32 a directory 'home' which will no longer be used in U64. But its still used for login of any remaining users, e.g. user2 when booting U32.
1. Shrinked the U32 partition with gparted by 32 GB. This takes some time...
2. Downloaded Minimal Ubuntu install CD (64 bit), copied the ISO image to a CD, booted the CD and installed Ubuntu on this newly created 32GB partition.
(At this step, it is not possible to specify U32 as new /home partition on U32, except if steps 4.1-4.3 would be performed before. In this case, I guess, the installation and user account creation would ask if home should be erased or NOT[!]).
3. Created user account on U64 with same name and pw and home encryption option as they existed on U32.
In the boot menu, one can now choose between U64 and U32 (and Windows).
4. Booted from U64, mounted U32 partition
4.1. moved U32 /home/.ecryptfs to U32 / (i.e. to root of U32)
4.2. moved U32 /home/user to U32 /user
4.3. moved U32 /home/user1 to U32 /user1
5. In U64 /etc/fstab added U32 partition as /home
6. In U64 /etc/passwd changed user to
user:x:1000:1000:user,,,,:/home/user:/bin/bash
user1:x:1001:1000:user1,,,,:/home/user1:/bin/bash
7. Rebooted U64 and logged in as user. My encrypted home and (almost) all my U32 settings were present in U64. dmesg shows some errors since some application's settings (configs) are not really 32 to 64 bit upward compatible.
The U32 package list** could not be used to install U32's extra apps (e.g. nemo) on U64. Amongst other errors it would add all the 32 bit stuff. The extra apps list must be created manually.
Good luck!
*) my work around for this 32 bit linux memory cache error is running a shell script with an endless loop to drop caches every 30 seconds:
#!/bin/bash # see http://www.linuxinsight.com/comment/2214#comment-2214 for (( c=1; c<=10000; c++ )) do echo $c sudo sh -c "sync; echo 3 > /proc/sys/vm/drop_caches" dd if=/dev/zero of=ddfile bs=8k count=10000 && sync sleep 30 done
If nevertheless the disk write gets insanely slow (which happens from time to time) it often helps close the browsers (I often have 3 browsers running; because FF is not compatible with all websites, thus chrome is the 2nd, and 3rd is Opera [under Linux only] has build-in VPN) and/or other big running apps. Or log out and login again. This usually brings the write speed back to around 100 MB/s. There are many (recently (2017) updated) bug threads about this error - with many new workaround prosposals. I studied all, but it turns out they are not effective and that there is no ultimative solution (yet). So the 64 bit migration is not avoidable.
**) #dpkg --get-selections > ~/Package.list #sudo cp /etc/apt/sources.list ~/sources.list #sudo apt-key exportall > ~/Repo.keys
***) Im my case (for historic reasons) there is actually another (first) partition on the hard disk for dual booting Windows which we can ignore here.
It is advisable not dual boot Windows and Linux because
Strange things can happen
("Error parsing PCC subspaces from PCCT: ACPI PCC probe failed."
One solution might be to disable hiberboot (fast startup) in Windows.)
See also Problems booting into 16.04 after dual boot.
Better use VirtualBox to boot Windows under Linux.
****) e.g. 64 bit Windows can be installed in a VB under 32 bit Linux, if the CPU supports the virtualisation instructions. (These must eventually be enabled in BIOS first).