Piecing "Humpty" back together again... Greetings! OK, the given - built a Windows 7/Linux Mint dual-BOOT System using a Legacy-MBR configuration, Windows being first and Linux Mint being added second. Both are currently managed through the Windows BOOT Control Store (BCD) via EasyBCD. The disk configuration is as follows.. Disk 1, Parttion 1 = Windows BOOT partition (C:\, Active, System) Disk 1, Partition 2 = Linux Mint "/" partition (EXT4) Disk 2, Partition 2 = Linux Mint "/home" partition (EXT4) other disks/partitions used in Windows NTFS DATA structures only no Linux SWAP partition The System works as expected... Windows starts as it's supposed to and Linux Mint, when selected at the Windows BOOT menu, appears to enter a Grub2 BOOT loader then on to Linux Mint. I guess this means that Grub is actually in the Linux "/" partition rather than in the MBR and EMBR when Mint is built separately. Keep in mind, I may have built a stand-alone Linux Mint System on Disk 1 before building the dual-BOOT configuration... which probably means the Grub2 loader leftovers from that installation is still sitting around in LBA1-LBA62. Using Macrium REFLECT imaging, The Windows System is only imaging it's BOOT partition ( C:\) and it's MBR, and as a separate task it's managing the Linux Mint System (both partitions from disk #1 & #2) which also is including the Windows-based MBR. Anyway, I wanted to take only that Linux Mint image and restore it to a disk of its own so I did that with REFLECT, placing both partitions back to back on the new disk and making the Linux "/" partition ACTIVE during the process. Knowing that the restored MBR would be Windows rather than Grub (and Windows isn't on this new System), before trying to BOOT the restored Mint System I ran the "BOOT Repair CD," a tool for reconstruction of BOOT paths for Linux Systems. It ran fine, was happy with its results, but the "reconstructed" BOOT paths did not provide a BOOTable System. I then built a stand-alone Mint System from scratch, then used REFLECT to restore those previously imaged Mint partitions but NOT RESTORE the Windows MBR incl. in that image... Grub would now be in the MBR and EMBR, still no successful BOOT. Any ideas on the next step here? Be aware I'm very much a newbie with Linux and Grub2... be gentle
Hmmm... maybe a better way to ask this is if I have my Linux Mint BOOT partition ("/") and a separate "/home" partition both lined up on 1mB partition boundaries of my new disk, and no BOOT loader installed (Grub or otherwise), what is the best way to make this System BOOTable? I do have a Mint LIVE CD and a Boot Repair CD available to work with...
Hi froggie can you post a screenshot or info of your disks/partitions from the live cd? The procedure should be similar with http://www.noobslab.com/2012/10/installrecover-grub-from-linux-live-cd.html http://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd I do not use mint. Does it provide an advanced configuration during setup? Usually Debian, Ubuntu and their derivates never install grub in a volume bootsector unless the user explicitly sets it during the installation (but it is avalaible in the expert mode installation) Panagiotis
Panagiotis, thanks for your interest in this. The System I'm trying to reassemble (2-partiton, BOOT and /home) was imaged by Reflect from a dual BOOT System (2-separate partitions from 2-different disks) and restored by Reflect to a single disk (back to back partitions. Following is the Gparted disk image followed by its information. The info states Gparted cannot read its FileSystem... not sure why not. But that issue doesn't allow me to follow the suggested procedure you posted above (Mount failure).
If this is going to be a single boot system I would advice to move/change the home partition from logical to primary and delete the extended one. As for why it cannot mount the ext4. Do you have the package "e2fsprogs" installed? In the live system from the terminal run the following commands and try to mount it again Code: sudo apt-get update sudo apt-get install e2fsprogs
Then run from the terminal the following commands Code: sudo mount /dev/sda1 /mnt Code: sudo mount --bind /dev /mnt/dev && sudo mount --bind /dev/pts /mnt/dev/pts && sudo mount --bind /proc /mnt/proc && sudo mount --bind /sys /mnt/sys Code: sudo chroot /mnt a. if you want to install grub2 to the mbr run the following Code: grub-install /dev/sda grub-install --recheck /dev/sda update-grub or b. if you want to install grub2 to the boot record of the first volume run Code: grub-install /dev/sda1 grub-install --recheck /dev/sda1 update-grub and in the end run Code: exit && sudo umount /mnt/sys && sudo umount /mnt/proc && sudo umount /mnt/dev/pts && sudo umount /mnt/dev && sudo umount /mnt
You can save the Grub boot sector from either the MBR or partition boot sector with the dd command. Almost all of my computers boot Windows and at least one version of Linix After grub is installed, I do the following command. The example uses sda2 as the partition where Grub is installed and the file is saved to the home directory of a user named user with the name lin.bsc. Code: sudo dd if=/dev/sda2 of=/home/user/lin.bsc bs=512 count=1 If I install it to the MBR, I first preserve the Windows MBR with Code: dd if=/dev/sda of=/home/user/win.mbr bs=512 count=1 Then I install Grub to the MBR and save the MBR with the same command with the output file named something like lin.mbr or ubt.mbr or deb.mbr. Then I restore the Windows MBR by reversing the dd command. Code: dd if=/home/user/win.mbr of=/dev/sda bs=512 count=1 Once you have a boot sector or MBR image that correctly references the Linux partition, you can add it to the Windows BCD boot menu and boot it. I use Bootice to edit the BCD. EasyBCD would work as well. Bootice can also do the MBR/Bootsector imaging but I've been doing the dd command long enough that it is second nature. Newer versions of Grub don't like being installed in partition boot sectors and you will probably have to use the -force option to install Grub in a boot sector.
OK, this time I took a forensic image (all partition sectors) of each partition. Did a SECURE ERASE on the SSD I'm installing to. Restored the images as adjacent partitions (both being set as PRIMARY), then tried to MOUNT the 1st partition. "e2fsprogs" was already installed in the LIVE CD I used (Mint). Results are below...
It seems that macrium has messed up the UUID (=GUID in unix systems). I have never seen a GUID c2da67d6-0f7f-4528-aaed-03c852d7c1fc. Do you have the original disk. Can you compare the ids?
For unbootable Linux partitions, try supergrub. https://www.supergrubdisk.org/ It can boot almost any Linux system partition that isn't corrupted. It can do advanced boot options and load different kernels if it finds them. It is my tool of choice when I migrate to a new disk and need to boot the Linux partition to reinstall grub. I'm not a Macrium user so I don't know how good it is with non windows partitions. I usually have to use the sector by sector option to clone Linux partitions with Windows partitioning software. I use Gparted for any resizing and manipulation of Linux partitions. Aomei can image them and automatically selects the sector by sector option but it can't resize them.
Macrium REFLECT claims it is fully EXT4 aware... I have my doubts as recently I discovered an imaging anomaly where imaging "used sectors" was imaging way more than the actual sectors in use. This has recently been fixed by Macrium... but I think there's more. As I mentioned previously, a forensic Reflect image didn't help above either. Since my last post, I decided to use "Image For Windows" (also EXT4 aware) to do a used sector image of the 2-partitions in question. Upon restore of those partitions in the geometry I wished to use, all went well and the partitions are just fine per Gparted... no anomalies. I'm now gonna set up Grub2, via Mint LIVE, to enable a fully BOOTable (hopefully) standalone Linux Mint System. Edit: Grub setup just fine per Panagiotis instructions (@pandlouk ), all now BOOTs as a standalone Linux Mint System. I wanna thank Panagiotis and @MisterB for all their help with this. I guess I'm fast becoming a bit of a Linux freak here... with all your help, of course. I'll be back in Macrium's lap shortly over this issue... it's usually not very much fun
Panagiotis (@pandlouk ), I compared them and the UUID of the original BOOT partition created by the Linux Mint build in the dual-BOOT System is exactly the same as the one above in the Gparted properties of the restored Macrium Reflect partition... yea, I know, it looks pretty weird.
@pandlouk , @MisterB - what would be the advantage, if any, to installing/running Grub in the Partition BOOT Record rather than the disk's Master BOOT Record? And if running it out of the PBR, what kind of MBR would be used to access it? Just trying to gain a little insight here...
If you install it to the partition boot record, you can set the partition active and switch from Grub to the Windows boot loader by switching the active partition. It would be a Windows MBR accessing it. If it was a grub MBR, installing Grub to the PBR would not be necessary. The boot sequence would bypass it and load the kernel directly.
In addition to what MisterB said. Advantages for multiboot configurations: - each Os has its own boot loader (Windows with MS bootloader, Ubuntu with grub, Debian with lilo, etc. and it also works for logical partitions) - you can chainload various boot loaders - but the biggest advantage is what you have encountered. You image the partition, move it in another drive, set it as active and you are ready to go. It avoids you the mess of reinstalling/updating the bootloader configuration... Advantages for single Os configuration: - none that I can think of Panagiotis
Hi Longboard, ...maybe there is one, somewhere... without meaning that one way is better from the other. On my systems sigle-boot or multi-boot I always install it in pbr. But when I perform installations on system for customers and friends I install it in the mbr.
When installing Linux in UEFI mode ("Something else" choice) does "Device for boot loader installation" have any meaning as you can choose /dev/sda, the Linux partition or the ESP and the boot loader only goes to the ESP. I guess that's how UEFI works.
Which distro? It should have a meaning. If you choose /dev/sda it should put the bootloader on the ESP of the drive. Same if you choose ESP. But if you choose Linux partition the bootloader should be installed in the root partition and not in the ESP. edit: Debian, Ubuntu and their derivates if I am not mistaken use the following installation: /dev/sda = normal esp installation ESP = normal esp installation Linux partition = removable/fallback bootloader installation on ESP/EFI/BOOT/bootx64.efi If you choose the linux partition installation and then move the bootloader from "ESP/EFI/BOOT/bootx64.efi" to the root partition in "/EFI/BOOT/bootx64.efi" then depending on the system efi/bios, the grub bootloader won't be selected as a boot option during boot, but the linux partition should be presented as a removable boot option when you press F2 or F10 or F12 (boot from other devices option)
Panagiotis, Mint Cinnamon 18.3 (root and swap partitions). I just installed it again along with Win10. Chose boot loader to go to the Mint partition. When I restart the computer I see a Grub menu. In EasyUEFI the file path is \EFI\Ubuntu\grubx64.efi Using TBExplorer, the EFI folder contains an ubuntu folder containing grubx64.efi and grub.cfg There is also an empty fw folder Edit... Just saw your added paragraphs.
Brian don't know if it is how it's supposed to work or if it is a bug or if it's just a option that should not be invoked when installing in gpt disks. The only advice I can give if you want to make custom grub2 installations is to read the arch wiki https://wiki.archlinux.org/index.php/GRUB
Panagiotis, Thanks for the help. I moved grubx64.efi and grub.cfg into the \EFI\Boot folder. Restarted and there was no Grub menu. Win10 booted. In the Firmware Boot Menu there were no entries to boot the Mint partition. I'm not concerned. It was just something of interest.
No, I didn't. I had a look in the Boot folder and there is already a bootx64.efi file, in addition to the Grub files. No problem as I'm almost ready to restore the Win10 Entire Drive image.
