system backups to bare metal

[PattiMichelle]

Thank you everyone for your help, especially deanno - sure enough, I downloaded the 64-bit version of Clonezilla, redid the sector-by-sector copy, and although it seemed not to finish completely, it boots correctly and I did partition checks with GParted and everything seems fine. All I had to do was update fstab, menu.lst, and device.map with the new drive S/N and it seems to be OK. Kewl!!

[kensch]

On 08/31/12 17:26, PattiMichelle pecked at the keyboard and wrote:
> Well, Clonezilla asked me if I want to copy the bootloader. If you're
> right, it's worse than I thought. I guess mere mortals can no longer do
> this trick (clonezilla backups) any more. Or any backups for that
> matter - it's really about the disk-id thingie. I tried for a couple of
> hours with google to figure out how to "reinstall GRUB." I'm giving up
> and reinstalling OpenSuSE. So far (since 10.0 anyway) that has always
> worked. Fingers crossed!
>
> So I guess it's only useful to back up data now. Is there any disk
> mirror routine that gets around this device issue? What is the
> "traditional" install option so that everything is done in terms of sda,
> etc.? So I can do bare-metal backups easily in the future? There are 4
> or 5 options now.
>
> Thank you very much for the time you've taken to fill me on the status
> of this issue. Have a great weekend.
>
>
Have a look at Microlite BackupEDGE. I have used it successfully in the
past.

[robin_listas]

On 2012-08-31 23:26, PattiMichelle wrote:
> What is the
> "traditional" install option so that everything is done in terms of sda,
> etc.?

No way.

--
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" (Minas Tirith))

[crmrhm]

I had this same problem when I replaced a mechanical hard drive with a solid state drive. This is with a 32-bit processor. A good description of the problem and fix is at TeraByte Unlimited Knowledge Base

I made an image of the HD then restored it to the SSD using Paragon Backup & Recovery 2012 Free. That software requires fixing Grub after the restore, which I did using Swerdna's nifty procedure at HowTo Boot into openSUSE when it won't Boot from the Grub Code on the Hard Drive

That got the Grub menu, and the system would boot into Windows XP, but not OpenSuSE 12.1. It gave an error message related to /dev/disk/by-id. I used partedmagic and Gparted to make some final adjustments to the partitions, then used partedmagic's included file manager and text editor to modify the menu.lst and fstab files as described in the TeraByte article. Success. Everything works on the new drive just like the old.

Yast Partitioner does have a way to change the fstab entries to uuid basis. On the screen to edit the partition, there is a "Fastab Options..." button. Clicking it brings up a window with radio buttons for five mount options, including uuid. I tested that procedure on another machine with 12.1, and it did indeed change the fstab file to uuid entries. For some reason, the uuid option is not available for NTFS or FAT32 partitions.

Somewhere along the line, the device.map file got revised to the new drive ID in a /dev/disk/by-id/ approach. I did not have to change that file manually.

On the machine where Yast changed the fstab entries, I tried to find a way to get it to change menu.lst, but was unsuccessful. The Yast Boot Loader configuration tool showed the menu entries as being uuid based. After finishing Boot Loader, the menu.lst file's timestamp was updated, but the entries remained /dev/disk/by-id. There is likely to be a way to have Yast rewrite menu.lst, but I did not find it.

On future install of OpenSuSE, I'll specify uuid from the start, so images can more easily be restored to new drives when the old ones fail.

Regards,
Howard

[robin_listas]

On 2012-09-03 00:56, crmrhm wrote:
> For some reason, the uuid option is not available for NTFS
> or FAT32 partitions.

Because the UUID is stored inside the partition filesystem, and neither those Windows partitions
have that. You can use label, though.

--
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" (Minas Tirith))

[crmrhm]

[QUOTE=robin_listas;2483395]

Because the UUID is stored inside the partition filesystem, and neither those Windows partitions
have that.

FWIW, if you run the blkid command, UUIDs are returned for NTFS and FAT32 partitions. The Windows UUIDs are quite different in format from the Linux partition UUIDs.

If you manually change fstab to have the NTFS or FAT32 partitions identified by the reported UUIDs, the Yast partition editor shows the UUID option button selected but gray. If you click one of the other options like device ID, it gets selected and you cannot go back to UUID.

With UUIDs for NTFS and FAT32 in fstab, the partitions are mounted correctly and accessible.

Cheers,
Howard

[robin_listas]

On 2012-09-03 07:26, crmrhm wrote:

>> FWIW, if you run the blkid command, UUIDs are returned for NTFS and
>> FAT32 partitions. The Windows UUIDs are quite different in format from
>> the Linux partition UUIDs.

Ah, yes, you are right. I see them in /dev/disk/by-uuid/


>> If you manually change fstab to have the NTFS or FAT32 partitions
>> identified by the reported UUIDs, the Yast partition editor shows the
>> UUID option button selected but gray. If you click one of the other
>> options like device ID, it gets selected and you cannot go back to UUID.

Well, it is a bug in the partitioner. --> Bugzilla ;-)


>> With UUIDs for NTFS and FAT32 in fstab, the partitions are mounted
>> correctly and accessible.

Yes, I just tried myself.

--
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" (Minas Tirith))

[nrickert]

With UUIDs for NTFS and FAT32 in fstab, the partitions are mounted correctly and accessible.

Thanks. I was wondering about that.

[PattiMichelle]

On 2012-08-31 23:26, PattiMichelle wrote:
> What is the
> "traditional" install option so that everything is done in terms of sda,
> etc.?

No way.

--
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" (Minas Tirith))

You know, it seems to me this used to be taken care of in the BIOS. The boot order, or even the order you plugged the drives in. But I can live with editing those three files if it saves problems with other aspects of drives.

...but I'm serious - opensuse needs (1) a bootloader fixer (windoz has one and OS used to) and (2) a "fixer" for those three files. Maybe disk crashes are just so uncommon that nobody cares? My main problem is that I do so many things that each system becomes custom unto itself and I forget how I got it that way (could be senile dementia onset...). So it's not as simple as copying and restoring data or the /home partition.

I'm trying to learn Perl - I wonder if that's something I could write in Perl?

[PattiMichelle]

On 2012-09-03 07:26, crmrhm wrote:
>> If you manually change fstab to have the NTFS or FAT32 partitions
>> identified by the reported UUIDs, the Yast partition editor shows the
>> UUID option button selected but gray. If you click one of the other
>> options like device ID, it gets selected and you cannot go back to UUID.

Well, it is a bug in the partitioner. --> Bugzilla ;-)

I've always been a bug magnet - it keeps me learning