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
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
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
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
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,
>
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
20 matches
Mail list logo
