[Gllug] Bootable USB backup like OS X dmg?

[Steve Parker]

On 31/05/11 17:17, Nix wrote:
> On 31 May 2011, Steve Parker outgrape:
>    
>> On 30/05/11 11:59, Nix wrote:
>>      
>>> On 30 May 2011, Steve Parker outgrape:
>>>        
>>>> It depends on the type of machine, and what you are trying to achieve.
>>>> For a PC, then yes, the dynamic way in which the current Linux kernel
>>>> and udev works is great. With more than one NIC, there is no guarantee
>>>> that they will both be detected as eth0/eth1 respectively on different
>>>> boots.
>>>>          
>>> udev has been able to bind names to network interfaces by MAC for many
>>> years (following which those names will not change), and has had a rule
>>> generator to automate that process after first boot for almost as long.
>>>        
>> Yes, although I don't like hard-coding MAC addresses (with RHEL you
>> can put the MAC in ifcfg-NIC); NICs don't often fail, but when they
>> do, and you replace it with a new one, I want it to be detected based
>> on its PCI address.
>>      
> ... while I consider PCI address stuff to be a hideous bus-specific
> bodge. I've encountered PCI busses where the addresses weren't stable
> between boots (often in virtualization), but have never once seen a
> system where the MAC address jumped about at random.
>    
I've not seen PCI buses move, but I've not done a lot with virtual 
machines. Intuitively it would seem surprising even for a VM to do that.
MAC addresses don't jump about at random, but when you replace the NIC 
the MACs are guaranteed to change. Not everybody who is on call at 3am 
to replace a NIC knows how to update rules.d, but even if they did, I 
consider hard-coding MACs in the OS even worse than hard-coding WWNs in 
FC switch zone configurations (which similarly have to be updated when 
replacing HBAs, but that's the fault of something beyond the OS, and not 
something that I can do anything about in my current role).

I can replace RAID Cards, DIMMs, even CPUs without telling the OS about 
it, but when I replace a PCI NIC, I have to choose between its physical 
location and the contents of its firmware to identify it. Neither is 
ideal, but MAC is the least ideal IMO.
>> What's the rule generator? I haven't come across that
>>      
> It's a udev rules file which notes your Ethernet card's MAC->name
> mapping on first boot and writes another udev rules file which
> establishes that binding for all time and turns off the first rules
> file.
>
>    
Oh, that. I thought you were referring to something useful ;-) As I 
mentioned, what it detects on first boot is exactly *not* what I want to 
have persistently.

Steve
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug