[Gllug] Bootable USB backup like OS X dmg?

[Steve Parker]

On 29/05/11 18:02, general_email at technicalbloke.com wrote:
> On 24/05/11 19:34, Steve Parker wrote:
>    
>> On 24/05/11 17:13, Dagfinn Ilmari Mannsåker wrote:
>>      
>>> Steve Parker<steve at steve-parker.org>   writes:
>>>
>>>
>>>        
>>>> On 24/05/11 16:38, gvim wrote:
>>>>
>>>>          
>>>>> This is not what I'm looking for. I want to make an externally
>>>>> bootable disk image of an installed Linux system, not a generic
>>>>> USB-bootable Linux distro. Something like SuperDuper! on Mac OS X.
>>>>>
>>>>>            
>>>> Your device paths etc are likely to be invalid if you boot one server's
>>>> image on another server
>>>>
>>>>          
>>> That's why you use UUIDs and logical volume names, not raw physical
>>> device paths, in fstab etc.
>>>
>>>
>>>        
>> PCI paths to NICs, or MAC addresses? I'm just saying, it's worth being
>> aware of these things. /dev/disk/by-* etc is useful, but only goes so
>> far.
>>
>>      
> Aren't those autodetected in the majority of cases? Doing as Dagfinn
> suggests and just making sure your devices are referenced by UUID should
> be enough. It certainly was for me when I upgraded my Ubuntu system
> recently. I took the drives out of my old machine, lashed them into the
> new one in arbitrary order, pointed the bios to the system drive and it
> booted straight up - no reconfiguration needed (except for my swap but
> that was only because I had more RAM in the new box).
> n
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. UIDs on filesystems helps to keep them under control, but what 
about raw devices (which Oracle DBs still like to play with)? Another 
level of abstraction is (Symantec) Veritas Volume Manager, which has its 
own view of the world. This is all datacentre type stuff, not desktop 
level stuff.

It's been a long time since I've felt the need to defend Linux against a 
Windows desktop OS, but comparing this with Solaris, it can be a real 
pain that the udev driver is so dynamic that it renames every device it 
finds on every reboot based upon how soon each device gets its response 
back down the PCI device tree.

I've built over 100 Sun/Oracle x86 class servers in the past year or so, 
with Oracle Enterprise Linux (basically RHEL, or CentOS). They all have 
onboard NICs (some have two, others have four) and all have a quad PCI 
NIC for resilience. During the install, they all detect the PCI card 
first, then the onboard, so the onboard is eth4. Long-term, I want the 
first onboard NIC to be called eth0, so I have to mess with udev rules.

Similarly, I require internal disk and SAN LUNs to be dealt with 
consistently across reboots, mainly due to limitations in Oracle and 
Veritas software as mentioned above. The way that udev deals with this 
is currently not good enough for me to compare any Linux distro with 
current Solaris 10 on the same hardware. Solaris 10 on SPARC is even 
more predictable.

But with any architecture and/or OS, you need to know that the root disk 
will be a SCSI-capable disk with an ext filesystem, that the first NIC 
will be an Intel-compatibile device with a certain MAC or PCI 
address...  unless you assume that you will only boot on a single-disk 
PC with one NIC (including WiFi), and lots of other typical Wintel 
assumptions.
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug