Re: System Cloning [SOLVED]

2020-03-23 Thread Samuel Sieb

On 3/20/20 11:23 AM, Robert McBroom via users wrote:
The problems was selinux.  Used the chroot process to edit 
/etc/selinus/config and disable selinux. Cloning is successful.


Recap

Knoppix DVD used to copy working Fedora 31 /boot and / to a usbdisk with 
rsync. If separate, /home and /var also


You didn't mention before how you did the "clone".  Especially if you're 
booting from a non-selinux aware system, rsync won't copy the labels. 
You just need to "touch /.autorelabel" on the new root filesystem and on 
reboot all the selinux labels will get fixed.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-23 Thread Samuel Sieb

On 3/18/20 9:45 PM, sixpack13 wrote:

On 19.03.20 03:58, Robert McBroom via users wrote:

On 3/18/20 12:04 PM, Patrick O'Callaghan wrote:

...
The kernels from a cloned system are  far different from what is 
executing by doing a chroot from a live system, so `uname -r` is not 
useful.


that could be, but AFAIK, if I chroot to a cloned or what so ever system 
dracut should *only* see the environment of the system I chrooted to.


wasn't that the benefit of ch(ange)root ?


No, it only changes the filesystem.  You're still running the kernel of 
whatever OS you booted from.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning [SOLVED]

2020-03-20 Thread Robert McBroom via users

On 3/18/20 11:50 PM, Robert McBroom via users wrote:

On 3/18/20 1:00 PM, Tom Horsley wrote:

On Wed, 18 Mar 2020 11:09:23 -0400
Robert McBroom via users wrote:


/etc/grub2.cfg

That's usually a link to the "real" file, and some
editors don't do well with links. Might want to check
the actual file down under /boot somewhere (location
varies for old dos versus uefi installs).


I use emacs which has yet to have any problem with links. Also looked 
at /boot/grub2/grub.cfg as well.


This is a legacy system but the recent changes in grub2 for "Boot 
Loader Specification" have added many quirks. I had missed that the 
grub menu entries come from the *.conf files in /boot/loader/entries.



I'm not even using uefi, yet for some reason I have
both these links:

/etc/grub2.cfg -> ../boot/grub2/grub.cfg
/etc/grub2-efi.cfg -> ../boot/efi/EFI/fedora/grub.cfg
True, the empty dummy entries are put in place holders in /boot and 
/boot/grub2 even though they are not used.

There are also references to things like "hd0,msdos2"
in grub.cfg which may need fixing as well. Possibly
there is a device.map file that needs fixing as well?
Tracked the entries for a DOS partitioned disk remembering that the 
disk count starts from 0 and the partition count starts from1, Simple 
since there is only one 1T disk.  Likewise for device.map the entry is 
(hd0) /dev/sda

I do this all the time to install a new fedora where I want
it by installing in a virtual machine then using guestmount
and rsync to put it on a "real" disk and boot it from
a stand alone grub partition using the "configfile" option.

Haven't tackled "virtual machine", what is your host?

I've never seen a uuid make it's way into an initramfs
file before, but if you can get booted by hook or
by crook, "dracut -f" forces a rebuild.


The message from dracut about initramfs was a red herring.

Fixing the *.conf entries in /boot/loader/entries gets the UUID 
problem solved and I get to the login screen but my logins are not 
accepted. Copied the original to usb disk from the source with a 
Knoppix live disk so there was nothing being executed by the file 
system. Then from the usb disk to a the partition on the target system 
again with Knoppix. The /boot was on a separate partition on the 
source and to a separate partition on the target system.


What is the login process looking for that is missing?
___


The problems was selinux.  Used the chroot process to edit 
/etc/selinus/config and disable selinux. Cloning is successful.


Recap

Knoppix DVD used to copy working Fedora 31 /boot and / to a usbdisk with 
rsync. If separate, /home and /var also


Using gparted on Knoppix on the new system make space for /boot and /, 
etc. where desired.


Copy /boot and  /, etc. to the new locations with rsync.

Using a Fedora Workstation live USB drive, boot and logoff to get out of 
graphics mode. Ctrl-alt f3 to a texmode and login with liveuser.


su - to root

From the documentation

https://docs.fedoraproject.org/en-US/Fedora/22/html/Multiboot_Guide/common_operations_appendix.html

structure the file system on the target and do the chroot.

Fix the UUID entries in /etc/fstab, /boot/grub2.cfg, 
/boot/grub2/grubenv, /grub/loader/*.conf


edit /etc/selinux/config to disable selinux

system 1 cloned to system 2


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread Tom Horsley
On Fri, 20 Mar 2020 04:43:56 +1030
Tim via users wrote:

> a. Do not install a bootloader, let me use something else (something
> you've already got, that you're prepared to configure, yourself).

It may allow me to not install grub at all (I forget), but
then I have no way to boot that partition at all.

What I do now is have a small stand alone boot partition with grub
installed. all the boot entries in that grub (the only one the
cpu boots) have "configfile" entries pointing to other partitions
which have their own /boot, their own grub.cfg, without a jumbled
mixing of multiple different kernels and partitions in a single
grub.

I can do kernel updates and wot-not and only the grub that
goes with that kernel is modified. I don't have to constantly fix
what the default boot is after every kernel update in every partition.

(uefi, on the other hand, might discombobulate this technique,
so far even my very new motherboard will let me boot old dos style
so I haven't had to deal with uefi at all).
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread Tim via users
On Thu, 2020-03-19 at 13:36 -0400, Tom Horsley wrote:
> Try installing on a one disk system in a new partition
> without it destroying the existing grub and replacing it
> with one that boots the new partition instead of the old one.
> It will no longer allow you to install grub on a partition,
> it only uses the disk block device.

Aha, now we get to the core problem.

It sounds like that would be simply solved if the installation routine
let you:

a. Do not install a bootloader, let me use something else (something
you've already got, that you're prepared to configure, yourself).

b. Do not re-partition or re-format drives, let me select existing
partitions to install to.

As far as I can recall, it used to let you do both.  It definitely used
to let you do the second one.  I haven't tried multiboot installs for a
while.  I have *one* PC with Fedora 28 & 30 on two different drives.

Multibooting has always been several kinds of pain.  UEFI has changed
the game in another way, you're supposed to let it choose what to boot.

GRUB has become worse, too.  It's almost totally incomprehensible to
customise.  The old single grub.cfg file was easy to understand and
modify.  I wonder if modern GRUB can read the old config format?

-- 
[tim@localhost ~]$ uname -rsvp
Linux 5.0.16-100.fc28.x86_64 #1 SMP Tue May 14 18:22:28 UTC 2019 x86_64

Boilerplate:  All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.

Using Windows software is like coating all your handtools with sewage.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread sixpack13

On 19.03.20 18:36, Tom Horsley wrote:

On Thu, 19 Mar 2020 15:06:52 +0100
sixpack13 wrote:


2 days ago I installed F32 on an two disk system keeping my /home and
the second disk. Reformating the rest.


Try installing on a one disk system in a new partition
without it destroying the existing grub and replacing it
with one that boots the new partition instead of the old one.
It will no longer allow you to install grub on a partition,
it only uses the disk block device.



to me it's somewhat difficult to understand what you want to archive. 
esp. English is not my native laguage.


you mean the old chainload-second-grub-partition stuff ?

did it years (10 ?) ago, but moved to a second disk box/layout/computer 
for multi-distro tests/use.


shouldn't entries for the second system be generated under the new grub ?

- at least after a boot in the new system -

osprober ?

anyway, did you write a bug report or RFC ?


will test that in an VM someday.

--
sixpack13
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread Tom Horsley
On Thu, 19 Mar 2020 15:06:52 +0100
sixpack13 wrote:

> 2 days ago I installed F32 on an two disk system keeping my /home and 
> the second disk. Reformating the rest.

Try installing on a one disk system in a new partition
without it destroying the existing grub and replacing it
with one that boots the new partition instead of the old one.
It will no longer allow you to install grub on a partition,
it only uses the disk block device.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread sixpack13

On 19.03.20 11:42, Tim via users wrote:

On Wed, 2020-03-18 at 23:50 -0400, Robert McBroom via users wrote:

Fixing the *.conf entries in /boot/loader/entries gets the UUID
problem solved and I get to the login screen but my logins are not
accepted. Copied the original to usb disk from the source with a
Knoppix live disk so there was nothing being executed by the file
system. Then from the usb disk to a the partition on the target
system again with Knoppix. The /boot was on a separate partition on
the source and to a separate partition on the target system.


I want to ask the obvious question:  Why is perserving with this
pallaver better than simply doing a fresh install on the other
computer?



it's maybe a sort of "learning curve" involving the usually - in your 
words: - "palaver" on user lists.


live is hard
be strong !
;-)

---
sixpack13
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread sixpack13

On 19.03.20 14:22, Tom Horsley wrote:

On Thu, 19 Mar 2020 21:12:51 +1030
Tim via users wrote:

...


Because these days anaconda is adamantly opposed to let you
install where you want to install without wiping out
stuff you didn't want wiped out. Installing a virtual machine
then copying it where I want it leaves me in control.


I'm "adamantly opposed" to this opinion.

2 days ago I installed F32 on an two disk system keeping my /home and 
the second disk. Reformating the rest.


ananconda (F32 *Beta*) did it all right.

so please verify if your (past) experiences are still valide.
--
sixpack13
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread Tom Horsley
On Thu, 19 Mar 2020 21:12:51 +1030
Tim via users wrote:

> I want to ask the obvious question:  Why is perserving with this
> pallaver better than simply doing a fresh install on the other
> computer?

Because these days anaconda is adamantly opposed to let you
install where you want to install without wiping out
stuff you didn't want wiped out. Installing a virtual machine
then copying it where I want it leaves me in control.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread Robert McBroom via users

On 3/19/20 6:42 AM, Tim via users wrote:

On Wed, 2020-03-18 at 23:50 -0400, Robert McBroom via users wrote:

Fixing the *.conf entries in /boot/loader/entries gets the UUID
problem solved and I get to the login screen but my logins are not
accepted. Copied the original to usb disk from the source with a
Knoppix live disk so there was nothing being executed by the file
system. Then from the usb disk to a the partition on the target
system again with Knoppix. The /boot was on a separate partition on
the source and to a separate partition on the target system.

I want to ask the obvious question:  Why is perserving with this
pallaver better than simply doing a fresh install on the other
computer?

Could not get the installers to let me put a boot partition on /dev/sda5 
and the root on /dev/sda7 while preserving the rest of the systems on 
the multiboot drive.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-19 Thread Tim via users
On Wed, 2020-03-18 at 23:50 -0400, Robert McBroom via users wrote:
> Fixing the *.conf entries in /boot/loader/entries gets the UUID
> problem solved and I get to the login screen but my logins are not
> accepted. Copied the original to usb disk from the source with a
> Knoppix live disk so there was nothing being executed by the file
> system. Then from the usb disk to a the partition on the target
> system again with Knoppix. The /boot was on a separate partition on
> the source and to a separate partition on the target system.

I want to ask the obvious question:  Why is perserving with this
pallaver better than simply doing a fresh install on the other
computer?

-- 
 
uname -rsvp
Linux 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread sixpack13

On 19.03.20 03:55, Robert McBroom via users wrote:

On 3/18/20 12:14 PM, sixpack13 wrote:

On 18.03.20 16:09, Robert McBroom via users wrote:

...


Editing the grub menu gets to a boot screen but entering an id and


you mean *login* screen ?

password lists a few entries to fast to read and goes back to the login, 
used both mode 3 for text and the default graphical. The graphical gives 
a last login and time that increments but no shell.


Found the source that the grub menu now uses for its entries in 
/grub/loader/*.conf.


Any ideas?



CRTL + F3 (or another Fx)
you should get a terminal.

if you can't login successful I guess it has something to do with user 
rights of the home dir.


how or with what tool did you clone ?

--
sixpack13
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread sixpack13

On 19.03.20 03:58, Robert McBroom via users wrote:

On 3/18/20 12:04 PM, Patrick O'Callaghan wrote:

...
The kernels from a cloned system are  far different from what is 
executing by doing a chroot from a live system, so `uname -r` is not 
useful.


that could be, but AFAIK, if I chroot to a cloned or what so ever system 
dracut should *only* see the environment of the system I chrooted to.


wasn't that the benefit of ch(ange)root ?

--
sixpack13
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread Robert McBroom via users

On 3/18/20 1:00 PM, Tom Horsley wrote:

On Wed, 18 Mar 2020 11:09:23 -0400
Robert McBroom via users wrote:


/etc/grub2.cfg

That's usually a link to the "real" file, and some
editors don't do well with links. Might want to check
the actual file down under /boot somewhere (location
varies for old dos versus uefi installs).


I use emacs which has yet to have any problem with links. Also looked at 
/boot/grub2/grub.cfg as well.


This is a legacy system but the recent changes in grub2 for "Boot Loader 
Specification" have added many quirks. I had missed that the grub menu 
entries come from the *.conf files in /boot/loader/entries.



I'm not even using uefi, yet for some reason I have
both these links:

/etc/grub2.cfg -> ../boot/grub2/grub.cfg
/etc/grub2-efi.cfg -> ../boot/efi/EFI/fedora/grub.cfg
True, the empty dummy entries are put in place holders in /boot and 
/boot/grub2 even though they are not used.

There are also references to things like "hd0,msdos2"
in grub.cfg which may need fixing as well. Possibly
there is a device.map file that needs fixing as well?
Tracked the entries for a DOS partitioned disk remembering that the disk 
count starts from 0 and the partition count starts from1, Simple since 
there is only one 1T disk.  Likewise for device.map the entry is (hd0) 
/dev/sda

I do this all the time to install a new fedora where I want
it by installing in a virtual machine then using guestmount
and rsync to put it on a "real" disk and boot it from
a stand alone grub partition using the "configfile" option.

Haven't tackled "virtual machine", what is your host?

I've never seen a uuid make it's way into an initramfs
file before, but if you can get booted by hook or
by crook, "dracut -f" forces a rebuild.


The message from dracut about initramfs was a red herring.

Fixing the *.conf entries in /boot/loader/entries gets the UUID problem 
solved and I get to the login screen but my logins are not accepted. 
Copied the original to usb disk from the source with a Knoppix live disk 
so there was nothing being executed by the file system. Then from the 
usb disk to a the partition on the target system again with Knoppix. The 
/boot was on a separate partition on the source and to a separate 
partition on the target system.


What is the login process looking for that is missing?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread Robert McBroom via users

On 3/18/20 12:04 PM, Patrick O'Callaghan wrote:

On Wed, 2020-03-18 at 11:09 -0400, Robert McBroom via users wrote:

Cloning Fedora 31 on different computer.  Fixed the UUID entries in
/etc/fstab, /etc/grub2.cfg, /boot/grub2/grubenv, but attempting to start
finds an entry for the original / UUID and drops into dracut. dracut
seems to implicate initramfs as the location of the legacy UUID and says
regenerate it.

I can use a live system to chroot to the new filesystem and do any
necessary edits.

Is there a way to edit or regenerate initramfs?

sudo dracut -f --kver `uname -r`
The kernels from a cloned system are  far different from what is 
executing by doing a chroot from a live system, so `uname -r` is not useful.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread Robert McBroom via users

On 3/18/20 12:14 PM, sixpack13 wrote:

On 18.03.20 16:09, Robert McBroom via users wrote:
Cloning Fedora 31 on different computer. Fixed the UUID entries in 
/etc/fstab, /etc/grub2.cfg, /boot/grub2/grubenv, but attempting to 
start finds an entry for the original / UUID and drops into dracut. 
dracut 


I guess you need to edit /etc/default/grub too, if you have a entry 
regarding swap/hibernate


seems to implicate initramfs as the location of the legacy UUID and 
says regenerate it.
I can use a live system to chroot to the new filesystem and do any 
necessary edits.


Is there a way to edit or regenerate initramfs?


*without* the live boot media:

for a successful start edit the UUID from the grub start menue:

I guess the "e" key at grub menu. CRTL+x, when finished editing.

when the box has booted try to reinstall the same or install an newer 
kernel should generate a new initramf


Editing the grub menu gets to a boot screen but entering an id and 
password lists a few entries to fast to read and goes back to the login, 
used both mode 3 for text and the default graphical. The graphical gives 
a last login and time that increments but no shell.


Found the source that the grub menu now uses for its entries in 
/grub/loader/*.conf.


Any ideas?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread Tom Horsley
On Wed, 18 Mar 2020 11:09:23 -0400
Robert McBroom via users wrote:

> /etc/grub2.cfg

That's usually a link to the "real" file, and some
editors don't do well with links. Might want to check
the actual file down under /boot somewhere (location
varies for old dos versus uefi installs).

I'm not even using uefi, yet for some reason I have
both these links:

/etc/grub2.cfg -> ../boot/grub2/grub.cfg
/etc/grub2-efi.cfg -> ../boot/efi/EFI/fedora/grub.cfg

There are also references to things like "hd0,msdos2"
in grub.cfg which may need fixing as well. Possibly
there is a device.map file that needs fixing as well?

I do this all the time to install a new fedora where I want
it by installing in a virtual machine then using guestmount
and rsync to put it on a "real" disk and boot it from
a stand alone grub partition using the "configfile" option.

I've never seen a uuid make it's way into an initramfs
file before, but if you can get booted by hook or
by crook, "dracut -f" forces a rebuild.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread sixpack13

On 18.03.20 16:09, Robert McBroom via users wrote:
Cloning Fedora 31 on different computer.  Fixed the UUID entries in 
/etc/fstab, /etc/grub2.cfg, /boot/grub2/grubenv, but attempting to start 
finds an entry for the original / UUID and drops into dracut. dracut 


I guess you need to edit /etc/default/grub too, if you have a entry 
regarding swap/hibernate


seems to implicate initramfs as the location of the legacy UUID and says 
regenerate it.
I can use a live system to chroot to the new filesystem and do any 
necessary edits.


Is there a way to edit or regenerate initramfs?


*without* the live boot media:

for a successful start edit the UUID from the grub start menue:

I guess the "e" key at grub menu. CRTL+x, when finished editing.

when the box has booted try to reinstall the same or install an newer 
kernel should generate a new initramfs



--
sixpack13
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


Re: System Cloning

2020-03-18 Thread Patrick O'Callaghan
On Wed, 2020-03-18 at 11:09 -0400, Robert McBroom via users wrote:
> Cloning Fedora 31 on different computer.  Fixed the UUID entries in 
> /etc/fstab, /etc/grub2.cfg, /boot/grub2/grubenv, but attempting to start 
> finds an entry for the original / UUID and drops into dracut. dracut 
> seems to implicate initramfs as the location of the legacy UUID and says 
> regenerate it.
> 
> I can use a live system to chroot to the new filesystem and do any 
> necessary edits.
> 
> Is there a way to edit or regenerate initramfs?

sudo dracut -f --kver `uname -r`

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org