-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-11-03 01:37, Linda Walsh wrote:
Carlos E. R. wrote:
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.
WRONG. This is my line in grub 1 menu.lst: kernel /vmlinuz-3.11.10-21-desktop root=/dev/disk/by-label/a_main resume=/dev/disk/by-label/b_swap showopts splash=verbose console=tty0 vga=0x31a Because there it is the *kernel* which does the reading, not grub. No matter that you thing that you need udev, it is obviously working. Grub 1 uses this to find the kernel itself: root (hd0,1) which depends on hd0 always being hd0, as handled of by the *BIOS*. Then, depending on what is plugged that day, it becomes either sda or sdb, depending on the *kernel's* choice of the day. On another system using grub2, I see: menuentry 'openSUSE 13.1' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-00eb9a40-d067-459e-a22f-1d3b667dddbb' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos3' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3' 6d9d4270-3fd1-4027-9316-c614d6c090e4 else search --no-floppy --fs-uuid --set=root 6d9d4270-3fd1-4027-9316-c614d6c090e4 fi echo 'Loading Linux 3.11.10-21-desktop ...' linux /vmlinuz-3.11.10-21-desktop root=UUID=00eb9a40-d067-459e-a22f-1d3b667dddbb resume=/dev/disk/by-label/b_swap splash=verbose showopts echo 'Loading initial ramdisk ...' initrd /initrd-3.11.10-21-desktop } which as you can see, uses 'hd0' initially, but if that fails it searches for the listed uuid. Thus, grub2 may boot a system based on the UUID, regardless of where it is.
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"...
I don't expect "/home" or "/" (both internal and fixed disks) to come and go. If either disk is missing, for whatever reason, I do not want the boot to proceed. This can happen if I accidentally shuffled the cables around a bit and forgot to plug one. I do not want "/usr/local/" to appear mounted in "/var/spool/" because I swapped a cable in mistake, inside the box. All of those examples are permanent drives, internal. Using, as I do, 'label's, or 'uuid's, that type of accident simply doesn't happen. I simply do not notice, the system boots happily and working correctly, every thing mounted on the expected place. That's progress to me.
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.
I call that "non-booting". :-| - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRW5FwACgkQtTMYHG2NR9X0RgCfQtf/S5RO0XkNhF7u5l/42j9F Ec4An1EEUdGG+MvHrTdJI9usP2binV/+ =wXd3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org