Moving Linux Installation OFF Virtual Machine and Into Real World ???

[25B.Z969]

I often test OS distros by installing them on VMs - KVM or
Virtualbox.

Thing is, while playing with them I often make a LOT of useful
tweaks, load a lot of software, get it working REALLY WELL.
Half the time I can't remember all the tweaks, the other half
of the time so MUCH time was spent getting it right I just
don't want to do it all over again.

So ... has anybody found a good way to migrate a VM to something
that can be installed on a conventional disk ?

I *suspect* it's possible to use 'dd' ... make a full image, make
space on a HD, copy the image, use one of those GRUB-REPAIR disks
so it's findable/bootable.

Or maybe not ...

[Bit Twister]

On Fri, 12 Aug 2022 00:59:15 -0400, 25B.Z969 wrote:
> I often test OS distros by installing them on VMs - KVM or
> Virtualbox.
>
> Thing is, while playing with them I often make a LOT of useful
> tweaks, load a lot of software, get it working REALLY WELL.
> Half the time I can't remember all the tweaks,

So write what you do/did in an admin diary.

> the other half
> of the time so MUCH time was spent getting it right I just
> don't want to do it all over again.

That is what automation is for.
You either let the computer work you or make the computer work for you.

So what will you do when your "Production" install no longer works
after an upgrade or whatever?

I used to document every change until it dawned on me to write
scripts to do the changes for me.

I can now do clean installs run my scripts and have everything as I
want it.

[Bobbie Sellers]

It is possible choosing the proper tools to creat an iso image of your
installation which can be installed to your new computer. On
PCLinuxOS we have a tool designed for that purpose, MyLiveUSB. Many of
the PCLinuxOS forum members have used it. I will be using it shortly
I imagine as the updates come so often

bliss - brought to you by the power and ease of PCLinuxOS
the Perfect Computer Linus Operating System(for me),
and a minor case of hypergraphia.

--
bliss dash SF 4 ever at dslextreme dot com

[Harri]

25B.Z969 <25B....@noda.net> wrote:
> So ... has anybody found a good way to migrate a VM to something
> that can be installed on a conventional disk ?

Copy files to new disk and install boot loader. Basically it's about
making a backup and then restoring the backup. I make my system backups
with Tar.
--

Harri

[Robert Heller]

Yes. Linux is *not* fussy about what "disk" it is installed on. Pretty much
any sort of disk-to-disk backup process, followed by a "rescue" process (to
possibly update /etc/fstab, install the boot loader, maybe rebuild the
initramfs, possibly fiddle with some hardware-specific issues, like the NIC,
etc.). Basically not really any different if you had to restore a full backup
from a machine that was totally trashed to new hardware.

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[25B.Z969]

On 8/12/22 1:15 AM, Bit Twister wrote:
> On Fri, 12 Aug 2022 00:59:15 -0400, 25B.Z969 wrote:
>> I often test OS distros by installing them on VMs - KVM or
>> Virtualbox.
>>
>> Thing is, while playing with them I often make a LOT of useful
>> tweaks, load a lot of software, get it working REALLY WELL.
>> Half the time I can't remember all the tweaks,
>
> So write what you do/did in an admin diary.

A what ??? :-)

>> the other half
>> of the time so MUCH time was spent getting it right I just
>> don't want to do it all over again.
>
> That is what automation is for.
> You either let the computer work you or make the computer work for you.
>
> So what will you do when your "Production" install no longer works
> after an upgrade or whatever?

I don't get THAT crazy - but I do keep backups of the
working scripts, config.files and such. However moving
all of that to a new installation is a pain, and I'm
just a bit lazy ... ok, OLD ...

> I used to document every change until it dawned on me to write
> scripts to do the changes for me.

Not a bad idea ... but then you've STILL "documented",
inside the scripts.

> I can now do clean installs run my scripts and have everything as I
> want it.

Ought to work fairly well, but for EVERY tweak ?
I tend to hammer at these issues until I get a
setup that does what I want ... but I often do
the tweaking so fast, with so many trial variants,
that remembering everything - even to write it in
a script - can be difficult.

There are two kinds of programmers. If the bosses
need it *eventually* there were some other guys,
who'll spend months carefully diagramming it all
out. If they needed it working by Monday morning
then I was the guy. Once I get going I can kinda
build and hold the whole equation in my head,
it all evolves almost in a fractal fashion. I'm
now a little old for that, not the same old energy
and hyper-focus. But I had my day and purpose.

The boss comes in on Thursday, wants a digital-
signage app for next Tuesday - pref with a usable
web interface for setting up the slide decks,
something that could be taken off to a conference
on Wednesday, preferably for free. Sorry, the
LibreOffice stuff hung-up after an hour and didn't
have the necessary flexibility. PowerPoint needs
something like an actual, bulky, Win-PC. So ... I wrote
one - a lot of redundant PHP code because I hadn't
written PHP in awhile. Lazarus for the actual
display app. Timed slides, sub-slides within the
main slides, fades or cuts, onboard storage - but
everything initially stored, resized, on the NAS,
multi-media via evoking MPG player. Runs on an rPi
velcro-ed to the back of a big-screen. Mostly for now
it sits in the lobby to entertain people waiting for
appointments, but occasionally gets taken to meetings
and such. She had it by Tuesday. OK, I actually
wrote it twice - first in Py3+TK and then Lazarus.
Polished-out a third of the code a week later.

That's kinda what I'm good for - weird apps needed
in a fairly short timeframe. Might require soldering
chips together for sensor boards. If you want a hyper-
deep high-priced medical-practice organizer/biller
with the pretty GTK/Qt interfaces and Java, that's
what the Other Guys are better for ... but you're
gonna wait a year or two.

But the big customer who says "Can I port my MediSoft
database to your system ?" ... guess who gets to
write that kind of module by Tuesday ?

And I got paid as much as the "software engineers"
too ... good retirement pkg, occasional consulting ...

Charlie will confirm - find the small/medium-sized
places and it'll always be INTERESTING - you'll never
"work" another day in your life.

ANYway ... I want the best path for moving common VMs
off into the non-virtual universe. VMs have their place,
but they have more weird issues too. The WORST aspect
of VMs is that cheap places love to put ALL those eggs
in ONE hardware basket - and then you get a hole in
that basket one day ..........

[25B.Z969]

On 8/12/22 2:35 AM, Bobbie Sellers wrote:
> On 8/11/22 21:59, 25B.Z969 wrote:
>> I often test OS distros by installing them on VMs - KVM or
>> Virtualbox.
>>
>> Thing is, while playing with them I often make a LOT of useful
>> tweaks, load a lot of software, get it working REALLY WELL.
>> Half the time I can't remember all the tweaks, the other half
>> of the time so MUCH time was spent getting it right I just
>> don't want to do it all over again.
>>
>> So ... has anybody found a good way to migrate a VM to something
>> that can be installed on a conventional disk ?
>>
>> I *suspect* it's possible to use 'dd' ... make a full image, make
>> space on a HD, copy the image, use one of those GRUB-REPAIR disks
>> so it's findable/bootable.
>>
>> Or maybe not ..
>
>     It is possible choosing the proper tools to creat an iso image of
> your installation which can be installed to your new computer. On
> PCLinuxOS we have a tool designed for that purpose, MyLiveUSB. Many of
> the PCLinuxOS forum members have used it.  I will be using it shortly
> I imagine as the updates come so often

MX has a very similar utility - customize, then make an ISO.
Alas it's custom to MX - but then MX is a very good base for
pretty much anything. Still, I prefer vanilla Deb - can't go
wrong there. MX is kinda using 'dd', the app just knows
exactly what folders to assemble into the ISO.

[25B.Z969]

I make some of my backups with Tar ... it is still perfect for
some purposes.

But basically I want to make an installable ISO from a VM.
MX and, according to one, PCLinuxOS, have a utility just
for that. I like vanilla Deb though.

[25B.Z969]

On 8/12/22 9:01 AM, Robert Heller wrote:
> At Fri, 12 Aug 2022 09:43:16 +0300 ha...@kallio.tunk.org (Harri) wrote:
>
>>
>> 25B.Z969 <25B....@noda.net> wrote:
>>> So ... has anybody found a good way to migrate a VM to something
>>> that can be installed on a conventional disk ?
>>
>> Copy files to new disk and install boot loader. Basically it's about
>> making a backup and then restoring the backup. I make my system backups
>> with Tar.
>
> Yes. Linux is *not* fussy about what "disk" it is installed on. Pretty much
> any sort of disk-to-disk backup process, followed by a "rescue" process (to
> possibly update /etc/fstab, install the boot loader, maybe rebuild the
> initramfs, possibly fiddle with some hardware-specific issues, like the NIC,
> etc.). Basically not really any different if you had to restore a full backup
> from a machine that was totally trashed to new hardware.

This is what I wanted to hear - I'm on the right track.
Winders will screw you 101 ways - but Linux/Unix are
pretty flexible in this respect. Linux systems don't
really KNOW they're running in a VM, it all seems
normal to them. The possible hang-up is in how the
storage is set up.

I'm gonna give it a few kinds of tries next week and
will post my experiences.

VMs are great - but sometimes you want all your work
to move into the Real World.

[Bit Twister]

On Sat, 13 Aug 2022 00:48:23 -0400, 25B.Z969 wrote:
> On 8/12/22 1:15 AM, Bit Twister wrote:
>> On Fri, 12 Aug 2022 00:59:15 -0400, 25B.Z969 wrote:
>>> I often test OS distros by installing them on VMs - KVM or
>>> Virtualbox.
>>>
>>> Thing is, while playing with them I often make a LOT of useful
>>> tweaks, load a lot of software, get it working REALLY WELL.
>>> Half the time I can't remember all the tweaks,
>>
>> So write what you do/did in an admin diary.
>
>
> A what ??? :-)

Usually an ASCII text file with date/time and description of what
was changed from/to in a file.

>
>>> the other half
>>> of the time so MUCH time was spent getting it right I just
>>> don't want to do it all over again.
>>
>> That is what automation is for.
>> You either let the computer work you or make the computer work for you.
>>
>> So what will you do when your "Production" install no longer works
>> after an upgrade or whatever?
>
>
> I don't get THAT crazy - but I do keep backups of the
> working scripts, config.files and such. However moving
> all of that to a new installation is a pain, and I'm
> just a bit lazy ... ok, OLD ...

Yep I know just what you are saying, but old release configuration files
may not be compatible with new release.

>> I used to document every change until it dawned on me to write
>> scripts to do the changes for me.
>
> Not a bad idea ... but then you've STILL "documented",
> inside the scripts.

Other than the code very little why/what commenting.

>
>> I can now do clean installs run my scripts and have everything as I
>> want it.
>
> Ought to work fairly well, but for EVERY tweak ?

Yep,
cd /local/bin
ls *install* | wc -l
61
ls *change* | wc -l
198

even my Desktop Environment changes. I use Xfce as my DE and use
xdotool dump/set my changes. Dead easy to use a junk account,
dump pristine user settings, Go through each gui user DE configuration screen
dump settings again and diff got me all the changes to automate.

> I tend to hammer at these issues until I get a
> setup that does what I want ... but I often do
> the tweaking so fast, with so many trial variants,
> that remembering everything - even to write it in
> a script - can be difficult.

Seems simple enough to me. Save file before change, use diff to
get what was changed, modify script to taste.

It does help to already have skeleton/boilerplate scripts to have 90%
of the grunt work done.

ls *skeleton*
bash_skeleton skeleton_sb_drop_in_changes
install_skeleton skeleton_service_changes

I have the Aide package installed on my Mageia 8 Release OS.
Makes is easy to find new/changed files/links.
http://sourceforge.net/projects/aide

> There are two kinds of programmers. If the bosses
> need it *eventually* there were some other guys,
> who'll spend months carefully diagramming it all
> out.

Yeah I find the six P's can help, You know Prior Planning Prevents
Piss Poor Performance..

> If they needed it working by Monday morning then I was the guy.

Hehehe, being a Maintenance Programmer I have had to fix a lot of that
methodology.

> Once I get going I can kinda
> build and hold the whole equation in my head,
> it all evolves almost in a fractal fashion.

Yep, been there and beats having to create Requirements and Design specs.
Sounds like it would be easy for you to create all the functions to
do scut work then dead easy to find the lines to set you changes.

> I'm
> now a little old for that, not the same old energy
> and hyper-focus. But I had my day and purpose.

Yeah, and if you are like me, not remembering everything needing to be
done where. I think you mentioned adding stuff. On mine I have
grep rpm install_addons | wc -l
151
extra stuff.

> Charlie will confirm - find the small/medium-sized
> places and it'll always be INTERESTING - you'll never
> "work" another day in your life.

Yup, mine started out as an engineers aid to wire/debug interface boards
to test cards. Pretty soon designing, wire it, write the program to test
new card and debug my interface card, my testing program and once in
a while the card under test.

> ANYway ... I want the best path for moving common VMs
> off into the non-virtual universe. VMs have their place,
> but they have more weird issues too. The WORST aspect
> of VMs is that cheap places love to put ALL those eggs
> in ONE hardware basket - and then you get a hole in
> that basket one day ..........

Yep, I use Virtualbox to test all my scripts for each new OS release.

Found it handy to have a change counter and test it for match.
If not, I have to delve into new configuration file to see what has changed.

Regardless how you get the vm machine onto real hardware, you still
have to make hardware difference changes.

Still recommending install/change scripts to do the work.

[stepore]

On 8/11/22 21:59, 25B.Z969 wrote:

> So ... has anybody found a good way to migrate a VM to something
> that can be installed on a conventional disk ?
>

Google V2P. Lots of ways to do this.

If you're using kvm and qcow2 format then standard convert should do it:
qemu-img convert your-vm.qcow2 -O raw your-disk.img

then ya, dd to write it to your device drive.

[25B.Z969]

On 8/13/22 2:14 AM, Bit Twister wrote:
> On Sat, 13 Aug 2022 00:48:23 -0400, 25B.Z969 wrote:
>> On 8/12/22 1:15 AM, Bit Twister wrote:
>>> On Fri, 12 Aug 2022 00:59:15 -0400, 25B.Z969 wrote:
>>>> I often test OS distros by installing them on VMs - KVM or
>>>> Virtualbox.
>>>>
>>>> Thing is, while playing with them I often make a LOT of useful
>>>> tweaks, load a lot of software, get it working REALLY WELL.
>>>> Half the time I can't remember all the tweaks,
>>>
>>> So write what you do/did in an admin diary.
>>
>>
>> A what ??? :-)
>
> Usually an ASCII text file with date/time and description of what
> was changed from/to in a file.

Not my style :-)

I hyper-doc PROGRAMS though.

>>>> the other half
>>>> of the time so MUCH time was spent getting it right I just
>>>> don't want to do it all over again.
>>>
>>> That is what automation is for.
>>> You either let the computer work you or make the computer work for you.
>>>
>>> So what will you do when your "Production" install no longer works
>>> after an upgrade or whatever?
>>
>>
>> I don't get THAT crazy - but I do keep backups of the
>> working scripts, config.files and such. However moving
>> all of that to a new installation is a pain, and I'm
>> just a bit lazy ... ok, OLD ...
>
> Yep I know just what you are saying, but old release configuration files
> may not be compatible with new release.

The updaters usually take care of that pretty well. At the
very least apt/apt-get will ASK you if you want to replace
a customized config file.

Anyway, my immediate focus is on moving the VM into the
real world. Various ways have been suggested - on checking
some 'fixes' seem to spend a LOT of time explaining why
they won't work very well. Discouraging. I just want to
kinda make a 'dd' image, then move it to an actual drive
partition. The tricky bit is that you have to make the
image of a running system from the running system. It
should mostly work, mostly ...

The most important two are on KVM, one on VBox.

>>> I used to document every change until it dawned on me to write
>>> scripts to do the changes for me.
>>
>> Not a bad idea ... but then you've STILL "documented",
>> inside the scripts.
>
> Other than the code very little why/what commenting.

Well, you CAN comment the hell out of it ....

>>
>>> I can now do clean installs run my scripts and have everything as I
>>> want it.
>>
>> Ought to work fairly well, but for EVERY tweak ?
>
> Yep,
> cd /local/bin
> ls *install* | wc -l
> 61
> ls *change* | wc -l
> 198
>
> even my Desktop Environment changes. I use Xfce as my DE and use
> xdotool dump/set my changes. Dead easy to use a junk account,
> dump pristine user settings, Go through each gui user DE configuration screen
> dump settings again and diff got me all the changes to automate.

I'm gonna try some of these approaches next week. I'll
report which seem to work the best.

>> I tend to hammer at these issues until I get a
>> setup that does what I want ... but I often do
>> the tweaking so fast, with so many trial variants,
>> that remembering everything - even to write it in
>> a script - can be difficult.
>
> Seems simple enough to me. Save file before change, use diff to
> get what was changed, modify script to taste.

Um ... maybe ten tweaks, sometimes to one config file, in
and hour - trial and error until the damned thing WORKS.
I generally keep an ".old" or two, but .....

In this respect I'm closer to a 'hack' ... but made 30+
years of fair money doing it this way. FAST is the
imperative for my niche.

> It does help to already have skeleton/boilerplate scripts to have 90%
> of the grunt work done.
>
> ls *skeleton*
> bash_skeleton skeleton_sb_drop_in_changes
> install_skeleton skeleton_service_changes

Always good. Don't always get DONE though :-)

> I have the Aide package installed on my Mageia 8 Release OS.
> Makes is easy to find new/changed files/links.
> http://sourceforge.net/projects/aide
>
>> There are two kinds of programmers. If the bosses
>> need it *eventually* there were some other guys,
>> who'll spend months carefully diagramming it all
>> out.
>
> Yeah I find the six P's can help, You know Prior Planning Prevents
> Piss Poor Performance..

PPPTR ... Prior Planning Prevents TIMELY RELEASE :-)

>> If they needed it working by Monday morning then I was the guy.
>
> Hehehe, being a Maintenance Programmer I have had to fix a lot of that
> methodology.

Sure ... but the boss HAS IT WORKING when it's WANTED/NEEDED.

Polish-up LATER. That can be fun too.

>> Once I get going I can kinda
>> build and hold the whole equation in my head,
>> it all evolves almost in a fractal fashion.
>
> Yep, been there and beats having to create Requirements and Design specs.
> Sounds like it would be easy for you to create all the functions to
> do scut work then dead easy to find the lines to set you changes.

I just blast it into existence, might completely re-do the
paradigm a few times in a day as current/future needs pop
into my head. There's money in the BY MONDAY MORNING
programming niche. The well-planned super-big apps, well,
those are for the Other Guys - but ya ain't gonna have it
by Monday morning ......

And sometimes those big ultra-planned/perfectly-structured
apps wind up being SO rigid that you can't squeeze a tweak
the boss/customer wants in there without collapsing the
whole house of cards.

The "best way" is probably in-between somewhere.

>> I'm
>> now a little old for that, not the same old energy
>> and hyper-focus. But I had my day and purpose.
>
> Yeah, and if you are like me, not remembering everything needing to be
> done where. I think you mentioned adding stuff. On mine I have
> grep rpm install_addons | wc -l
> 151
> extra stuff.
>
>> Charlie will confirm - find the small/medium-sized
>> places and it'll always be INTERESTING - you'll never
>> "work" another day in your life.
>
> Yup, mine started out as an engineers aid to wire/debug interface boards
> to test cards. Pretty soon designing, wire it, write the program to test
> new card and debug my interface card, my testing program and once in
> a while the card under test.

Ah ... somebody else who "programs in Solder" once in a
while :-)

I was annoying everybody by insisting that there are really no
boundaries between software/firmware/hardware ... all are one
and one is all ....

For awhile I was making 'embedded' stuff for people who needed
to do environmental monitoring - and often changed their minds
about WHAT they needed to monitor. Often there really weren't
any off-the-shelf solutions to their particular wants plus the
environments the things would be used in (like salt water or
boiling/freezing conditions) So - you build the Whole Thing ...
code+microcontrollers+sensor-adapter-boards (some with smaller
microcontrollers of their own). I2C,SPI,1-Wire,RS232/485 - have
to leverage them all. Then the systems to be used in vehicles -
pumps, monitors, GPS, electrically-noisy environs ... good
education in why opto's can be your friend ....

And they always want it REAL QUICK :-)

>> ANYway ... I want the best path for moving common VMs
>> off into the non-virtual universe. VMs have their place,
>> but they have more weird issues too. The WORST aspect
>> of VMs is that cheap places love to put ALL those eggs
>> in ONE hardware basket - and then you get a hole in
>> that basket one day ..........
>
> Yep, I use Virtualbox to test all my scripts for each new OS release.

I've found that VBox isn't good for *everything*. Often you
can install something in VBox ... but sometimes it goes
better in KVM. The various add-on paks that help VBox
interface with the real world can also be an impediment,
while the more system-level stuff KVM wants for interfacing
with local networks is actually more portable. Xen, at
this point, seems to be falling behind the curve alas
and VMWare is more and more $$$.

VMs ARE super-good for checking suspicious e-mails/attachments
though ... irrelevant if they're corrupted/infested. For that
kind of stuff I have Kali VMs with all the forensic apps. The
evil people are getting VERY clever these days ... impossible
to train all the 'average users' to look for all possible
scam methods. At best I can dissect scam mails, write a little
one-page expo on WHY/HOW they were scamming. It does help,
makes the staff more suspicious, less ready to trust, less
likely to just click the "Click Me !" button ....

The latest trend is Fake Invoices. Sometimes they look/feel
VERY real - might even seem kind-of related to what the cpny
is doing at the moment (the Evils do keep track, even check
construction permits being made and make deductions). One
outfit got a bill, supposedly from a local company, for some
concrete work - but the bill SHOULD have gone to the primary
contractor ... and the company was real, but only did a
completely different kind of concrete work. Another
construction company, again a REAL name, only did work
overseas. Mis-spelling tricks, hidden links, fake QuickBooks
billings, seeming US addresses that, once checking, went to
eastern europe ...... at best you can make the staff PARANOID
about anybody wanting money/passwords/acct#'s etc. They do
not have the skills/time to really check-out this stuff.

> Found it handy to have a change counter and test it for match.
> If not, I have to delve into new configuration file to see what has changed.

I've done that ... though probably not as often as I should have.
My niche was "fast and loose". It has it's place. Always wrote
code so you could jam some weird change/improvement in there
somewhere without re-writing half the pgm. Kinda left over from
the old "batch job" days - everything step-by-step - so you
can easily insert an odd very-different step in there. It's
neater/smaller if you combine operations, but you lose that
patching flexibility.

> Regardless how you get the vm machine onto real hardware, you still
> have to make hardware difference changes.

Well ... Linux does most of it's hardware detection at boot.
A little different from Win in that respect. This does make
it easier to port between different hardware environs.

> Still recommending install/change scripts to do the work.

I agree ... but at this point I'm semi-retired. The New Boyz
will have to do all this. <Perferred-Gawd> Help Them :-)

Sometimes the New Girlz are actually better ...

They think taking a Python course will make them "systems
guys" or good IT overlords. Sorry, but experiencing all
the PAST crap - working with diverse systems/languages -
no real substitute. My first "real programs" were FORTRAN
writ for a PDP-11/RSX-11m somebody (I'm sure with sadistic
intent) wired CARD/PTape-readers to even though the thing
WOULD support terminals. There's just no substitute for
"coming up thru the ranks". Maybe all the "old guys" say
that - but it IS really hard to chart a sane course forward
when you don't know where you've been.

From the early 60s, yer VAX/360/etc and its language suites
were set up to get data (slowly) from remote/international
sources - biz/banking/science. The New Guys think this
only happened with the internet, don't know the Foundations,
don't know why TCP/IP exists, don't know about xmodem and
error detection/correction. For them It Just Works ...
until some Russkie actor makes sure it doesn't, or finds
a way to leverage it against you ......

In a way I lament not getting into it a decade or so
earlier - the immediate post-UNIVAC world. Those people
really knew how to get by with less - and how to CREATE
what they didn't have.

[Bit Twister]

On Sun, 14 Aug 2022 03:08:58 -0400, 25B.Z969 wrote:
> On 8/13/22 2:14 AM, Bit Twister wrote:

>
>
>> Regardless how you get the vm machine onto real hardware, you still
>> have to make hardware difference changes.
>
> Well ... Linux does most of it's hardware detection at boot.
> A little different from Win in that respect. This does make
> it easier to port between different hardware environs.

I am talking about things like configuring Network Interface Card(s)'s
routing, ip address and whatnot, /etc/fstab, dhcpd server...

[Robert Heller]

+1

The Linux install is likely to "hard code" things like UUIDs for disks and MAC
addresses for NIC in various files in /etc. If your target system is on a
*freshly* create FS, the UUID will be different and of course the NIC will be
different. These are things that are easy to fix with a live rescue system.
And of course, one has to install the boot loader (grub-install). These are
"standard" things one would need to do. It is also possible that the name of
the NIC device might be different, due to different hardware.

[Kirk_Rockstein]

On 2022-08-14, 25B.Z969 <25B....@noda.net> wrote:
<snip>

> Anyway, my immediate focus is on moving the VM into the
> real world. Various ways have been suggested - on checking
> some 'fixes' seem to spend a LOT of time explaining why
> they won't work very well. Discouraging. I just want to
> kinda make a 'dd' image, then move it to an actual drive
> partition. The tricky bit is that you have to make the
> image of a running system from the running system. It
> should mostly work, mostly ...
>

<snip>

If this is just your user systems you are speaking of why not do something
like this from your live environment. Modify the options as needed.
Example:
rsync -av --delete / /mnt/your-formated-partition-on-HDD --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/home/youruser/.gvfs","/var/lib/ntp/proc/*"}

[Bobbie Sellers]

The packager of PCLinuxOS 64 creates each distribution in a virtual
machine then when satisfied he converts it to an iso file and
sends it to Repositories. I believe he has scripts to help him with
these matters and if you go to PCLinuxOS Forum and register then you
could do a search on the matter or even ask Texstar about his
procedure. He got a high powered Ryzen computer to use for this
purpose.

[Carlos E.R.]

On 2022-08-12 15:01, Robert Heller wrote:
> At Fri, 12 Aug 2022 09:43:16 +0300 ha...@kallio.tunk.org (Harri) wrote:
>> 25B.Z969 <25B....@noda.net> wrote:
>>> So ... has anybody found a good way to migrate a VM to something
>>> that can be installed on a conventional disk ?
>>
>> Copy files to new disk and install boot loader. Basically it's about
>> making a backup and then restoring the backup. I make my system backups
>> with Tar.
>
> Yes. Linux is *not* fussy about what "disk" it is installed on.

Unless it is btrfs.

> Pretty much
> any sort of disk-to-disk backup process, followed by a "rescue" process (to
> possibly update /etc/fstab, install the boot loader, maybe rebuild the
> initramfs, possibly fiddle with some hardware-specific issues, like the NIC,
> etc.). Basically not really any different if you had to restore a full backup
> from a machine that was totally trashed to new hardware.
>


--

Cheers, Carlos.

[25B.Z969]

On 8/14/22 3:11 PM, Carlos E.R. wrote:
> On 2022-08-12 15:01, Robert Heller wrote:
>> At Fri, 12 Aug 2022 09:43:16 +0300 ha...@kallio.tunk.org (Harri) wrote:
>>> 25B.Z969 <25B....@noda.net> wrote:
>>>> So ... has anybody found a good way to migrate a VM to something
>>>> that can be installed on a conventional disk ?
>>>
>>> Copy files to new disk and install boot loader. Basically it's about
>>> making a backup and then restoring the backup. I make my system backups
>>> with Tar.
>>
>> Yes. Linux is *not* fussy about what "disk" it is installed on.
>
> Unless it is btrfs.

Heh heh ... yea ... the "new and improved" :-)

I have an NAS that's pretty much tuned to btrfs.
You can do some neat-o tricks with it, but. Screw
"snapshots", just rsync .....

"Boilerplate", "ArmorPlate", is what you want, ANY
time you can get it. EXT3/EXT4. Hoping for an EXT5.

>> Pretty much
>> any sort of disk-to-disk backup process, followed by a "rescue"
>> process (to
>> possibly update /etc/fstab, install the boot loader, maybe rebuild the
>> initramfs, possibly fiddle with some hardware-specific issues, like
>> the NIC,
>> etc.).  Basically not really any different if you had to restore a
>> full backup
>> from a machine that was totally trashed to new hardware.

Hmm ... consider 'gparted'. It is easy to make a copy of a
partition to the same, or adjacent, disk. It's an image.
Then you run update-grub and it'll find the image and
make it a bootable entry.

Seems like this is a possible way forward.

Linux usually does a fair job of detecting hardware
changes when it boots. This will help.

Alas the FIRST VM I want to xfer is FreeBSD :-)

A well-tweaked Deb is next on the list.

[25B.Z969]

I understand. Fortunately that's "easy" stuff - a few
entries in a few files (and for servers I always use
static IPs). Not torture.

The more GENERAL question here ... people make lots of
VMs, do a lot of work with them, and may then wish them
to be non-virtual for whatever reasons. Clear and functional
methods for switching between worlds would seem to be
in the "general interest". VM-Ware might want to prevent
this, but VBox/KVM have no motive.

[25B.Z969]

On 8/14/22 8:55 AM, Robert Heller wrote:
> At Sun, 14 Aug 2022 03:04:39 -0500 Bit Twister <BitTw...@mouse-potato.com> wrote:
>
>>
>> On Sun, 14 Aug 2022 03:08:58 -0400, 25B.Z969 wrote:
>>> On 8/13/22 2:14 AM, Bit Twister wrote:
>>
>>>
>>>
>>>> Regardless how you get the vm machine onto real hardware, you still
>>>> have to make hardware difference changes.
>>>
>>> Well ... Linux does most of it's hardware detection at boot.
>>> A little different from Win in that respect. This does make
>>> it easier to port between different hardware environs.
>>
>> I am talking about things like configuring Network Interface Card(s)'s
>> routing, ip address and whatnot, /etc/fstab, dhcpd server...
>>
>
> +1
>
> The Linux install is likely to "hard code" things like UUIDs for disks and MAC
> addresses for NIC in various files in /etc. If your target system is on a
> *freshly* create FS, the UUID will be different and of course the NIC will be
> different.

Of course ... but that's one of the first adjustments I'd
make anyway - and it's not too hard, just takes a minute.
I've no expectations of an instant plug-n-play xfer from
a VM ... I just don't want it to be TORTURE.

I still like to use LABELED disks/partitions - and Linux
can find and properly adjust to those easier than those
damned UUIDs. LABELs are usually the easiest way to get
external USB drives to always mount to where you expect
also, no matter where you plug 'em in. They'll always
mount to /media/username/diskname (NOW, but not always
historically as best I recall).

> These are things that are easy to fix with a live rescue system.
> And of course, one has to install the boot loader (grub-install). These are
> "standard" things one would need to do. It is also possible that the name of
> the NIC device might be different, due to different hardware.

Ideally you xfer to a new partition on a machine that already has
at least one, even if very basic, distro on it. THEN you can use
that original distro as the tool to make some of those fine
adjustments to what you just brought over from VM. Then update-grub
and reset the boot order.

[25B.Z969]

I know you like PCLinuxOS ... but none of the VMs I want to bring
to the Real World are PCLinuxOS. Indeed one is FreeBSD .....

MX has a similar "existing-distro to ISO" utility.