3:03 p.m.
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?
4:34 p.m.
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users <
users(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
--
George N. White III
6:09 p.m.
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(a)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
6:23 p.m.
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(a)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?
--
Remind me to ignore comments which aren't germane to the thread.
7:11 p.m.
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(a)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.
11:23 p.m.
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(a)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
3:17 p.m.
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
5:16 p.m.
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/...
Could be of value in searching for the problem.
--
Remind me to ignore comments which aren't germane to the thread.
8:59 a.m.
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/...
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.
11:33 p.m.
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/...
>
>
> 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.
11:43 p.m.
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.
10:58 p.m.
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.
12:05 a.m.
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.
3:20 p.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
3:35 p.m.
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.
5:16 p.m.
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"
7:32 p.m.
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(a)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(a)lists.fedoraproject.org>
From: Robert McBroom via users
<users(a)lists.fedoraproject.org>
Copies to: Robert McBroom
<robert.mcbroom(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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/
+------------------------------------------------------------+
11:36 p.m.
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.
1078
days inactive
1094
days old
17 comments
8 participants
participants (8)
-
alan＠clueserver.org -
Bill Shirley -
Ed Greshko -
George N. White III -
Michael D. Setzer II -
Robert McBroom -
Samuel Sieb -
Tom Horsley