0

I have this problem (well larger but it can be stripped down to this) - headless machine far, far away, with two discs

/dev/sda is "working disc" with a lot of partitions, mainly

/dev/sda1 .. /boot
/dev/sda2 .. /
/dev/sdax .. something other

installed with grub 0.97 the clasiccal gentoo way (boot from CD, chroot, install everything, run grub type root (hd0,0) and setup (hd0) and it works)

/dev/sdb is "backup disc" with similar partition scheme, but different size and partition sizes

/dev/sdb1 .. /boot
/dev/sdb2 .. /
/dev/sdbx .. something other

added much later as free disk for "data backups", later it was desided, that it should be rather "reserve system", so some kind of synchronisation process was established, which mounts sdB partitions, picks up files from sdA, rearrange them to new patritition scheme (compressing something, ommiting something else, adding extra backups etc, etc), then again unmount sdB.

At that point the sdB is good enough copy of sdA, that if sdA crashes, the sdB should have all files needed to be able take its work and start be new sdA. All needed to do that is that somebody stop the machine, detach physically old sdA, while leaving sdB intact and reboot the machine. But that dic never was prepared to be bootable, grub was not installed there, just copied as buch of other files. So it would not run grub on start. It would not boot. It is only data disc, rewriten with zeroes, then partitioned, formated and filled with files.

As even booting paramaters are sometime changed on sdA /boot/grub/grub.conf, new kernel may be used etc etc, the content of sda1 partition is also backuped to sdB. The /etc/fstab is written, that it would work on either disc (if it is marked as sdA by system)

My question is - how make the second disc bootable too now, from far, far away with just ssh access to the machine.

I think that it would be something simple, like running grub, typing root (h1,1) and setup (hd1) and quit or so, but I am not sure, how to express, that I am installing it on sdB (or hd1 for grub), but when it would be booted, the only disc in the computer will be the "backup disc", so it will be sda (hd0) then and it should boot from files on itself.

But I have just one try and nobody with technical knowledge, console or keyboard on the other side, just simple man with screwdriver instructed "in case o problem just switch off this machine, pull out disc marked WORKING DISC, do not touch disc marked BACKUP DATA and switch the machine on" (I can rely on that done correctly, but that is all) and it must work.

Status now (and it boots all from sda): 

sda          # work disc
   sda1 /boot 
   sda2 /

sdb          # backup disc (unmounted)
   sdb1 /boot
   sdb2 /

New status wanted (and it should boot all from new sda): 

# work disc (not present at all)
sda          # backup disc (mounted and single in computer)
   sda1 /boot
   sda2 /

Thanks in advance. (Yes, I went to that too late, but it is the situation now and it should be solved fast)

4
  • So sdB has a copy of the operating system too? Are you concerned that the data on sdA becoming corrupt or the disk failing?
    – jc__
    Aug 18, 2017 at 15:04
  • If the OS is copied or cloned from sdA to sdB, wouldn't the OS get lost if booted from sdB because of UUIDs for the partitions would be of sdA and not sdB.
    – jc__
    Aug 18, 2017 at 15:10
  • Using something like grub-install --boot-directory=/mnt/sdbOS/boot /dev/sdb may help. Dont forget to grub-mkimage for sdB. That should install the boot sector to sdB and "point" it to the grub.cfg on sdb1. Please check the switches for correct locations before executing.
    – jc__
    Aug 18, 2017 at 15:23
  • Last time the problem was that the sdA just stopped working. Data on sdB are (a day) older copy of sdA, so there is good chance, that it will be still OK. UUIDs are not problem, as the fstab uses simple /dev/sda1, no LABEL nor UUID. There is no grub-mkimage anywhere. The grub is legacy or 0.97, not grub2
    – gilhad
    Aug 19, 2017 at 0:55

1 Answer 1

Reset to default
0

I'd suggest you to buy a third disk /dev/sdc...

Make it has the exact same partition table that /dev/sda and install grub2, then send the data to your new /dev/sdc/ disk, see how does the system react with grub2 and if everything is ok, then you'll have your new "emergency system" available and a "data recovery" disk.

The biggest problem that I can notice with your approach is the:

(compressing something, omitting something else, adding extra backups etc, etc)

you can't spect to have a fully runnable system if there is some kind of omission. And that could be more dangerous than having all your hopes in a "data recovery" disk.

I believe this is the fastest way to solve your problem, as you said that was your biggest concern.

2
  • The biggest problem is the distance, where I cannot simply go there and do something. More over grub2 is not good choise for continual backuping system with grub 0.97 because of different config files. (And even if grub2 can manage things that grub 0.97 cannot, there is no reson to install it where grub 0.97 works flawlessly. On the other hand compressing old log files, deleting temporary files, that are regenerated on demand (and then never deleted, as space is not concern there) and not backuping known 'inactive test users' does not make a problem. The system would work perfectly.
    – gilhad
    Aug 19, 2017 at 23:55
  • well, keep the grub legacy then... now, even if the person that helps you is only capable of removing the drives, you should be able to install and make the chroot in a bare new gentoo through SSH... the idea is, you should not have a backup as a "rescue system", the backup is just that, files tha you consider important to keep safe, but that is not a whole system... if you want to have a "rescue system" then you need a copy from your actual system
    – Christopher Díaz Riveros
    Aug 20, 2017 at 3:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .