Hello, On Nov 5 21:27 Andrei Borzenkov wrote (excerpt):
05.11.2015 21:02, Carlos E. R.:
On 2015-11-05 18:12, Andrei Borzenkov wrote:
There are plenty of dedicated rescue images. What justifies additional efforts spent on creating yet another one? What openSUSE rescue image offers that other long existing ones are lacking? ... I never understood why it had to be created.
What does it offer? Well, the same kernel, and YaST. ... Kernel ... OK, that is valid argument.
The same tool set as the computer under repair. ... That's really too vague. The only truly unique tool is snapper
I do not agree that "The only truly unique tool is snapper". For example SUSE has a specially enhanced parted that can deal with a so called 'gpt_sync_mbr' partitioning. For example SUSE has special systemd/udev rules to get the right kernel modules loaded in the right ordering (at least what is "the right thing" for SUSE) so that for example disk device nodes and network interfaces in the rescue system would be the same as in the original system. For example SUSE has zypper. You can run "zypper -R " to let it operate on a different root directory so that zypper could be useful in a rescue system. For example regarding btrfs I think it is in general better when one uses the SUSE kernel plus the SUSE btrfs tools in a rescue system. For example when using mkfs.btrfs from SUSE it makes a btrfs filesystem with "the right defaults" for SUSE. In general regarding using a different system for rescue tasks compared to the initial installation system have a look at "Deployment via recovery installation" and "The limitation is what the special rear recovery system can do" in https://en.opensuse.org/SDB:Disaster_Recovery Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org