Will/should a system/drive built on one system boot & work o

[wilcal]

I've a general question concerning the exchange of hard drives from one system to another. Given: System A & System B. They are both identical in every way. MoBo, Processor, memory ect ect. Install lets say up and upcoming Mageia 5 on a 1TB drive on System A. When that's finished, updated and running remove the drive from System A and move it over to System B. Would you expect that system to boot and run just as it did on System A? I have seen at least one "Linux Expert" indicate that that should never work and Linux security guards against this kind of thing happening. Is he not understanding the UEFI Secure Boot thingy or something?

I've been creating systems that do this for years and have had no problems doing it. I did it just yesterday with a prerelease version of M5. All went just fine between two 32-bit systems. And the two systems are not identical.

As a Mageia user what would you expect?

[filip]

I updated my PC last year. The only things that was the same were SSD and HD. Previous PC had 32 bit mga4 install so I enabled legacy mode in UEFI on new 64 bit MB. Grub and mga4 started without any hickup. You might need "dracut -f" tough.

I went 64 bit with mga5RC but I still use legacy boot as I'm not ready to go GPT just yet.

[doktor5000]

Should be no issue at all - only thing that usually needs manual intervention (or at least that was like that in the past) that the network will not come up,
as the other system uses a different MAC adress for the same device. In the past that needed editing or deletion of /etc/udev/ules.d/70-persistent-net.rules
as that file would contain the PCI IDs and mac adresses and which driver to load for them.

Apart from that, as the kernel usually brings a great amount of drivers for a really broad range of hardware by default,
this is usually not an issue between completely different systems. You might need to intervene if the underlying
storage/RAID drivers are completely different, that means you might need to rebuild the initrd via dracut as filip mentioned.
And the more obvious thing is the X driver, if you move from nvidia to ATI or something like that.
But a simple run of drakx11 should fix that.

Even with secure boot that should not be an issue at all, as the original key is contained in UEFI, against which
the bootchain is verified. So if you have a system that supports secure boot (currently only Fedora and *buntu out of the box IIRC) it will boot on both systems.

If you want to know more, simply google a bit related to linux cloning. Some examples:
http://superuser.com/questions/516544/w ... er-machine
http://unix.stackexchange.com/questions ... w-computer
http://unix.stackexchange.com/questions ... l-harddisk
http://askubuntu.com/questions/25633/ho ... /5025#5025

[wilcal]

doktor5000 said:

> Should be no issue at all.....

That's my thinking on this. Lets say you have a small server farm of a dozen identical Dell Blade servers all featuring removable, replaceable drives ( no RAID ). You should be able to operate a 13th Blade, identical to the other 12, build systems on that and just slide them into the other dozen as needed. Assign IP's using the Router. I am actually in the process here of building two identical systems ( different chassis ). One for on-line continuous duty the other for off line testing and stuff. IP's here are assigned by DHCP but I set the router to port forward and set IP's to MAC's as needed. I should be able to build the system hd on one box and slide it into the online system without any problems. Thanks.

[wilcal]

Here's one video I found:

Mythbusting Linux: https://www.youtube.com/watch?v=y_lhqg_p21k

Starting at 14:30

[doktor5000]

Mythbusting Linux: https://www.youtube.com/watch?v=y_lhqg_p21k
Starting at 14:30

Well, he's a little bit off, as the UUIDs will not change on disk when you move a disk to a new system, only if you do actual changes to the partitions.
But then, in the case you want to do that more frequently, you should use labels or directly /dev/sdxN naming in /etc/fstab. It is true that in many cases it will not boot,
but more due to the reasons I've described before, which should all be fixable from an emergency shell, or if it can not boot at all you might need a live cd.

As an opposite example, why do you think a lot of people will create USB drives so they can take their installation with them ... ?
Or why Mandriva had a commercial product for this purpose? https://web.archive.org/web/20081028203 ... anguage=en

Apart from that, there's at least one more important detail to consider, that is ssh (host) keys - you should obviously not clone those too, as that would be a really bad idea.

[jiml8]

In that video, he did something that appeared to be HP-specific to identify that he had plugged that hard drive in, and I don't understand what, exactly, he did. I also do not know that he unplugged the old drive from the HP desktop.

I did not see him tell BIOS to switch the boot drive, and I don't know that what he did was correct.

I do know that I personally have done what he just did (using modern distros), and had the system boot just fine off of the moved HD. Usually, though, I turn off UEFI so it could be something to do with that...I'm not sure.

The error message he showed is the message I am used to seeing when I copy an installation onto a new hard drive; the UUID is unique to the drive, and most modern distros put that UUID into the initrd as well so copying a distro to a new drive requires some extra work. I generally just change the UUID of the new system partition to match what the initrd wants because that is usually a bit easier than rebuilding the initrd from a repair distro.

Beyond that, in the rest of the video, he was strictly accurate but (IMO) picking nits. In the 17-odd years I have used Linux, I have never had to defrag an extN filesystem; it has never been necessary, and I am certainly not your typical home user. Also, while I grant that some Linux users DO say "there is no malware on Linux", those who are genuinely knowledgeable say: "the risk of malware on Linux is non-zero, but much less than the risk on Windows, and the typical Linux system is far more resistant to malware than the typical Windows system due to the security model". At that, the malware he demonstrated apparently was preventing the opening of one program; he did not demonstrate the existence of a significant system compromise - and thus, the point about "resistant" is supported.