You are not logged in.
Pages: 1
I have used the Windows Installer to successfully install Gemini on my Win 10 Pro laptop. Once I get my Gemini installation set up and configured the way I like it, can that installation be cloned to another Win 10 Pro machine? I have two other Windows machines that I use regularly and would like to have Q4OS Gemini set up the same way without going through two more manual setups/configurations.
If I have an image/copy of my working Q4OS Gemini setup I can also easily restore it in the event of an issue. I am no terminal/command line hero in either Windows or Linux but I take direction well (don't ask my wife...) and don't mind working through problems/issues. I have used desktop Linux - mostly Debian/Ubuntu derivatives and Puppy - for years as a hobbyist.
I have done a little searching through the forum but didn't find this specific question.
Thanks in advance for any tips/insight!
Offline
Replying to myself - I can copy the Linux 64 directory from C:\ in Windows 10 to a thumb drive and from there to a target Windows 10 machine. I am guessing that installing/configuring Wubi on the target machine would be the way to make the Gemini installation in that directory bootable. Am I on the right track here?
Thanks!
Offline
,,, Am I on the right track here?
We would recommend to make a fresh installation on a new machine in order to proceed the Linux/Debian configuration properly on the target hardware. We recommend to use "custom profiles" to pass the system wide configuration on a new machine, see https://www.q4os.org/dqa016.html
If you know what you are doing, you can try to boot just configured image, so you need to copy/rewrite the file "c:\linux64\debian11\disks\root.disk" only. Keep in mind, you could end up with a broken system, as the loop image has been configured for another hardware.
Offline
carmicheals wrote:,,, Am I on the right track here?
We would recommend to make a fresh installation on a new machine in order to proceed the Linux/Debian configuration properly on the target hardware. We recommend to use "custom profiles" to pass the system wide configuration on a new machine, see https://www.q4os.org/dqa016.html
If you know what you are doing, you can try to boot just configured image, so you need to copy/rewrite the file "c:\linux64\debian11\disks\root.disk" only. Keep in mind, you could end up with a broken system, as the loop image has been configured for another hardware.
It looks like the "custom profiles" function is the way to go. I will experiment with that, and thanks! That would still save a bunch of time and keystrokes over separate installs/configurations!
Offline
Ran the Windows Installer on another machine. Tried "Custom Profiles" first. The issue there is that my installation has some software installed that wasn't from the Q4OS Software Centre.
I then renamed C:\Linux64\Debian11\disks\root.disk on the target machine to root.disk.old and copied the root.disk file from my original Windows machine over.
It takes a fair amount of time to boot once selected (it gets stuck for several minutes at "Initializing system during boot), but it works. Is there anything I can do within wubiuefi to speed this up? A boot configuration file that needs editing, maybe?
My original root.disk file was created on an i7 Toshiba laptop. I migrated it over to a Lenovo AMD desktop, and ran updates from terminal after it booted to make sure all of the differing hardware was accounted for. it works great once it finally boots.
Last edited by carmicheals (2022-07-05 14:39)
Offline
It takes a fair amount of time to boot once selected (it gets stuck for several minutes at "Initializing system during boot), but it works. Is there anything I can do within wubiuefi to speed this up? A boot configuration file that needs editing, maybe?
I am guessing that this is a UUID issue. Since the boot.disk file was created on another machine it likely contains the UUID from the host machine. The boot configuration post-"Initializing system during boot" on the target machine is looking for a different UUID which creates the delay. That's my theory, anyway.
Offline
Yes it could be.. Check for swap UUID in /etc/fstab and modify it accordingly.
Offline
Pages: 1