Disabling/bypassing UUID on Ubuntu Trusty
Hi All, Want to disable UUID, and address hardware directly by device and partition specs. Did it on my current system (~ 4 years ago), happy. But see differences in files/contents in Trusty, and want your expert advice, before I start changing things. My knowledge is low. (Barely understand what I'm writing.) Can follow clear simple step-by-step instructions, or grateful for links to same. New system is Gigabyte MB, IntelCore i5 CPU, SATA HDD, dual booting on 64-bit Windoze plus just-released Trusty 64-bit Desktop. Here's what I =would= do... (1) Edit /etc/default/grub to remove the # at the start of line... #GRUB_DISABLE_LINUX_UUID="true" (2) Edit /usr/share/grub/grub-mkconfig_lib to comment out the 3 lines starting... if FS_UUID= (etc.) ... but that line doesn't exist in that file. (3) Edit /etc/fstab and change very instance of UUID= (etc.) into the corresponding drive and partition e.g. /dev/sda2 (4) Edit /etc/initramfs-tools/conf.d/resume and change UUID=RESUME= (etc.) into the corresponding drive and partition e.g. /dev/sda2 (5) Run update-grub (6) Then re-do all the above each time I do a kernel upgrade. So please: Your advice, keeping to my original goal of disabling/bypassing UUID. What am I forgetting? What am I doing wrong? Thanks VERY much, Carl Turney Bayswater, Vic
On 21 Apr 2014, at 17:19, Carl Turney <carl@boms.com.au> wrote:
Want to disable UUID, and address hardware directly by device and partition specs.
Hmm.
My knowledge is low. (Barely understand what I'm writing.)
Hmmmmm. There benefits of UUIDs outweighs the disadvantages for the majority of users. Given your own admission of a lack of knowledge, what makes you sure you want to second guess what is a very sane default made by technically capable decision-makers? You have every right to shoot yourself in the foot, so I won’t stop you, but I’m curious why you want to do so.
Jeremy Visser <jeremy@visser.name> writes:
On 21 Apr 2014, at 17:19, Carl Turney <carl@boms.com.au> wrote:
Want to disable UUID, and address hardware directly by device and partition specs.
Hmm.
My knowledge is low. (Barely understand what I'm writing.)
Hmmmmm.
There benefits of UUIDs outweighs the disadvantages for the majority of users. Given your own admission of a lack of knowledge, what makes you sure you want to second guess what is a very sane default made by technically capable decision-makers?
You have every right to shoot yourself in the foot, so I won’t stop you, but I’m curious why you want to do so.
+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.
On 22/04/14 12:14, Trent W. Buck wrote:
Jeremy Visser <jeremy@visser.name> writes:
On 21 Apr 2014, at 17:19, Carl Turney <carl@boms.com.au> wrote:
Want to disable UUID, and address hardware directly by device and partition specs.
Hmm.
My knowledge is low. (Barely understand what I'm writing.)
Hmmmmm.
There benefits of UUIDs outweighs the disadvantages for the majority of users. Given your own admission of a lack of knowledge, what makes you sure you want to second guess what is a very sane default made by technically capable decision-makers?
You have every right to shoot yourself in the foot, so I won’t stop you, but I’m curious why you want to do so.
+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.
A "*in theory*" that I experienced quite frequently not so long ago, not exactly in the sequence above, but /dev/sda and /dev/sdb frequently interchanged. If UUID are hard to deal with, ie: readability, LABEL may be an alternative. If my memory is right, OpenSUSE uses Labels instead of UUIDs. Daniel.
_______________________________________________ luv-main mailing list A *in theory* that I have experienced quite frequently luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
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:
On 22/04/14 12:14, Trent W. Buck wrote:
Jeremy Visser <jeremy@visser.name> writes:
On 21 Apr 2014, at 17:19, Carl Turney <carl@boms.com.au> wrote:
Want to disable UUID, and address hardware directly by device and partition specs.
Hmm.
My knowledge is low. (Barely understand what I'm writing.)
Hmmmmm.
There benefits of UUIDs outweighs the disadvantages for the majority of users. Given your own admission of a lack of knowledge, what makes you sure you want to second guess what is a very sane default made by technically capable decision-makers?
You have every right to shoot yourself in the foot, so I won’t stop you, but I’m curious why you want to do so.
+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.
A "*in theory*" that I experienced quite frequently not so long ago, not exactly in the sequence above, but /dev/sda and /dev/sdb frequently interchanged.
If UUID are hard to deal with, ie: readability, LABEL may be an alternative. If my memory is right, OpenSUSE uses Labels instead of UUIDs.
Daniel.
_______________________________________________ luv-main mailing list A *in theory* that I have experienced quite frequently luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Tue, 22 Apr 2014 14:03:30 Carl Turney wrote:
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.
With IDE there were usually two cables in a system which were often labeled as "primary" and "secondary" (or similar). Each cable had at most two connections and the devices attached could be jumpered for master/slave or "CS" to determine things by cable position. The scope for getting things wrong was limited, particularly on systems which wouldn't boot from the secondary cable and when drive names were /dev/hda and /dev/hdc based on cabling. When the kernel went to libata for IDE and the drives were named /dev/sda, /dev/sdb, etc sequentially things got a little more complicated. Unplugging the drive which used to be /dev/sdb would rename the device that used to be /dev/sdc and potentially cause problems. With SATA it's even more difficult due to the unclear labeling of motherboards. A motherboard that has 4+ SATA ports with no clear labels showing which is which is fairly common. Mapping between physical ports and /dev/sda etc also isn't clear to me. It could be that the mapping is expected to be constant but my observation doesn't bear that out (maybe I dealt with some motherboards that did the wrong thing - if so such motherboards are common). Then there's the issue of USB CF/SD card readers getting assigned /dev/sdX and making the device for your backup vary depending on whether you plugged your backup device in before turning your monitor on (which happens to me). UUIDs are annoying when you want to do a backup/format/restore on the root filesystem without modifying the boot loader configuration. But apart from that they work well. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
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:
On Tue, 22 Apr 2014 14:03:30 Carl Turney wrote:
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.
With IDE there were usually two cables in a system which were often labeled as "primary" and "secondary" (or similar). Each cable had at most two connections and the devices attached could be jumpered for master/slave or "CS" to determine things by cable position. The scope for getting things wrong was limited, particularly on systems which wouldn't boot from the secondary cable and when drive names were /dev/hda and /dev/hdc based on cabling.
When the kernel went to libata for IDE and the drives were named /dev/sda, /dev/sdb, etc sequentially things got a little more complicated. Unplugging the drive which used to be /dev/sdb would rename the device that used to be /dev/sdc and potentially cause problems.
With SATA it's even more difficult due to the unclear labeling of motherboards. A motherboard that has 4+ SATA ports with no clear labels showing which is which is fairly common. Mapping between physical ports and /dev/sda etc also isn't clear to me. It could be that the mapping is expected to be constant but my observation doesn't bear that out (maybe I dealt with some motherboards that did the wrong thing - if so such motherboards are common). Then there's the issue of USB CF/SD card readers getting assigned /dev/sdX and making the device for your backup vary depending on whether you plugged your backup device in before turning your monitor on (which happens to me).
UUIDs are annoying when you want to do a backup/format/restore on the root filesystem without modifying the boot loader configuration. But apart from that they work well.
On Tue, Apr 22, 2014 at 4:41 PM, Carl Turney <carl@boms.com.au> wrote:
p.s. Still no advice from anyone about the original UUID editing-out that I posted. We're too busy with the meta-picture.
I would take that as a subtle hint that the general consensus is that you should forget about disabling UUIDs and instead put your effort into fixing your backup software to work with them, rather than requiring them to be gone. They're here for a good reason, adapt. cheers, / Brett
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:
On Tue, Apr 22, 2014 at 4:41 PM, Carl Turney <carl@boms.com.au> wrote:
p.s. Still no advice from anyone about the original UUID editing-out that I posted. We're too busy with the meta-picture.
I would take that as a subtle hint that the general consensus is that you should forget about disabling UUIDs and instead put your effort into fixing your backup software to work with them, rather than requiring them to be gone.
They're here for a good reason, adapt.
cheers,
/ Brett
Carl Turney <carl@boms.com.au> writes:
(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
UUID and label are filesystem metadata. File-level cp'ing files will not touch them; Block-level dd'ing the whole filesystem will. You can view them with blkid. You can set ext ones with tune2fs.
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:
Carl Turney <carl@boms.com.au> writes:
(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
UUID and label are filesystem metadata. File-level cp'ing files will not touch them; Block-level dd'ing the whole filesystem will. You can view them with blkid. You can set ext ones with tune2fs.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Wed, Apr 23, 2014 at 11:31:52AM +1000, Carl Turney 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.
no. dd is not an alternative to your current rsync approach (well, pedantically it is but it's a damn stupid alternative to rsync for a job like this). dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
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?
forget about dd, you're making this far more complicated than it needs to be. UUIDs are not the problem you imagine them to be. if your main drive has died and you need to use the backup, then just take a few minutes with a boot CD or USB and modify the /etc/fstab and /boot/grub/grub.cfg so that it has the new filesystems UUIDs. i've done this dozens of times without problem when replacing the boot+os drive on a system with a new larger or faster drive. better yet, modify your backup script so that the last thing it does is to modify the UUIDs in /etc/fstab and in /boot/grub/grub.cfg on the backup disk - a trivial 2 or 3 line 'perl -pi' script will do the job. for example: #! /usr/bin/perl -p -i.bak s/OLDUUID1/NEWUUID1/g s/OLDUUID2/NEWUUID2/g with one 's/old/new/g' line for each fileystem / uuid.
BTW: Can one dd from a filesystem whilst running on that same filesystem?
yes, but you'll have the same potential for corruption on the destination drive as you would if the system was rebooted or powered down with the partitions still mounted (i.e. any unflushed data) in any case, dd is not the answer to your problem. craig -- craig sanders <cas@taz.net.au> BOFH excuse #402: Secretary sent chain letter to all 5000 employees.
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:
On Wed, Apr 23, 2014 at 11:31:52AM +1000, Carl Turney 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.
no. dd is not an alternative to your current rsync approach (well, pedantically it is but it's a damn stupid alternative to rsync for a job like this).
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
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?
forget about dd, you're making this far more complicated than it needs to be. UUIDs are not the problem you imagine them to be.
if your main drive has died and you need to use the backup, then just take a few minutes with a boot CD or USB and modify the /etc/fstab and /boot/grub/grub.cfg so that it has the new filesystems UUIDs. i've done this dozens of times without problem when replacing the boot+os drive on a system with a new larger or faster drive.
better yet, modify your backup script so that the last thing it does is to modify the UUIDs in /etc/fstab and in /boot/grub/grub.cfg on the backup disk - a trivial 2 or 3 line 'perl -pi' script will do the job. for example:
#! /usr/bin/perl -p -i.bak s/OLDUUID1/NEWUUID1/g s/OLDUUID2/NEWUUID2/g
with one 's/old/new/g' line for each fileystem / uuid.
BTW: Can one dd from a filesystem whilst running on that same filesystem?
yes, but you'll have the same potential for corruption on the destination drive as you would if the system was rebooted or powered down with the partitions still mounted (i.e. any unflushed data)
in any case, dd is not the answer to your problem.
craig
On Wed, Apr 23, 2014 at 05:01:18PM +1000, Carl Turney wrote:
Yeah, my style of "restoring" isn't that common an occurrence, so editing the relevant files on the rare occasion would be OK.
BTW, an even better alternative is to just leave both drives in the system, configured as a RAID-1 set. as long as you have grub installed into the MBR of both drives, it would never matter if one drive died, the other would still keep working and you'd be able to boot without any fuss. if/when a drive dies, just replace it and tell mdadm about it and it will automatically sync everything to the the replacement. of course, RAID is not a substitute for backup (it doesn't save you from hasty deletes or disasters like fires) so it would be a good idea to have a third, removable, drive to keep on backing up your system to. craig -- craig sanders <cas@taz.net.au> BOFH excuse #378: Operators killed by year 2000 bug bite.
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, Apr 23, 2014 at 05:01:18PM +1000, Carl Turney wrote:
Yeah, my style of "restoring" isn't that common an occurrence, so editing the relevant files on the rare occasion would be OK.
BTW, an even better alternative is to just leave both drives in the system, configured as a RAID-1 set. as long as you have grub installed into the MBR of both drives, it would never matter if one drive died, the other would still keep working and you'd be able to boot without any fuss.
if/when a drive dies, just replace it and tell mdadm about it and it will automatically sync everything to the the replacement.
of course, RAID is not a substitute for backup (it doesn't save you from hasty deletes or disasters like fires) so it would be a good idea to have a third, removable, drive to keep on backing up your system to.
craig
On Wed, 23 Apr 2014 17:13:10 Craig Sanders wrote:
of course, RAID is not a substitute for backup (it doesn't save you from hasty deletes or disasters like fires) so it would be a good idea to have a third, removable, drive to keep on backing up your system to.
http://etbe.coker.com.au/2013/05/21/no-backups-wtf/ There is a major British corporation that seems to believe otherwise, they appear to have done well in spite of incompetence, they are listed in the FTSE250. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Wed, 23 Apr 2014 05:13:10 PM Craig Sanders wrote:
of course, RAID is not a substitute for backup (it doesn't save you from hasty deletes or disasters like fires) so it would be a good idea to have a third, removable, drive to keep on backing up your system to.
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
Hi All, On 24/04/14 12:22, Chris Samuel 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:
Don't seem so bad. Looks like the PC I'm running right now. Ha ha ha. Carl
On Wed, 23 Apr 2014 16:13:13 Craig Sanders wrote:
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
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/
Russell Coker <russell@coker.com.au> writes:
On Wed, 23 Apr 2014 16:13:13 Craig Sanders wrote:
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
One thing that DD is good for is the boot loader.
You wouldn't need to backup the bootloader if you used syslinux. It's mbr.bin is static and dumb and the same everywhere. The only smarts are in the PBR and ./ldlinux.sys (which is chattr -i on ext, and completely hidden on btrfs). It makes life much easier when a stupid installer hoses the MBR, because instead of booting a live CD and hoping the CD has a similar enough version of grub and then doing grub-install or whatever, you just cat mbr.bin >/dev/sda
---- "Trent W. Buck" <trentbuck@gmail.com> wrote:
Russell Coker <russell@coker.com.au> writes:
On Wed, 23 Apr 2014 16:13:13 Craig Sanders wrote:
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
One thing that DD is good for is the boot loader.
You wouldn't need to backup the bootloader if you used syslinux. It's mbr.bin is static and dumb and the same everywhere. The only smarts are in the PBR and ./ldlinux.sys (which is chattr -i on ext, and completely hidden on btrfs).
It makes life much easier when a stupid installer hoses the MBR, because instead of booting a live CD and hoping the CD has a similar enough version of grub and then doing grub-install or whatever, you just
cat mbr.bin >/dev/sda
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
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Wed, Apr 23, 2014, at 16:13, Craig Sanders wrote:
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
I haven't tried this, but I wonder what would happen if you ran rsync directly on the block devices, rather than on files in the mounted filesystem. There's no reason in principle why rsync's rolling-block algorithm wouldn't work on a block device. Of course, this would require a full read of both devices and then writes of just the changed chunks, so it's not as good as it might seem. But there might be some scenarios in which it could be beneficial -- remote device at the other end of a slow comms link, where the time would be dominated by transfer of blocks down the wire. But building on this idea, you could image a scheme where you keep block-checksums (for some reasonable size of block) for a device, and when the time came, just transfer changed blocks. Of course, this would require cooperation from the driver. You could imagine some sort of virtual device that sits on top of a physical device, but also keeps track of checksums for this sort of incremental device backup -- just like a raid or crypto device sits on top of physical devices, or even LVM. In a way, it's such an obvious idea, that I'd be surprised if it hasn't been tried somewhere already. -- Smiles, Les.
"Les Kitchen (LUV)" <ljk+luv@ljk.id.au> writes:
But building on this idea, you could image a scheme where you keep block-checksums (for some reasonable size of block) for a device, and when the time came, just transfer changed blocks.
At that point, just use the built-in btrfs/ZFS equivalent.
On Tue, Apr 29, 2014 at 08:53:48PM +1000, Les Kitchen (LUV) wrote:
But building on this idea, you could image a scheme where you keep block-checksums (for some reasonable size of block) for a device, and when the time came, just transfer changed blocks.
this is roughly how 'zfs send' (and 'btrfs send') works. in zfs & btrfs, a snapshot is just a list of blocks, so when you do an incremental zfs send, the list of blocks for new-snapshot@localhost are compared to old-snapshote@remotehost and only the blocks that differ need be sent. it's far more efficient even than rsync (because there's no need to compare the data in the blocks between src and dst). craig -- craig sanders <cas@taz.net.au> BOFH excuse #438: sticky bit has come loose
On Tue, 29 Apr 2014 20:53:48 Les Kitchen wrote:
On Wed, Apr 23, 2014, at 16:13, Craig Sanders wrote:
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
I haven't tried this, but I wonder what would happen if you ran rsync directly on the block devices, rather than on files in the mounted filesystem. There's no reason in principle why rsync's rolling-block algorithm wouldn't work on a block device. Of course, this would require a full read of both devices and then writes of just the changed chunks, so it's not as good as it might seem. But there might be some scenarios in which it could be beneficial -- remote device at the other end of a slow comms link, where the time would be dominated by transfer of blocks down the wire.
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.
of incremental device backup -- just like a raid or crypto device sits on top of physical devices, or even LVM.
In a way, it's such an obvious idea, that I'd be surprised if it hasn't been tried somewhere already.
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/
Carl Turney <carl@boms.com.au> writes:
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.
PS: I deal with this by editing the necessary files after each backup. In my case, I'm copying over network, so I can simply have the same UUIDs in both arrays. The MACs OTOH require fiddling: sed --in-place --file=- /srv/backup/root/etc/udev/rules.d/*persistent-net.rules <<-EOF s/00:1b:21:0d:32:8d/00:1b:21:c6:4f:fc/ s/00:1b:21:b6:67:14/00:1b:21:b6:65:98/ s/00:1b:21:b6:67:15/00:1b:21:b6:65:99/ s/00:1b:21:b6:67:16/00:1b:21:b6:65:9a/ s/00:1b:21:b6:67:17/00:1b:21:b6:65:9b/ s/1c:6f:65:c6:47:56/1c:6f:65:c6:47:46/ EOF
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:
Carl Turney <carl@boms.com.au> writes:
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.
PS: I deal with this by editing the necessary files after each backup.
In my case, I'm copying over network, so I can simply have the same UUIDs in both arrays. The MACs OTOH require fiddling:
sed --in-place --file=- /srv/backup/root/etc/udev/rules.d/*persistent-net.rules <<-EOF s/00:1b:21:0d:32:8d/00:1b:21:c6:4f:fc/ s/00:1b:21:b6:67:14/00:1b:21:b6:65:98/ s/00:1b:21:b6:67:15/00:1b:21:b6:65:99/ s/00:1b:21:b6:67:16/00:1b:21:b6:65:9a/ s/00:1b:21:b6:67:17/00:1b:21:b6:65:9b/ s/1c:6f:65:c6:47:56/1c:6f:65:c6:47:46/ EOF
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Carl Turney <carl@boms.com.au> writes:
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.)
Just run it automatically as part of your backup script. sed -i and perl -i both have a command s/foo/bar/ which says "look for regexp foo and replace it with bar". i.e. they're editing a file. As suggested upthread, though, a RAID1 array is the Right Thing for you.
sed --in-place --file=- /srv/backup/root/etc/udev/rules.d/*persistent-net.rules <<-EOF s/00:1b:21:0d:32:8d/00:1b:21:c6:4f:fc/ s/00:1b:21:b6:67:14/00:1b:21:b6:65:98/ s/00:1b:21:b6:67:15/00:1b:21:b6:65:99/ s/00:1b:21:b6:67:16/00:1b:21:b6:65:9a/ s/00:1b:21:b6:67:17/00:1b:21:b6:65:9b/ s/1c:6f:65:c6:47:56/1c:6f:65:c6:47:46/ EOF
Quoting Carl Turney (carl@boms.com.au):
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.
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]
Hi Rick, Sounds like you're doing things similar to what I've been doing and want to continue doing. We also treat USB storage the same way. (Don't think I've =ever= booted up with an external USB drive or USB memstick connected.) You make it sound like you ONLY edit /etc/fstab But when I first got advice on how to edit my boot files (probably from a Linux boot-up contributor, if memory serves) he said I had to edit... /etc/fstab /etc/default/grub /usr/share/grub/grub-mkconfig_lib =and= /etc/initramfs-tools/conf.d/resume (or wherever they were located ~10 years ago). Maybe you've been treading on thin ice and didn't know it? Maybe he was being overly cautious? Maybe things have changed in the intervening years? Cheers, Carl On 23/04/14 13:51, Rick Moen wrote:
Quoting Carl Turney (carl@boms.com.au):
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.
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]
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Quoting Carl Turney (carl@boms.com.au):
Sounds like you're doing things similar to what I've been doing and want to continue doing. We also treat USB storage the same way. (Don't think I've =ever= booted up with an external USB drive or USB memstick connected.)
You make it sound like you ONLY edit /etc/fstab
And I do exactly that.
But when I first got advice on how to edit my boot files (probably from a Linux boot-up contributor, if memory serves) he said I had to edit... /etc/fstab /etc/default/grub /usr/share/grub/grub-mkconfig_lib =and= /etc/initramfs-tools/conf.d/resume (or wherever they were located ~10 years ago).
Maybe you've been treading on thin ice and didn't know it?
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.)
Maybe things have changed in the intervening years?
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.)
I wrote:
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.)
It's late in the time zone where I am, I'm tired after a very long day at work, and I really need to more carefully proofread before I post. The intended reference was to _1993_.
On Tue, 22 Apr 2014 22:22:00 Rick Moen wrote:
I wrote:
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.)
It's late in the time zone where I am, I'm tired after a very long day at work, and I really need to more carefully proofread before I post.
The intended reference was to _1993_.
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/
Quoting Russell Coker (russell@coker.com.au):
You haven't been using GRUB nearly that long.
Quite right. And I've been seriously tempted to give that piece of junk the heave-ho and go back to lilo. (On EFI, there's elilo.) It wasn't broken, and I am annoyed by distros fixing what wasn't broken. (Your mileage may differ.) That being said, I've been an utterly non-enthusiastic user of GRUB since whenever it was that Debian introduced it into d-i or boot-floppies (whichever it was) on the unstable branch. And that's a lot of years, too. Which matter aside, if GRUB somehow dissuades games of device-name Frogger, point for GRUB and your point is unclear. If not, your point is still unclear.
Also the development of libata and SATA disks are much more recent.
Yeah, you may recall I wrote the first real documentation about Linux on SATA, so you could say I did notice it at the time.
Yes things can work with direct names for the simpler cases.
Apparently, all of the reasonable cases are what you call 'simpler'.
Probably the best case for UUIDs is when using BTRFS as you have RAID, volume management, and the filesystem all combined.
Good point.
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:
Quoting Carl Turney (carl@boms.com.au):
Sounds like you're doing things similar to what I've been doing and want to continue doing. We also treat USB storage the same way. (Don't think I've =ever= booted up with an external USB drive or USB memstick connected.)
You make it sound like you ONLY edit /etc/fstab
And I do exactly that.
But when I first got advice on how to edit my boot files (probably from a Linux boot-up contributor, if memory serves) he said I had to edit... /etc/fstab /etc/default/grub /usr/share/grub/grub-mkconfig_lib =and= /etc/initramfs-tools/conf.d/resume (or wherever they were located ~10 years ago).
Maybe you've been treading on thin ice and didn't know it?
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.)
Maybe things have changed in the intervening years?
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.)
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Quoting Carl Turney (carl@boms.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?
It says at the bottom of the front page of my Web site: Contents of this Web site as a whole (as a collection, i.e., compilation copyright), without prejudice to the ownership of individual components, are copyright (C) Rick Moen, 1993-2013. (Need to update that closing year.)
On Tue, Apr 22, 2014 at 08:51:53PM -0700, Rick Moen wrote:
Quoting Carl Turney (carl@boms.com.au):
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.
Nor I.
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@taz.net.au> BOFH excuse #118: the router thinks its a printer.
Quoting Craig Sanders (cas@taz.net.au):
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 can envision that happening if your kernel suddenly changed from old drivers/ide SATA drivers to modern libata one - a one-time changeover that occurred sometime early in the 2.6 kernel series, if I remember what I wrote on http://linuxmafia.com/faq/Hardware/sata.html correctly. I envision that happening if you use multiple, different drive technologies (e.g., PATA and SCSI). I have having a difficult time envisioning it happening otherwise. Your master drive on the first PATA chain will always get the first PATA device assignment, your third SCSI device on a SCSI chain will always get the third SCSI device name allocated to that chain, and so on. In short, I suspect that the applicable scenarios are either very rare or involve hardware practices about which the best overall comment is Don't Do That, Then.
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.
This is a good and valid point.
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.
While recognising that there's a serious cost in lack of simplicity to adopting a method that makes your hardware more difficult to understand and manage, in the name of protecting you from things that are wildly unlikely if you follow elementary good practices in hardware and system management matters. Me, I'd say just keep a live CD around in case of a need to do system maintenance (I like aptosid), know your system, and be prepared to update /etc/fstab in the unlikely event of device names changing - which is highly unlikely to occur except for perfectly obvious reasons that you yourself triggered, e.g., inserting or removing a drive from the middle of a drive chain, or something like that. Or, have it both ways: Keep the UUID rubbish, but move it down to comment lines at the bottom of /etc/fstab, the way I do, and use /dev/sdXX for the functional lines. If you ever have problems, boot that live CD - and you can always swap in the commented-out lines if you can't figure things out otherwise (which I'll bet anyone here can).
On Tue, Apr 22, 2014 at 11:52:51PM -0700, Rick Moen wrote:
Quoting Craig Sanders (cas@taz.net.au):
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 can envision that happening if your kernel suddenly changed from old drivers/ide SATA drivers to modern libata one - a one-time changeover that occurred sometime early in the 2.6 kernel series, if I remember what I wrote on http://linuxmafia.com/faq/Hardware/sata.html correctly. I envision that happening if you use multiple, different drive technologies (e.g., PATA and SCSI).
having multiple drive controller technologies - sata and sas, for example - is not at all uncommon.
I have having a difficult time envisioning it happening otherwise. Your master drive on the first PATA chain will always get the first PATA device assignment, your third SCSI device on a SCSI chain will always get the third SCSI device name allocated to that chain, and so on.
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.
In short, I suspect that the applicable scenarios are either very rare or involve hardware practices about which the best overall comment is Don't Do That, Then.
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@taz.net.au> BOFH excuse #362: Plasma conduit breach
Quoting Craig Sanders (cas@taz.net.au):
having multiple drive controller technologies - sata and sas, for example - is not at all uncommon.
I've already stated my view that this is something to avoid (concerning main storage) if reasonably possible - and also stated that my view applies within the scope of the usage scenarios I've found myself in over the past 21 years of Linux use. I've also said that I think it's a great idea to, at minimum, retain UUID-based lines in one's /etc/fstab as comments in case the information therein is ever needed. I believe that covers the matter.
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.
Haven't encountered that, not even in my many years as sole tester of all proposed new Unix servers, workstations, and laptops for large EDA firm Cadence Design Systems, Inc. If I did start encountering such things on my or other systems, on instance #1 I'd update the /dev/sdX items in fstab and do some very serious checking to see if this was likely to be a problem (the answer to which would doubtless be 'yes' except in edge cases like the transition from drivers/ide to libata for most PATA HBAs in early kernel 2.6, which was a one-time nuisance). The fix if necessary, in that hypothetical, might be UUID usage, but nailing down the module load order might end up being more appealing. In that imaginary scenario, I'd have to think about it.
to the contrary, they're entirely normal and fairly common scenarios.
I don't think that word means what you think it does. ;->
the fact that you haven't encountered it just means you're lucky....
Please teach me how to extend that 21-year streak of unfathomably stupendous luck to other areas of life, Craig. That would be keen of you.
On Wed, Apr 23, 2014 at 10:48:08PM -0700, Rick Moen wrote:
Quoting Craig Sanders (cas@taz.net.au):
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.
Haven't encountered that, not even in my many years as sole tester of all proposed new Unix servers, workstations, and laptops for large EDA firm Cadence Design Systems, Inc.
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@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
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.
All systems I've seen with >4 SATA ports work this way. They have an ICH9 or whatever southbridge with 2 or 4 SATA ports, and then a random crappy sata chipset from promise or whatever for rest.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 24 Apr 2014 03:59:32 PM Trent W. Buck wrote:
All systems I've seen with >4 SATA ports work this way.
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEVAwUBU1siLI1yjaOTJg85AQKiWAf/Tz5m1GclFDz0+9ap49Rg0CtILVhLvBev 6P3s9BexsGDKoRfvamIFyLGnrHgHnEl21fXOkGQ7Vg8BjQUZhrxSqsUwXsb+fztQ 7+XrOHBWd/aOD4y8GNZXd4b+BnmOF0p/oyZ4otUVtdpPkmSKDLh9+jYh8Ys6nopp 5wccXJgR8V40TubTwEBTI86Z6uiA2j40FomCEMn3W2MmJVMeZ4+NBIx0QYgyNDdZ Hrq45+LhwqnE/hczP224mAmNGmUoiKMQR+mc9UfGamLecALfwkIlqTkddb/KqQ75 fHquePgsy325kO3BnTIYd8s5L1zyfcISomMNreZeC74/d2wHsf0N2Q== =sr8x -----END PGP SIGNATURE-----
Daniel Jitnah <djitnah@greenwareit.com.au> writes:
A "*in theory*" that I experienced quite frequently not so long ago, not exactly in the sequence above, but /dev/sda and /dev/sdb frequently interchanged.
I added that caveat because I've never had it trip me up. :-) OTOH I got badly stung under Ubuntu 8.04 where udev would prefer LVM snapshots over snapshot origins for /dev/disk/by-uuid/ symlinks -- so if you rebooted with an LVM snapshot, it would quietly mount the snapshot and keep going. Had an entire apt mirror being maintained in the snapshot... :-/
If UUID are hard to deal with, ie: readability, LABEL may be an alternative. If my memory is right, OpenSUSE uses Labels instead of UUIDs.
+1, this is what I usually do. You can also refer to it by the bus and serial number: $ find /dev/disk -type l -ls /dev/disk/by-uuid/b94873ff-cabe-445a-b0d4-4907bb1d26a7 -> ../../zram0 /dev/disk/by-uuid/c636d1f0-a35e-423c-a7b1-bafe06f6aa58 -> ../../sda /dev/disk/by-label/frey -> ../../sda /dev/disk/by-id/scsi-SATA_KINGSTON_SNS415150026B723B05A525 -> ../../sda /dev/disk/by-id/ata-KINGSTON_SNS4151S316G_50026B723B05A525 -> ../../sda
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 = = = = = =
New system is Gigabyte MB, IntelCore i5 CPU, SATA HDD, dual booting on 64-bit Windoze plus just-released Trusty 64-bit Desktop.
Here's what I =would= do...
(1) Edit /etc/default/grub to remove the # at the start of line... #GRUB_DISABLE_LINUX_UUID="true"
(2) Edit /usr/share/grub/grub-mkconfig_lib to comment out the 3 lines starting... if FS_UUID= (etc.) ... but that line doesn't exist in that file in the Trusty version of Ubuntu.
(3) Edit /etc/fstab and change very instance of UUID= (etc.) into the corresponding drive and partition e.g. /dev/sda2
(4) Edit /etc/initramfs-tools/conf.d/resume and change UUID=RESUME= (etc.) into the corresponding drive and partition e.g. /dev/sda2
(5) Run update-grub
(6) Then re-do all the above each time I do a kernel upgrade.
Hi, Good thing I don't know what "module loading" is, or I'd be worried. My first impression was that the motherboard BIOS settings determine boot-up device sequence, but you're obviously talking about something different -- and potentially relevant for me. Carl On 22/04/14 12:14, Trent W. Buck wrote:
Jeremy Visser <jeremy@visser.name> writes:
On 21 Apr 2014, at 17:19, Carl Turney <carl@boms.com.au> wrote:
Want to disable UUID, and address hardware directly by device and partition specs.
Hmm.
My knowledge is low. (Barely understand what I'm writing.)
Hmmmmm.
There benefits of UUIDs outweighs the disadvantages for the majority of users. Given your own admission of a lack of knowledge, what makes you sure you want to second guess what is a very sane default made by technically capable decision-makers?
You have every right to shoot yourself in the foot, so I won’t stop you, but I’m curious why you want to do so.
+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.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
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:
On 21 Apr 2014, at 17:19, Carl Turney <carl@boms.com.au> wrote:
Want to disable UUID, and address hardware directly by device and partition specs.
Hmm.
My knowledge is low. (Barely understand what I'm writing.)
Hmmmmm.
There benefits of UUIDs outweighs the disadvantages for the majority of users. Given your own admission of a lack of knowledge, what makes you sure you want to second guess what is a very sane default made by technically capable decision-makers?
You have every right to shoot yourself in the foot, so I won’t stop you, but I’m curious why you want to do so.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Carl Turney <carl@boms.com.au> writes:
(and SELINUX -- is that in Ubuntu nowadays?) thwart that excellent "restore".
Ubuntu defaults to apparmor. https://en.wikipedia.org/wiki/AppArmor
participants (11)
-
Brett Pemberton -
Carl Turney -
Chris Samuel -
Craig Sanders -
Daniel Jitnah -
Jeremy Visser -
Les Kitchen (LUV) -
n0b0dy＠bigpond.net.au -
Rick Moen -
Russell Coker -
trentbuck＠gmail.com