I’ve searched and can’t find precisely what I’m doing, so perhaps someone has a quick answer…
I have a disk, it has Win7 and openSUSE 13.1 with the Windows bootmgr calling to Grub2 on the opensuse partition, which are after the windows partition.
All is good with this install, works great, but I’m out of disk space and want to move the openSuse to another disk.
So, I installed the second disk, Cloned all three partitions (swap/root/home) as they were and then booted rescue and reinstalled grub2, but I can’t get past the grub2 menu to run grub2-mkconfig on the new setup.
I’ve renamed /boot/grub2/grub.cfg and changed /etc/fstab to use device names instead of ids and then get to the grub2 prompt and I am trying to boot from there, and as it’s booting, I see it’s still looking for the original drive and it hangs.
I’m close, but missing something like /etc/fstab with the disk-by-id is being used.
You have to change the fstab entries to reflect the new disk ID
You could use chroot from a runnable CD/DVD to then run grub2-mkconfig
Assuming that you have grub installed in the MBR you would need to reinstall grub, But if you have generic MBR then you need a boot flag. and you can’t boot to the new disk unless you have at least a boot partition on the old drive. Or if you change the BIOS to boot from the new drive you will need to install some sort of MBR code on the new drive.
Its little unclear exactly how your system is setup so it is hard to give exact instructions
> So, I installed the second disk, Cloned all three partitions
> (swap/root/home) as they were and then booted rescue and reinstalled
> grub2, but I can’t get past the grub2 menu to run grub2-mkconfig on the
> new setup.
Another method is to clone the entire disk, byte by byte. The new disk
“thinks” it is smaller, ie, the size of the old disk, but it boots. The
next step is to resize the partitions later.
I don’t know which method is better, though.
Ah, some other thing. Windows will probably detect the hardware change
and refuse to run. If you do “fdisk -l” on the original disk, you will
see a field named “Disk identifier”. You will have to alter that field
on the destination disk, with fdisk, to match, when the original disk is
not active (I’m not sure what happens if the system sees two disks with
the same value).
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Yeah, sorry, all that’s good on the new disk AFAIK, I’ve got the MBR on it and Grub2 is there and it boots to the Grub menu with the original /boot/grub2/grub.cfg. I thought I could then remove (rename) the grub.cfg, boot to the Grub2 prompt, set root, linux and initrd and then boot, get to a terminal and then run grub2-mkconfig and restart and be off and running.
I also changed /etc/fstab to use /dev/sda6 (root) /dev/sda5 (swap) and /dev/sda7 (home) instead of the disk-by-id nomenclature.
So, my disk is (hd0) and the boot is (hd0,6), so at the grub prompt, I type:
set root=(hd0,6)
linux (hd0,6)/boot/vmlinuz-3.12.0-rc5-my_build selinux=0
initrd (hd0,6)/boot/initrd-3.12.0-rc5-my_build
boot
So it goes through what looks to be a boot sequence, then it hangs trying to access the original disk (which is no longer even connected) and there I sit.
Another method is to clone the entire disk, byte by byte. The new disk
“thinks” it is smaller, ie, the size of the old disk, but it boots. The
next step is to resize the partitions later.
I’m actually trying to get rid of windows and on this new disk, just have openSuse.
Ah, some other thing. Windows will probably detect the hardware change
and refuse to run. If you do “fdisk -l” on the original disk, you will
see a field named “Disk identifier”. You will have to alter that field
on the destination disk, with fdisk, to match, when the original disk is
not active (I’m not sure what happens if the system sees two disks with
the same value).
Well, Windows didn’t have a problem at all, still doesn’t if I connect the orig disk. The orig install of openSuse won’t boot at all with the new disk connected, so that appears to be the impact. When I boot the rescue with both connected, it (udev?) adds a “1” to the UUID of the disk, I guess to keep them unique.
I’m thinking I have to change something on the new disk relating to udev, now…
Okay, I got it, turns out it was simple with chroot (thx for the nudge **gogalthorp)
**With just the new drive (sda) connected (already cloned from the old drive openSuse partitions), I booted to the rescue USB stick and from terminal ran:
mkdir /mnt/new
mount /dev/sda6 /mnt/new
mount -t proc none /mnt/new/proc
mount --rbind /sys /mnt/new/sys
mount --rbind /dev /mnt/new/dev
chroot /mnt/new /bin/bash
# Now at the "new" root
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda6
Then rebooted, adjusted BIOS back to boot the new drive and grub came up and it loaded right up.
> I also changed /etc/fstab to use /dev/sda6 (root) /dev/sda5 (swap) and
> /dev/sda7 (home) instead of the disk-by-id nomenclature.
No, please don’t use the sdX nomenclature. It can change from boot to
boot and depending on how many disks you plug.
You have four types to choose from: by-id by-label by-path by-uuid
> I’m actually trying to get rid of windows and on this new disk, just
> have openSuse.
Good for you, if you can
>> Ah, some other thing. Windows will probably detect the hardware change
>> and refuse to run. If you do “fdisk -l” on the original disk, you will
>> see a field named “Disk identifier”. You will have to alter that field
>> on the destination disk, with fdisk, to match, when the original disk is
>> not active (I’m not sure what happens if the system sees two disks with
>> the same value).
>
> Well, Windows didn’t have a problem at all, still doesn’t if I connect
> the orig disk.
And if you don’t?
> The orig install of openSuse won’t boot at all with the
> new disk connected, so that appears to be the impact. When I boot the
> rescue with both connected, it (udev?) adds a “1” to the UUID of the
> disk, I guess to keep them unique.
The uuid is stored inside the partitions, so cloning a partition changes
the uuid. You have to somehow change them on the new disk, which some
tools can do. I think parted does.
Else, you can use id, label (changing them), path…
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
If kernel boots and initrd loads the problem has nothing to do with grub. You need to edit /etc/fstab to reflect you current disk and rebuild initrd to tell it where your root partition now is. You could also try kernel parameter: root=/dev/whatever; for testing /dev/sda6 would be just fine.
Final workflow, this is what I ended up using. It allows you to clone partitions from one disk to another and then with a couple of modifications, boot to the new disk. I choose this approach because my openSuse install was on the same disk (extended partitions) as my Win7 install and I was out of space on the linux partitions (SSD full), so I wanted to move only openSuse to it’s own new drive, make it’s partitions bigger, then reclaim the space on the old drive. I have old machine with just normal BIOS.
Install new drive into computer and set up the partitions as you please. I chose to increase sizes significantly for / and home, but left swap the same. I’m using EXT4 and I set the flag “boot” on the / partition.
Use Clonezilla to copy the partitions from source to target just using “Beginner” mode.
Disconnect old drive, reboot with the Rescue USB stick (openSuse 13.1).
Determine new disk id (/dev/disk/by-id)
…from su terminal
5. mkdir /mnt/new
6. mount /dev/sdxY /mnt/new # where /sdxY is the / for the new disk
7. mount -t proc none /mnt/new/proc
8. mount --rbind /sys /mnt/new/sys
9. mount --rbind /dev /mnt/new/dev
10. chroot /mnt/new /bin/bash
…root should now be the new disk root
11. Modify /etc/fstab to reflect new disk id for home / and swap with new disk-id from above
12. Modify /etc/default/grub to reflect new disk-id in the GRUB_CMDLINE_LINUX_DEFAULT entry
13. grub2-mkconfig -o /boot/grub2/grub.cfg
14. grub2-install /dev/sdx (this installs grub2 to the new disk mbr)
15. exit
16. reboot
…in BIOS, set boot to the new drive if necessary
You should get to the Grub boot menu now and the options should work as before. To check, press “E” and you can double-check the params for the menu entries.
I’ve tried this for both 12.3 and 13.1. If anyone has any thoughts or comments, feel free, I had to piece together quite a few sources to get this working as I desired.
You need also edit /etc/default/grub_installdevice and /boot/grub2/device.map (if exists) and replace old disks with new ones; otherwise standard openSUSE tools will fail to update bootloader. grub_installdevice is where YaST keeps bootloader location.
