on my laptop with opensuse 12.2 and windows7 installed:
I backed up my laptop hard disk using clonezilla and redobackup, without errors, I restored the backup in another disk, everything went well, but grub don’t boot, after this I controlled the partitions with gparted and everything was there, so *(https://forums.opensuse.org/content/128-re-install-grub2-dvd-rescue.html) and now windows boot successfully, but linux opensuse 12.2 not, apart the annoying thing that windows start and linux not, why this:)???
my first flash has been that fstab was wrong becouse it had old /dev/disk/by-id/the_nuber_very_long, so I changed it to /dev/disk/by-label/partition_labels
but I had no success
if I boot in standard way the error is:
can’t evaluate _CRS 12311
doing fast boot
creating device nodes with udev
welcome to emergency mode… give root password for login
if I boot in recovery mode the error are:
many of this… job basic.target/start failed with result “dependency”
many of this
dependency failed. aborted start of login service
…of network manager
…
unexpectedly disconnected from boot status daemon
welcome to emergency mode… give root password for login
I suspect to be at one step to have my spare disc, what can I do to start with opensuse???
tnx ciao P.*
solved, in fstab I forgot and omitted two item in fstab, the ntfs partitions, I put a # before them and everything went smoooothly :), but, why opensuse choose to identify partitions by id ??? instead of by label??, wich is the advantage??, what is the cons to identify partitions by labels??? that in this case if I did this I only had to reinstall grub??
in /boot/grub2/device.map there is a thing like this:
(hd0) /dev/disk/by-id/ata-SAMSUNG_HN-H500MBB_S2RSJ9Eb705578
but my disk is an itachi, how can I get the long number used by opensuse for my itachi disk??
may be that if I change this number in /boot/grub2/device.map, and /boot/grub2/grub.cfg and fstab or use another identifier like label or uuid, before to backup, I will not have to reinstall grub??
[QUOTE=pier_andreit;2526490
may be that if I change this number in /boot/grub2/device.map, and /boot/grub2/grub.cfg and fstab or use another identifier like label or uuid, before to backup, I will not have to reinstall grub??[/QUOTE]
It is better to reinstall bootloader after any changes to disk configuration.
ok, but, does the reinstall of grub2 modify the config files??
becouse in my /boot/grub2/device.map there is still (hd0) /dev/disk/by-id/ata-SAMSUNG_HN-H500MBB_S2RSJ9Eb705578 when my disk now is an itachi
and, is it better to reinstall grub2 from yast2??? perhaps this update the grub2 config files??
grub2-install does not update grub.cfg, it is separate step. grub.cfg is created by grub2-mkconfig.
grub2 itself never updates device.map. Nor does it actually need it. It will use it to map Linux device names to BIOS disk names hdX if this file is available, but as long as you are using grub2-install grub2 does not need or rely upon this mapping. grub2 will always load core.img from boot device and refuse to perform so called “cross-disk” install, so disk names are irrelevant here. And if /boot/grub2 is on different disk, core.img always includes bootstrap code to search for /boot/grub2 location using filesystem UUID.
Where grub2 installation may break is in loading core.img. Initial bootstrap code always contains pointer(s) to absolute disk location(s) of core.img. If core.img is located in partition and this partition is moved or file location is changed (which can easily happen when you copy files between filesystems), grub2 fails to boostrap itself. That is the reason to run grub2-install - to compute possibly changed core.img location. Another possible problem is when grub2 is embedded in post-MBR gap. In this case copying files between filesystem will of course not include it. Again grub2-install puts core.img in its proper place in this case.
Now YaST2 is different matter. For once, YaST2 runs both grub2-install and grub2-mkconfig. OTOH it does use such files as device.map or /etc/default/grub_installdevice and does not automatically refresh them (I intended to open bug report about it but apparently I forgot, at least I cannot find it). This can lead to very interesting failures
So grub2 itself tries to be very conservative. But it does leave you with gun to shoot yourself in the foot. And YaST2 does utilize this gun to full extent
grub2-install does not update grub.cfg, it is separate step. grub.cfg is created by grub2-mkconfig.
well, now in grub.cfg there are wrong issues like the two item:
resume=/dev/disk/by-id/ata-SAMSUNG…
that I would like to change in resume=/dev/disk/by-label/swap
on the top of the file is written do not edit this file…
so I changed it in >yast2>bootloader>options and it seems to works… in /var/boot no errors…
is this ok??
grub2 itself never updates device.map. Nor does it actually need it. It will use it to map Linux device names to BIOS disk names hdX if this file is available, but as long as you are using grub2-install grub2 does not need or rely upon this mapping. grub2 will always load core.img from boot device and refuse to perform so called “cross-disk” install, so disk names are irrelevant here
so I can delete it,… or change the by-id/ata-SAMSUNG… with by-id/ata-HITACHI…
I got the ata-HITACHI… from >yast2>partitioner>settings show the disk by ID, it seems it also seems to works…
So grub2 itself tries to be very conservative. But it does leave you with gun to shoot yourself in the foot. And YaST2 does utilize this gun to full extent
the only hope is in a blank shot gun…
ciao P.*
P