Thanks Ed, Matt, and Word Wizard for your response.
M. Edward (Ed) Borasky wrote:
> This looks familiar. Didn't we run into this at a Linux clinic a
> couple of months ago?
>
Yes, and I thank you for your help. But as I recall, we were never able
to get it to boot on any machine other than the machine it was installed on.
When I edit the line /root=/dev/disk/by-id/ata-WDC....-part2/
to /root=/dev/sda2/
and edit /resume=/dev/sda1 /and then hit the escape key to end editing,
I can see the line displayed on the screen just as it was before I
edited it and when I hit b for boot, the results are the same, it hangs
for a while then switches to console mode and displays the same old message:
"Could not find /dev/disk/by-id/ata-WDC......"
Is there some command I am missing that is required to save or use the
edited line before resuming the boot process?
I have also tried /dev/hda2 and /dev/hda1 with the same results.
By the way, when I boot the disk on the machine it was installed on and
look in the /dev/disk/by-id/ directory, I see the following links.
ven...@suse30:/dev/disk/by-id> ls -lah
total 0
drwxr-xr-x 2 root root 280 2009-05-28 05:58 .
drwxr-xr-x 5 root root 100 2009-05-28 05:58 ..
lrwxrwxrwx 1 root root 9 2009-05-28 05:58
ata-WDC_WD800JB-00JJC0_WD-WMAM9CUM7063 -> ../../sda
lrwxrwxrwx 1 root root 10 2009-05-28 05:58
ata-WDC_WD800JB-00JJC0_WD-WMAM9CUM7063-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2009-05-28 05:58
ata-WDC_WD800JB-00JJC0_WD-WMAM9CUM7063-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2009-05-28 05:58
ata-WDC_WD800JB-00JJC0_WD-WMAM9CUM7063-part3 -> ../../sda3
lrwxrwxrwx 1 root root 9 2009-05-28 05:58 edd-int13_dev80 -> ../../sda
lrwxrwxrwx 1 root root 10 2009-05-28 05:58 edd-int13_dev80-part1 ->
../../sda1
lrwxrwxrwx 1 root root 10 2009-05-28 05:58 edd-int13_dev80-part2 ->
../../sda2
lrwxrwxrwx 1 root root 10 2009-05-28 05:58 edd-int13_dev80-part3 ->
../../sda3
lrwxrwxrwx 1 root root 9 2009-05-28 05:58
scsi-SATA_WDC_WD800JB-00J_WD-WMAM9CUM7063 -> ../../sda
lrwxrwxrwx 1 root root 10 2009-05-28 05:58
scsi-SATA_WDC_WD800JB-00J_WD-WMAM9CUM7063-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2009-05-28 05:58
scsi-SATA_WDC_WD800JB-00J_WD-WMAM9CUM7063-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2009-05-28 05:58
scsi-SATA_WDC_WD800JB-00J_WD-WMAM9CUM7063-part3 -> ../../sda3
ven...@suse30:/dev/disk/by-id>
These links appear to be freshened each boot although the time zone
doesn't look like anything I recognize. As it was 12:58 local time,
anything with a time of 05:58 should be somewhere where it is tomorrow.
>>> Do you think not being able to run on any hardware other than the
>>> installation hardware is a good idea?
>>>
Addressing the question above, I hate to see Linux loosing it's openness
and flexibility. I use mobile disk drive docks that enable me to quickly
put any disk into any of my computers. At a customer's site, I may have
several computers controlling different processes. I leave 1 spare
computer on the shelf with a mobile dock installed and a spare disk in a
mobile dock tray for each machine. The GRUB by-id stuff would end all of
that flexibility. It would require a spare computer and disk for each
machine.
While I am at it, I may as well sound off as to what I think of the
/udev rules. In case you are not aware of the addition of the /udev
(user devices) rules, they lock hardware to a particular interface. For
example, the eth0 interface can only be assigned to a NIC with a certain
MAC address. If your NIC should die and you replace it, the interface
won't come up until you do something with the network rules file.
When the /udev rules were first introduced into Slackware, they were
flexible, you could list a single MAC address and associate that with a
interface or list multiple MAC addresses each associated with a
interface. This was the desired result of the udev rules, to always
assign the same interface to the same hardware. You could also list a
multiple MAC addresses all associated with the same interface as I did
in my Slackware 12.0 /etc/udev/rules.d/75-network-devices.rules file below.
# Local network rules to name your network cards.
#
# These rules were generated by nethelper.sh, but you can
# customize them.
#
# You may edit them as needed.
# (If, for example, your machine has more than one network
# card and you need to be sure they will always be given
# the same name, like eth0, based on the MAC address)
#
# If you delete this file, /lib/udev/nethelper.sh will try to
# generate it again the next time udev is started.
KERNEL=="eth?", ATTR{address}=="00:06:4f:25:67:b1", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:06:4f:59:04:34", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:13:46:e7:81:52", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:04:bf:90:b7:a2", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:04:bf:90:b7:a1", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:a0:cc:69:5c:55", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:d0:09:e6:23:38", NAME="eth0"
KERNEL=="eth?", ATTR{address}=="00:1e:90:fe:9d:ac", NAME="eth0"
If the disk boots in any machine and finds one of the MAC addresses
above, eth0 will come up. This worked, not great, but it worked.
Later versions of the Slackware /udev stuff are not as flexible. Should
the disk be moved to another machine, the only way I have been able to
get the network to come up is to delete
/etc/udev/rules.d/75-network-devices.rules and reboot. Again, lost
flexibility.
Wayne
Matt M. wrote:
>>> Wayne
>>>
>>>
>>>
>>>
>>>
>> This is a bit of a shot in the dark, but I may have run into something
>> similar, although with Ubuntu.
>> It may be that OpenSuSE uses UUID of the disk to determine what to boot,
>> instead of a pathname like /dev/hda or /dev/sda. Moving the disk to a
>> different computer, causes that disk to have a different UUID since it is on
>> a different IDE/SATA controller. UUID is said to remain constant across
>> reboots, but only on the same computer. If you move the drive to another
>> computer (and thus another IDE/SATA controller) the UUID is not guaranteed
>> and likely not going to be the same.
>>
>> One thing you can do, is when the system boots, interrupt the automated
>> countdown, and go into GRUB and edit the kernel line (use arrow keys to
>> hightlight the line that has "kernel" and hit "e" to edit) so that it points
>> to /dev/hda1 or /dev/sda1 (depending on your disk) instead of the UUID, and
>> see if it boots. If it does, you can then get the UUID of the disk in the
>> new computer on the command line (I forget the exact command offhand,
>> perhaps someone else can chip in with it...), and edit /boot/grub.conf and
>> change it to point to the new UUID to boot to it each time.
>>
>> I am pretty sure OpenSuSE uses GRUB now yes?
>>
>> This is a guess but an educated guess... ;)
>>
>> ----------
>> Matt M.
>> LinuxKnight
>> _______________________________________________
>> PLUG mailing list
>> [email protected]
>> http://lists.pdxlinux.org/mailman/listinfo/plug
>>
>>
>
>
>
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
