Jeremy Visser <jeremy(a)visser.name> writes: +1. The biggest reason for this is decreased determinism in module loading order -- e.g. at least *in theory* it might load USB, then PATA, then SATA one boot, then next boot it loads SATA then USB then PATA.

Hi yet again, (1) sda sdb confusion: Hadn't ever experienced sda and sdb changing assignments in my system -- except one period years ago when the pin contacts on my IDE/PATA caddies got a bit wonky. In my backing up system, I'm clear about the physical location of master and backup drives, and include a visual (LED-on) confirmation of drive assignment before the shell script starts the RSYNC command. First time using SATA. Hope it doesn't introduce any randomising factors. (2) LABEL a possible bullet-in-the-foot: As every single file and directory is copied in my backup system, it may COPY the master disk label on to the backup disk, creating a dual identity problem from then on. But if it does NOT copy the label across, then the backup disk would not boot (in a restore situation) due to an invalid identification problem, similar to the UUID that I'm working around. Thanks for thinking about it, though. Carl p.s. And =still= no one has actually commented on the adequacy and accuracy of the proposed editing in the boot-up configuration files in my original post. Sigh. On 22/04/14 13:03, Daniel Jitnah wrote:

Hi, I easily overcame the libata changeover (/dev/sda) with my IDE drives. I never (have a need to) hot swap any drives. And always power down my system when not in use, and disconnect the mains power board. (Surge protectors have their limitations.) Haven't used SATA drives until the last couple days. Haven't had two drives in at same time yet. Just fired it up and noticed that the SATA dual drive caddy from Lindy has a LED for each disk, but that it doesn't light up when read/writing. Hmm. Will have to talk with them about that. When doing backups, it will always be from a cold start with both HDDs already inserted. Will think a bit more about verifying identity of source and destination drives, in this SATA world. Carl p.s. Still no advice from anyone about the original UUID editing-out that I posted. We're too busy with the meta-picture. On 22/04/14 16:23, Russell Coker wrote:

Hi Brett, Hmm. Good point. Of course, the "general consensus" is also that we should all use Windows, and stop using Linux or Apple. Ha ha. Shall we? Nah. There's a few of us who still like to swim against the tide & experiment, and in the so-doing make elegant discoveries. Cheers, Carl On 22/04/14 16:50, Brett Pemberton wrote:

Hi Trent, I had a 50/50 feeling that label would be metadata, providing no solution to my original different-UUIDs-at-boot-up problem. So an alternative to my current rsync approach could be dd'ing. Hmm. But if dd'ing is so thorough, wouldn't the kernel (?) go into an exception routine, the next time I do a backup, when it tries to mount two hard disks with the exact =same= UUID and/or label? BTW: Can one dd from a filesystem whilst running on that same filesystem? BTW BTW: In the current scheme, while I'm rsync'ing from a filesystem whilst running on that same filesystem... I've shut it down to runlevel 1. Never had a problem yet. Cheers, Carl On 23/04/14 10:40, Trent W. Buck wrote:

Hi Craig, Darn, that's right. The things I loved about rsync were how very thorough and very fast it was. Using dd would be a =real= time muncher. The cadence of "UUIDs are not the problem you imagine them to be" (however true) reminds me of the scene where Obi Wan convinces the stormtrooper that "these are not the droids we're looking for". Yeah, my style of "restoring" isn't that common an occurrence, so editing the relevant files on the rare occasion would be OK. And including the editing of boot up scripts in the backup script would be even better. (Thanks for the sample code, as I'd be at a loss to begin to remember how.) Cheers, Carl On 23/04/14 16:13, Craig Sanders wrote:

Craig, Your last paragraph says it all for me. I'm more focused on fire, flood, theft, lightning strike, and power outage than media failure per se. Which reminds me: I've got a good little UPS whose SLA battery is quite dead. Need to get to Jaycar or Altronics and replace the battery with a new one. Carl On 23/04/14 17:13, Craig Sanders wrote:

On Wed, 23 Apr 2014 05:13:10 PM Craig Sanders wrote: For those of us in bushfire areas here's something to make why a bit more concrete, this is what's left of the doctors PC from Marysville: https://www.flickr.com/photos/chrissamuel/7746409996/ Fortunately the doctor survived. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC

On Wed, 23 Apr 2014 16:13:13 Craig Sanders wrote: One thing that DD is good for is the boot loader. For a machine with a single disk I make /boot the first partition on the disk and make it a primary partition. Then I use dd to backup the MBR and first partition. On a restore I use dd to copy that to the new disk and then run fdisk to fix the size of the other partitions before restoring a rsync backup and editing GRUB config files. There are CD/USB boot images that can be used to reinstall GRUB, but I find that a PITA when I can just use a USB drive caddy to dd a /boot image. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

---- "Trent W. Buck" <trentbuck(a)gmail.com> wrote: Or boot off a liveCD mount your filesystem and chroot into your filesystem to reinstall your grub. I have had to do this more than once, when trying out stupid installers. cheers Robert

"Les Kitchen (LUV)" <ljk+luv(a)ljk.id.au> writes: At that point, just use the built-in btrfs/ZFS equivalent.

On Tue, 29 Apr 2014 20:53:48 Les Kitchen wrote: https://lists.samba.org/archive/rsync/2010-June/025164.html There are patches to rsync to allow this. In the default mode of rsync it creates a temporary file, writes all data to that, and then renames it back. That process breaks the ability of filesystems like BTRFS and ZFS to share data between snapshots and also breaks the copy of the amount of free space in the filesystem is less than the size of the file (think of having 1G of disk space free and wanting to rsync changes to a 5G DVD image). The --inplace option to rsync fixes that. Copying a block device will be much the same as copying a file with --inplace. Yes it's been implemented before for LVM. But as Trent and Criag noted you can just use the send/recv functionality built in to ZFS and BTRFS. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Hi Trent, You edit those files you mention after each backup. I back up at least once a week, but only edit the files I mentioned when I upgrade a system or do a kernel upgrade -- less often. (Been running 10.4 so long haven't upgraded a kernel in a very long time.) Everything after the phrase "The MACs OTOH ..." is beyond my skill set. Cheers, Carl On 23/04/14 10:43, Trent W. Buck wrote:

Quoting Carl Turney (carl(a)boms.com.au): Nor I. I am guessing that the 'sda and sdb changing assignments' occurs in one of a couple of scenarios: 1. At the time of adding or removing drives from an otherwise stable set of fixed main-storage drive devices. 2. When leaving USB-connected drives connected through reboots. USB-connectable drives are handy, but IMO are completely unsuitable for use as main storage. E.g., I attach and detach a USB-connectable external 2TB drive to my server at home, to archive filesets. When done each time, I detach the drive and store it at the far end of my lot, so if the house burns down, the fire can't burn my archive file copies. So, the USB drive is always /dev/sdd, the next drive up from my three SCSI hard drives. Because it's not present during booting, it cannot even in theory grab /dev/sda away from the SCSI ID0 drive. That scenario aside, yeah, if you decide to kludge in a new PATA, or SAS, or SATA, or old-SCSI drive to your existing chains -- or remove one of the drives, your /dev/sdX may shuffle a bit in a fairly predictable way that is essentially a one-time shift. At which time, you make the very obvious adjustment to /etc/fstab, and you're done. To put that another way, adjusting /etc/fstab is just the price of adding or removing physical drives from your main storage. You need to do that even if using UUIDs; all using /dev/sdX adds is the possibility you might need to edit some existing entries on the same one-time basis, too. Also, I know what /dev/sda _is_. Yay, clarity. So, on my system, those UUID lines get banished to ghastly comment lines way at the bottom of /etc/fstab and never used - the replacement lines using /dev/sdX instead. I reserve the right to change my mind if, say, I use Thunderbolt or Firewire devices as main storage and their /dev/sdX names keep changing. In my present use scenario, UUIDs are an ugly solution to a non-existent problem. Your Mileage May Differ.[tm]

Quoting Carl Turney (carl(a)boms.com.au): And I do exactly that. Well, if I've been treading on thin ice, it's been holding since 1983. ;-> (Yes, I really _have_ been running Linux systems since then. Time flies when you're having fun.) I really don't think so. To amplify on what I said about 'I reserve the right to change my mind if...': The same applies if I ever decide to use SD cards or similar things as main storage. (Which might be sufficient proof that I've lost my mind, but that's a different discussion.)

On Tue, 22 Apr 2014 22:22:00 Rick Moen wrote: You haven't been using GRUB nearly that long. Also the development of libata and SATA disks are much more recent. Yes things can work with direct names for the simpler cases. Also for most of the more complex cases you should probably be using hardware RAID (which generally gives a simpler naming that is fixed such as /dev/cciss/c0d0whatever) or a combination of software RAID (that does UUIDs internally) and LVM (with LVM names NOT UUIDs which break with snapshots as previously noted). Probably the best case for UUIDs is when using BTRFS as you have RAID, volume management, and the filesystem all combined. The other good case for UUIDs is having multiple disks that aren't part of RAID arrays, which is fairly common. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Hi Rick, Except back in 1983 it may have been called UNIX, XENIX, SunOS, BSD, or Sys V. You ain't one of them time travellers, are ya? Carl On 23/04/14 15:19, Rick Moen wrote:

On Tue, Apr 22, 2014 at 08:51:53PM -0700, Rick Moen wrote: i've had it happen on kernel upgrades, and even on reboots - a new version of udev or something loaded modules in a different order, so drives got detected in a different order. i also dislike UUIDs because of their ugliness and non- human-readability so my /etc/fstab has a mixture of LABEL and /dev/md* devices - but i understand how the boot process works well enough to have no difficulty just editing /etc/fstab and whatever else is needed to get my system to boot again if there's ever a problem. i expect you're the same. for people without that skill, though, it's better that they just follow the recommended defaults so that they don't cause major problems for themselves. craig -- craig sanders <cas(a)taz.net.au> BOFH excuse #118: the router thinks its a printer.

On Tue, Apr 22, 2014 at 11:52:51PM -0700, Rick Moen wrote: having multiple drive controller technologies - sata and sas, for example - is not at all uncommon. it's also not at all uncommon for motherboards to have multiple different kinds of SATA (or even SAS) ports, requiring different drivers - e.g. sata_mv, sata_nv, ahci. the order that these drivers will load is *not* guaranteed by anything. in fact, it's explicitly NOT guaranteed which is why the advice is to use UUIDs or LABELs rather than device names. load the sata_mv driver before ahci and suddenly your /dev/sda is now /dev/sde or /dev/sdj or something. most people don't have the knowledge or skill to deal with this happening, so it's best for most people to just follow the default of using UUIDs (or LABELs) and avoid the problems that drive re-numbering will cause. to the contrary, they're entirely normal and fairly common scenarios. the fact that you haven't encountered it just means you're lucky, not that your experience is common. craig -- craig sanders <cas(a)taz.net.au> BOFH excuse #362: Plasma conduit breach

On Wed, Apr 23, 2014 at 10:48:08PM -0700, Rick Moen wrote: then you must never have used any AMD CPU motherboards from ASUS or Gigabyte or ASRock etc - almost all of them have SATA ports from the AMD chipset *plus* 2 or 4 more from a Marvell or Nvidia or some other SATA chip, and possibly another 1 or 2 set up as "ESATA" Intel CPU motherboards tend to have less SATA ports built-in, but when they have more then the 4 or so provided by the CPU chipset, then they're also usually provided by Marvell or Nvidia etc SATA chips. craig -- craig sanders <cas(a)taz.net.au>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 24 Apr 2014 03:59:32 PM Trent W. Buck wrote: This Gigabyte board with Intel IVB CPU I've got has a single SATA controller with 6 ports hanging off it, 5 in use (4 HD and one DVD) and one for an eSATA port. 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) cheers, Chris - -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC

Hi All, Maybe you're missing my desired outcome. Maybe I've been using the phrase "master disk" incorrectly. too. Maybe you're all working in a heavily networked environment, with many hard disks on-line to manage simultaneously -- while I'm just a standalone desktop user, running on a single HDD, and never hot swapping. I DON'T want to =uniquely= identify each disk (using UUID, serial number, nor label) during the boot-up process -- but definitely when running the backup script which uses rsync (and then by using the device name (?) e.g. /dev/sda /dev/sdb ). When my "master disk" (the only hard disk I use on a day to day basis, with all my OS, apps, and data on it) faults on me: I want to take a recently backed-up/mirrored disk, physically replace my "master disk" with it, and have it boot up (taking over the role of being my "master disk" from then on). This scheme has been working =perfectly= for me for at least 10 years now (including a fair few "restores" this way). I have no motivation to alter it in any way. I'm only asking LUV-list for assist in editing those boot-up scripts (below) because a couple things seem to have changed in Ubuntu since my current 10.4 version (and I'm using SATA drives for the first time). Maybe a better approach: Could anyone just point me to the specific forum where the Ubuntu boot process contributors focus their attention? Thanks very much, Carl Bayswater = = = = = = O R I G I N A L Q U E S T I O N = = = = = =

Hi Jeremy, Yes, most people should just let UUID do it's thing. I left out the reason "why" in my original post, for the sake of brevity. The answer, below. Still hope someone will answer the question I posed, however. Cheers, Carl = = = = = EXPLANATION FOR MY UNUSUAL DESIRES = = = = = I'm basically a SOHO personal user, single system, with a strong background in the fundamentals of computing. I taught a very wide range of 1st and 2nd year courses at university and technical colleges, and used Linux (when the kernel was 0.96.x and there was no GUI) as a teaching tool. I also worked as a hardware/software techie in the days of CP/M, MSDOS and Windows 3.x. But had a couple of career changes since then. Am now very out of date on the latest IT industry changes, and the details of Linux sysop'ing for most things. (Used to use vi and EMACS, and could type out working shell commands as quick as I thought up the need, but now would be at a total loss with them. Sigh.) Just built up twin 64-bit desktop machines from scratch, and they fired up perfectly, though. UUID makes my own (quick, elegant, thorough, useful, tried & true) backup system fail. I started this system (and benefited from it a few times since then) back before UUID was implemented in Linux. After creating my master disk, I create 2 (or more) backup hard disks (similar partitions, OSs, etc.). Then I use a robust script incorporating rsync at least once a week to ensure each partition on each backup disk is a complete copy of the master disk. Each backup disk is stored in a separate physical location from my home. The beauty of this system is that (when the master disk fails) I slip out the master, slip in a "backup" and turn on my computer. Voila! Up and running (with every single detail the same) in the time it just takes to boot up. UUID (and SELINUX -- is that in Ubuntu nowadays?) thwart that excellent "restore". Explanations for why I use at least two backups, store them in distant locations, don't use "the cloud", don't use RAID, don't use other backup methods, etc. could fill a chapter in a book. (Lots of years supporting lots of small business computer owners has taught me a few things.) Hope that's quenched your curiosity. Hope someone critiques my planned UUID workaround/kludge, soon. Cheers. On 21/04/14 23:54, Jeremy Visser wrote: