Felix Miata <mrma...@earthlink.net> writes:
> This is a big lurking booby trap that could have been the problem both
> last time
> and this time. It's one of the reasons why installation systems and Grub
> switched
> from using device names to using UUIDs: inconsistent and/or unpredicable
> device
> enumeration.
>
> Is this a PC with both PATA and SATA controllers? These old PCs can
> compound the
> issue.
>
> Different kernel, disk controller, USB controller and BIOS combinations
> can cause
> e.g. an SATA or PATA disk sda to become sde, or sdb become sda, IOW,
> device names
> that don't persist. UUIDs are supposed to prevent inconsistent device
> names from
> being a problem, but in a rescue environment, it can muddy the waters, or
> backfire.
Yes on all counts. These are old PC's that use IDE
controllers. The IDE cables end in the normal 34-conductor
header with one pin missing on one side that plugs directly in to
the drive. In this case, the connector plugs in to a SATA-to-IDE
converter with a female SATA connector.
I believe you have hit the nail on the head because I
know for a fact that the devices change names. On the working
system, the boot device we would normally think of as /dev/sda is
/dev/sdc and 5 minutes from now might be /dev/sdq depending on
what drives were plugged in to usb ports when the system booted.
Just yesterday, I mounted /dev/sdd, thinking it was the
now infamous unbootable drive and immediately realized that I was
looking at the boot drive that starts the good system. I had
plugged a thumb drive in to a usb port some time earlier and then
rebooted the system while failing to remove the thumb drive as it
wasn't even being used right then.
Let's see. $ dd if=/dev/sdd of=/dev/sde What could
possibly go wrong? Just kidding this time but that's what we are
dealing with. That possibly lethal command can work but only
under the right circumstances so if one forgot to recreate the
world one was working with, it's tuition in the school of hard
knocks. I haven't yet totally given up and done anything else
rash so it's still full steam ahead. This is one of those
situations where if a person has the time, this can be a
teachable moment.
I've got several thumb drives that I mount based on their
UUID and that method of doing things is your friend if you
understand how to use it. If not, what one ends up with is total
chaos.
Felix's message hasn't saved the day yet but it confirms
my hunch that the UUID's have been at the heart of this problem
all along because there is simply no other logical reason why one
can not transplant the same boot logic from one system to the
other when they are functional copies of each other. The trick
will be to replace every UUID personalization which is doable.
Whether it is practical still remains to be seen.
To briefly reference an earlier message, I checked the
good system to see what rsnapshot did over night and /boot is
now committed to a series of little capacitors which is how SSD's
remember things. From fstab:
# /etc/fstab: static file system information.
UUID="49c4eda8-3bcc-445e-841b-513b07d560fe" /var/cache/rsnapshot ext4
relatime,rw,user,noauto 0 0
If that drive wasn't always plugged in, the boot drive
would have a different device number than /dev/sdc1 which is also
mounted by UUID. That drive also plugs directly in to a usb slot
and not any extender to hopefully insure that it is more likely
to be present.
I will uncompress the initrd files and see how hard it
will be to find the UUID and change it to what it should be on
the problem target system.
Again, thanks to all.
Martin WB5AGZ
