New drive has the same msdos partition structure as the old. Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode.
What can be done to get access to f33?
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users < users@lists.fedoraproject.org> wrote:
New drive has the same msdos partition structure as the old. Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode.
What can be done to get access to f33?
Were any original directories encrypted? Can you boot in rescue mode? If not, then you may have to arrange an alternate bootable drive (Live distro?).
Once you are booted in linux you can mount the root directory and do some basic sanity checks for proper permissions, missing home directories, etc.
More details of the command used to create the tar archive might be useful. You may be better off installing a fresh system and restoring just the home directories and other changes outside the purview of distro (/opt, /usr/local, etc).
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/25/21 5:34 PM, George N. White III wrote:
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
New drive has the same msdos partition structure as the old. Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode. What can be done to get access to f33?Were any original directories encrypted? Can you boot in rescue mode? If not, then you may have to arrange an alternate bootable drive (Live distro?).
Once you are booted in linux you can mount the root directory and do some basic sanity checks for proper permissions, missing home directories, etc.
More details of the command used to create the tar archive might be useful. You may be better off installing a fresh system and restoring just the home directories and other changes outside the purview of distro (/opt, /usr/local, etc).
The drive was pulled out of the system to a usb external drive adapter on another system, mounted and entered from a terminal window.
in the mounted root of the partition the command used was
tar -czf /mnt/stor/system.gz *
to put the tarball on a NAS.
I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by
chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas
On 26/04/2021 07:09, Robert McBroom via users wrote:
On 4/25/21 5:34 PM, George N. White III wrote:
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
New drive has the same msdos partition structure as the old. Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode. What can be done to get access to f33?Were any original directories encrypted? Can you boot in rescue mode? If not, then you may have to arrange an alternate bootable drive (Live distro?).
Once you are booted in linux you can mount the root directory and do some basic sanity checks for proper permissions, missing home directories, etc.
More details of the command used to create the tar archive might be useful. You may be better off installing a fresh system and restoring just the home directories and other changes outside the purview of distro (/opt, /usr/local, etc).
The drive was pulled out of the system to a usb external drive adapter on another system, mounted and entered from a terminal window.
in the mounted root of the partition the command used was
tar -czf /mnt/stor/system.gz *
to put the tarball on a NAS.
I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by
chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas
I have never tried using a tar file to restore. However using tar (both creating and restoring) without using the --selinux parameter won't preserve selinux context.
Have you tried booting after adding "selinux=0" to the linux line in grub?
On 26/04/2021 07:09, Robert McBroom via users wrote:
On 4/25/21 5:34 PM, George N. White III wrote:
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
New drive has the same msdos partition structure as the old.Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode.
What can be done to get access to f33?Were any original directories encrypted?  Can you boot in rescue mode? If not, then you may have to arrange an alternate bootable drive (Live distro?).
Once you are booted in linux you can mount the root directory and do some basic sanity checks for proper permissions, missing home directories, etc.
More details of the command used to create the tar archive might be useful. You may be better off installing a fresh system and restoring just the home directories and other changes outside the purview of distro (/opt, /usr/local, etc).
The drive was pulled out of the system to a usb external drive adapter on another system, mounted and entered from a terminal window.
in the mounted root of the partition the command used was
tar -czf /mnt/stor/system.gz *
to put the tarball on a NAS.
I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by
chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas
I have never tried using a tar file to restore. However using tar (both creating and restoring) without using the --selinux parameter won't preserve selinux context.
Have you tried booting after adding "selinux=0" to the linux line in grub?
I am willing to bet that /etc/fstab has uuids refering to the drives. This means to need to determine what the new uuids are and make the changes to fstab. You will also need to make changes to /etc/crypttab if you have encrypted drives.
To figure out the uuids for the drive(s), use "sudo blkid".
Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25.
Just wondering how you copied the old drive to the new one? If you manually copied the data, the blkids are different, so the boot and fstab information will have to manually be updated, or you will have to use blkid to change the blkids to match.
I generally clone disks to the new one, which also sets the blkids to be identical, so this problem doesn't happen.
I've maintained the disk imaging project G4L since 2004.
Good Luck.
On 25 Apr 2021 at 16:03, Robert McBroom via users wrote:
To: Fedora users@lists.fedoraproject.org Subject: Restored f33 on new drive from a tarball now a problem Date sent: Sun, 25 Apr 2021 16:03:57 -0400 Send reply to: Community support for Fedora users users@lists.fedoraproject.org From: Robert McBroom via users users@lists.fedoraproject.org Copies to: Robert McBroom robert.mcbroom@yahoo.com
New drive has the same msdos partition structure as the old. Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode.
What can be done to get access to f33?
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On 4/25/21 7:23 PM, Ed Greshko wrote:
On 26/04/2021 07:09, Robert McBroom via users wrote:
On 4/25/21 5:34 PM, George N. White III wrote:
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
New drive has the same msdos partition structure as the old. Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode.
What can be done to get access to f33?
Were any original directories encrypted? Can you boot in rescue mode? If not, then you may have to arrange an alternate bootable drive (Live distro?).
Once you are booted in linux you can mount the root directory and do some basic sanity checks for proper permissions, missing home directories, etc.
More details of the command used to create the tar archive might be useful. You may be better off installing a fresh system and restoring just the home directories and other changes outside the purview of distro (/opt, /usr/local, etc).
The drive was pulled out of the system to a usb external drive adapter on another system, mounted and entered from a terminal window.
in the mounted root of the partition the command used was
tar -czf /mnt/stor/system.gz *
to put the tarball on a NAS.
I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by
chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas
I have never tried using a tar file to restore. However using tar (both creating and restoring) without using the --selinux parameter won't preserve selinux context.
Have you tried booting after adding "selinux=0" to the linux line in grub?
"selinux=0" works I'll do the .autorelabel
On 4/25/21 8:32 PM, Michael D. Setzer II via users wrote:
Just wondering how you copied the old drive to the new one? If you manually copied the data, the blkids are different, so the boot and fstab information will have to manually be updated, or you will have to use blkid to change the blkids to match.
I generally clone disks to the new one, which also sets the blkids to be identical, so this problem doesn't happen.
I've maintained the disk imaging project G4L since 2004.
The new drive was a dd of the old one several years back missing many updates. I still use the /dev/sdax. The old drive says its been spinning for seven years and developed a bad patch in one of the ntfs partitions. 1465 bad sectors but still passes the self test unless a attempt is made to read certain files.
I recently migrated a fresh F33 install from a single drive installation to Raid-1. My eyes and fingers that did the initial install is over 1,000 miles away.
The initial install: / /dev/sda3 /boot /dev/sda2 /swap /dev/sda1
The following is the process I used to migrate the OS to /dev/sdb. Note I'm not using a separate /boot partition and this is a legacy BIOS: Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 67110911 67108864 32G 82 Linux swap / Solaris /dev/sdb2 * 67110912 1953525167 1886414256 899.5G fd Linux raid autodetect
mdadm -C /dev/md12 --homehost=yoda.example.com -n 2 -l 1 -e 1.2 -b internal /dev/sdb2 missing mdadm --detail /dev/md12 #edit mdadm.conf add new array
mkdir /mnt/newroot mount /dev/md12 /mnt/newroot rsync -axAX --delete --info=progress2 / /mnt/newroot/ rsync -axAX --delete --info=progress2 /boot/ /mnt/newroot/boot/ rsync -axAX --delete --info=progress2 /dev/ /mnt/newroot/dev/
mount -t proc proc /mnt/newroot/proc mount -t sysfs sys /mnt/newroot/sys #mount -o bind /dev /mnt/newroot/dev not needed
chroot /mnt/newroot
## -- chroot'ed -- #grubby --info=ALL ##kernel command line rd.md.uuid= only assembles these Raid devices ##grubby --args="rd.md.uuid=1630fa68-5cea-44be-8808-9cca3dd46a15" --update-kernel=ALL grubby --args=rd.auto --update-kernel /boot/vmlinuz-5.11.15-200.fc33.x86_64 dracut -f -v /boot/initramfs-5.11.15-200.fc33.x86_64.img 5.11.15-200.fc33.x86_64 lsinitrd /boot/initramfs-5.11.15-200.fc33.x86_64.img | less
blkid edit fstab with UUID changes #edit grub with UUID changes # legacy BIOS grub2-mkconfig -o /boot/grub2/grub.cfg grub2-install /dev/sdb # EFI grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
#dracut --regenerate-all --force ## -- chroot'ed end --
# EFI not chroot'ed efibootmgr -c -d /dev/sda -p 3 -L "Fedora (new)" -l "\EFI\FEDORA\SHIMX64.EFI"
Booting (from 2nd drive) failed using a degraded array /dev/md12. That's when I removed rd.md.uuid= from the kernel command line. No joy. Then I added rd.auto to the command line and removed AUTO +imsm +1.x -all from mdadm.conf and re-generated the initramfs and re-ran: grub2-install /dev/sdb
Note in the mdadm.conf man page that *everything* after AUTO is ignored. After sucessfully booting onto the new Raid-1 array, I fdisk'ed /dev/sda and added it to the array. Also note the use of rsync instead of tar.
Hope this helps, Bill
On 4/25/2021 7:09 PM, Robert McBroom via users wrote:
On 4/25/21 5:34 PM, George N. White III wrote:
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users <users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org> wrote:
New drive has the same msdos partition structure as the old. Legacy system with boot partition on a separate drive and from the root partition. System boots in mode 3 as specified but entering id and password flashes some text and returns to the login. Edited the grub entry to try a graphical boot but still get textmode. What can be done to get access to f33?Were any original directories encrypted? Can you boot in rescue mode? If not, then you may have to arrange an alternate bootable drive (Live distro?).
Once you are booted in linux you can mount the root directory and do some basic sanity checks for proper permissions, missing home directories, etc.
More details of the command used to create the tar archive might be useful. You may be better off installing a fresh system and restoring just the home directories and other changes outside the purview of distro (/opt, /usr/local, etc).
The drive was pulled out of the system to a usb external drive adapter on another system, mounted and entered from a terminal window.
in the mounted root of the partition the command used was
tar -czf /mnt/stor/system.gz *
to put the tarball on a NAS.
I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by
chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, 28 Apr 2021 16:20:23 -0400 Bill Shirley wrote:
Also note the use of rsync instead of tar.
I always install a new fedora at home by doing the install in a virtual machine, then doing a guestmout of the VM image and using rsync to copy everything to an empty partition on my "real" machine (usually the one that has the two fedoras ago release installed on it which I clear out first).
I note the blkid values from inside the virtual machine and grep -R for those UUIDs in the copied image (mostly find them in /boot and /etc). That tells me the UUIDs to edit to fix things so it will boot in the new partition. A few other things need fixing as well, but then I can boot using the "configfile" option in grub from the nice stand alone grub partition I have just to boot other partitions.
Just installed f34 this way, seem to work fine (still tweaking the install to make it useful though).
I do turn off selinux through all this. If I wanted to turn it back on I'd look up how to force it to relabel everything on boot.
On 4/26/21 12:23 AM, Robert McBroom via users wrote:
On 4/25/21 7:23 PM, Ed Greshko wrote:
On 26/04/2021 07:09, Robert McBroom via users wrote:
On 4/25/21 5:34 PM, George N. White III wrote: The drive was pulled out of the system to a usb external drive adapter on another system, mounted and entered from a terminal window.
in the mounted root of the partition the command used was
tar -czf /mnt/stor/system.gz *
to put the tarball on a NAS.
I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by
chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas
I have never tried using a tar file to restore. However using tar (both creating and restoring) without using the --selinux parameter won't preserve selinux context.
Have you tried booting after adding "selinux=0" to the linux line in grub?
"selinux=0" works I'll do the .autorelabel
.autorelabel doesn't get everything apparently. From a texmode boot as user, startx for the graphical desktop fails saying it can't find a screen. The ati 5450 has on a minimal xinitrc with no screen paragraphs. However, from root it works.
Put selinux=0 in the kernal command in grub allows user to dos startx but there are I/O problems with the mouse.
All the permissions look as expected
On 30/04/2021 04:17, Robert McBroom via users wrote:
On 4/26/21 12:23 AM, Robert McBroom via users wrote:
On 4/25/21 7:23 PM, Ed Greshko wrote:
I have never tried using a tar file to restore. However using tar (both creating and restoring) without using the --selinux parameter won't preserve selinux context.
Have you tried booting after adding "selinux=0" to the linux line in grub?
"selinux=0" works I'll do the .autorelabel
.autorelabel doesn't get everything apparently. From a texmode boot as user, startx for the graphical desktop fails saying it can't find a screen. The ati 5450 has on a minimal xinitrc with no screen paragraphs. However, from root it works.
Put selinux=0 in the kernal command in grub allows user to dos startx but there are I/O problems with the mouse.
All the permissions look as expected
Well, in this case I'd then use the "ausearch" command to find the AVC which happened at the time of failure. You can use the --start and --end parameters to narrow down the time frame of the search. Check the man page for the format of that parameter.
https://access.redhat.com/articles/2191331 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
Could be of value in searching for the problem.
On 4/29/21 6:16 PM, Ed Greshko wrote:
On 30/04/2021 04:17, Robert McBroom via users wrote:
On 4/26/21 12:23 AM, Robert McBroom via users wrote:
On 4/25/21 7:23 PM, Ed Greshko wrote:
I have never tried using a tar file to restore. However using tar (both creating and restoring) without using the --selinux parameter won't preserve selinux context.
Have you tried booting after adding "selinux=0" to the linux line in grub?
"selinux=0" works I'll do the .autorelabel
.autorelabel doesn't get everything apparently. From a texmode boot as user, startx for the graphical desktop fails saying it can't find a screen. The ati 5450 has on a minimal xinitrc with no screen paragraphs. However, from root it works.
Put selinux=0 in the kernal command in grub allows user to dos startx but there are I/O problems with the mouse.
All the permissions look as expected
Well, in this case I'd then use the "ausearch" command to find the AVC which happened at the time of failure. You can use the --start and --end parameters to narrow down the time frame of the search. Check the man page for the format of that parameter.
https://access.redhat.com/articles/2191331 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
Could be of value in searching for the problem.
Didn't look too promising. Started over with the --selinux option on tar and all is well. Have to look for the the discussion of --selinux on the tar documents, hadn't seen it and the traditional use of tar for system backup would be useless without it.
On 2021-04-25 4:09 p.m., Robert McBroom via users wrote:
I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by
chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas
Since you can chroot, you could use "journalctl" to check the logs from the previous boot to see what was happening. Maybe you need to force an selinux relabel. "touch /.autorelabel"
On 5/1/21 9:59 AM, Robert McBroom via users wrote:
On 4/29/21 6:16 PM, Ed Greshko wrote:
On 30/04/2021 04:17, Robert McBroom via users wrote:
On 4/26/21 12:23 AM, Robert McBroom via users wrote:
On 4/25/21 7:23 PM, Ed Greshko wrote:
I have never tried using a tar file to restore. However using tar (both creating and restoring) without using the --selinux parameter won't preserve selinux context.
Have you tried booting after adding "selinux=0" to the linux line in grub?
"selinux=0" works I'll do the .autorelabel
.autorelabel doesn't get everything apparently. From a texmode boot as user, startx for the graphical desktop fails saying it can't find a screen. The ati 5450 has on a minimal xinitrc with no screen paragraphs. However, from root it works.
Put selinux=0 in the kernal command in grub allows user to dos startx but there are I/O problems with the mouse.
All the permissions look as expected
Well, in this case I'd then use the "ausearch" command to find the AVC which happened at the time of failure. You can use the --start and --end parameters to narrow down the time frame of the search. Check the man page for the format of that parameter.
https://access.redhat.com/articles/2191331 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
Could be of value in searching for the problem.
Didn't look too promising. Started over with the --selinux option on tar and all is well. Have to look for the the discussion of --selinux on the tar documents, hadn't seen it and the traditional use of tar for system backup would be useless without it. _______________________________________________
To happy to soon, Did an update to get current and on reboot and login the entire system is read only. Looking at directories with emacs and all permissions look fine but any attempt to write fails.
On 2021-05-03 9:33 p.m., Robert McBroom via users wrote:
To happy to soon, Did an update to get current and on reboot and login the entire system is read only. Looking at directories with emacs and all permissions look fine but any attempt to write fails.
Check the log to see why.
On 5/4/21 12:43 AM, Samuel Sieb wrote:
On 2021-05-03 9:33 p.m., Robert McBroom via users wrote:
To happy to soon, Did an update to get current and on reboot and login the entire system is read only. Looking at directories with emacs and all permissions look fine but any attempt to write fails.
Check the log to see why. _______________________________________________
Found an error in the uuid for / in fstab. Interesting that read access was available at all.
On 5/10/21 8:58 PM, Robert McBroom via users wrote:
On 5/4/21 12:43 AM, Samuel Sieb wrote:
On 2021-05-03 9:33 p.m., Robert McBroom via users wrote:
To happy to soon, Did an update to get current and on reboot and login the entire system is read only. Looking at directories with emacs and all permissions look fine but any attempt to write fails.
Check the log to see why. _______________________________________________
Found an error in the uuid for / in fstab. Interesting that read access was available at all.
I assume the device in the kernel command line was correct, so the kernel could mount the rootfs to boot. But once the system was running it didn't have the right information to remount it r/w.
-
alan＠clueserver.org -
Bill Shirley -
Ed Greshko -
George N. White III -
Michael D. Setzer II -
Robert McBroom -
Samuel Sieb -
Tom Horsley