Mailinglist Archive: opensuse (1620 mails)

< Previous Next >
[opensuse] Re: Why uuid its confusing: kernel doesn't recognize it
Carlos E. R. wrote:
On 2014-10-30 10:01, Hans Witvliet wrote:
No more horror-scenario's from the past, where external scsi-drives
ended up somewhere else, only because one of the powercables were
disconnected.
---
If a scsi cable isn't detected, it would most
likely be from a fixed-mount in fstab. In that case, the
boot-mount of drives would fail and your system won't boot.

VS:

Some random boot with file systems not containing
the right content, in which case, your system isn't likely to boot
unless the missing drive was near the end of some drive chain. Still
not great.

I am not _sure_, that I see a great benefit here.

Vs. -- if you use UUID, and try to boot from it
(aka boot=/dev/disk/by-uuid1 root=/dev/disk/by-uuid2), the kernel
won't boot as it doesn't recognize anything in /dev/disk without
a system being already booted (aka an init-ramdisk that runs
'udev'(or *equiv*)) that assigns and interprets those UUID's.

Everything in /dev/disk/xxx is a symlink to the
kernel recognized name for those partitions. But those
symlinks are created by 'udev' rules and won't exist prior
to booting a system and starting 'udev'.

For 'removable drives', partitions should be
mounted from /etc/auto.XXX to not interfere with
your systems non-removable drives.


If a drive is (momentarily) not detected, it just should
mean that its content is not available. It should not have any
consequence where the data of other drives might end up...

LOL.

That's precisely the issue solved by using UUIDs ;.)
---

That's really up to the sysadmin who should know to put
fixed drives in /etc/fstab and drives that might become
"'momentarily'-not-detected" in the /etc/automounter
hierarchy that expects mounts to "come and go"...

Your system NEEDS to know which drives are "permanent"
and which are "temporary" for performance reasons (how often
to flush caches to a writeable media). By default, removable
drives will have caches flushed after every write. Built-in
drives, however, have the option to allow a more relaxed
flush schedule that has less impact on system performance (and
is less likely to cause drive fragmentation).


I heard of a tool. Dunno. But MS may refuse to boot on the grounds of
"changed hardware, you are a pirate!".
---
While there are many reasons MS won't boot, changing HW
causing Windows to not validate is not one of them -- it does boot,
but operates in some "restricted mode" (that does something like
reboot every few minutes or something -- that can give you a chance
to recover a valid installation, but do little else; admittedly
with all the Win updates, this might have changed, but I seem to
remember that even MS, recognized as folly, piracy yielding
the same feedback as other problems.


--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups