Hello. I have a Red Hat -derivative 32-bit Linux Guest physically installed on /dev/sda3 of my laptop (the first two partitions being my Windows 10 host OS) that I run in VirtualBox via raw disk access, and I wanted to replicate this setup on my new Windows 10 desktop PC (where Win10 also occupies the first two disk partitions). The approach I used was to use a partition backup / copy / clone utility suite (two different utility suites, actually, with the same result) to create a sector-by-sector copy of the 3rd partition from the laptop's disk onto the 3rd partition of the desktop PC (temporarily removing the SATA disk from the desktop and connecting it to the laptop as an external USB drive). On the laptop, I have the vmdk that facilitates raw-disk-access to that partition (and only that partition) set to "writethrough", and after repeating on the desktop the same "VBoxManage internalcommands createrawvmdk ...etc" command to create a fresh desktop vmdk to facilitate raw-disk-access to the fresh copy of the Linux Guest /dev/sda3 partition on my desktop's drive, I likewise set the media access type to "writethrough" in the VirtualBox Manager Media Tool (on the desktop, same as on the laptop). On the desktop, from inside VirtualBox I then booted the gparted iso and used it to set the "boot" flag on the fresh /dev/sda3 partition. But my attempts to boot the Linux Guest on my desktop PC from this same /dev/sda3 partition just prints: GRUB on the screen and stops there.
Back before switching from various Windows/Linux dual-boot setups to VirtualBox, when adding the Linux boot option on a new host computer [different Windows versions, different disk configurations] I'd sometimes encounter just: GRUB on the screen, and to the best of my recollection this was always the result of a configuration mismatch in the /boot/grub/grub.conf file (e.g., in how the root partition and/or the boot partition were specified in that config file --- i.e., sometimes my dual-boot setups used a separate hard disk, /dev/sdb , or sometimes different partitions on the "windows" system disk /dev/sda2 or /dev/sda3, etc. ... and different BIOS and/or different disk controllers would require different disk-referencing syntax in grub.conf before the Linux OS would boot successfully). But here I have two Windows 10 hosts, with the Linux Guest OS as /dev/sda3 on both system disks and identical /boot/grub/grub.conf contents, and the laptop's Linux Guest OS boots properly from within VirtualBox while the desktop's Linux Guest OS does not. Inside /boot/grub/grub.conf, the Linux boot partition is referenced by LABEL=/ (i.e., not by any UUID string -- I've tried replacing "LABEL=/" with "/dev/sda3" within grub.conf [and likewise in /etc/fstab ...], but the resulting behavior is the same). On the laptop I've also compared the UUID assigned to the VirtualBox raw-disk-access vmdk file to the UUID reported for /dev/sda3 when I'm inside the Linux Guest OS running on VirtualBox, and these are not the same (on the laptop platform where the VirtualBox Linux Guest OS boots successfully), so based on this I didn't think it would help to try specifying a UUID when creating the raw-disk-access vmdk on the desktop platform.
BUT, there is certainly much I don't understand about the Linux boot process ... consequently at present I'm out of ideas on what else to try to be able to boot my Linux Guest OS from the /dev/sda3 partition using VirtualBox on the desktop. It does seems to me like a [generic] Linux OS booting problem (and thus maybe not necessarily a VirtualBox configuration problem per se), but regardless I'd greatly appreciate any comments / ideas / suggestions. My /boot/grub/grub.conf file is attached (renamed to grubconf.txt), in case that may help. (( Does Linux make use of UUID during boot in some mysterious way that's invisible to a non-expert sysmgr whose grasp only extends as far as the various *.conf files ? )) Comparing the VirtualBox Manager setups on the laptop and desktop side-by-side, all the Linux Guest VM System and Storage settings in VirtualBox are the same (e.g., # of CPUs = 2, Enable PAE/NX checked, SATA type AHCI, Port Count 3, Use Host I/O Cache checked ... but this blanket statement isn't intended to rule out me having overlooked something obvious ...).
Can anyone identify the missing element that I need to address/fix to make the cloned Linux OS /dev/sda3 partition on the desktop PC boot from VirtualBox like it does on my laptop ?
It still seems to me that what I'm trying to do here *should* be possible --- indeed what sold me on VirtualBox raw disk access is that early-on I had a vmdk file that somehow became corrupted ... but because it was configured for "writethrough" to the physical disk partition where my Linux Guest OS was installed, I was able to put that vmdk file aside and return to the "VBoxManage internalcommands createrawvmdk ...etc" step to re-create a new vmdk to facilitate VirtualBox's access to the same physical disk partition where the Linux Guest OS still resided intact, and I was soon back in business. Hence I was expecting to have similar success setting up VirtualBox raw-disk-access from scratch after having replicated the Linux Guest OS physical disk partition sector-by-sector on another computer, but no such luck thus far : - (
Thanks in advance,
-- Jim
Raw disk -based Linux Guest won't boot from partition copied sector-by-sector onto another host PC
-
- Posts: 3
- Joined: 8. Aug 2019, 23:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Scientifc Linux (RHEL) v5.8 32-bit, and rarely Windows XP
- Location: Los Angeles, CA USA
Raw disk -based Linux Guest won't boot from partition copied sector-by-sector onto another host PC
- Attachments
-
- grubconf.txt
- (862 Bytes) Downloaded 11 times
-
- Volunteer
- Posts: 5677
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Raw disk -based Linux Guest won't boot from partition copied sector-by-sector onto another host
Are you sure about that? Because the partition number in "(hd0,2)" is counted from 1, so /dev/sda3 would rather be (hd0,3) ...jkmccarthy wrote:But here I have two Windows 10 hosts, with the Linux Guest OS as /dev/sda3 on both system disks and identical /boot/grub/grub.conf contents
-
- Posts: 3
- Joined: 8. Aug 2019, 23:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Scientifc Linux (RHEL) v5.8 32-bit, and rarely Windows XP
- Location: Los Angeles, CA USA
Re: Raw disk -based Linux Guest won't boot from partition copied sector-by-sector onto another host
Thanks for this suggestion ... first thing I did this morning (of course) was to change all occurrences of (hd0,2) to (hd0,3) and try again, but unfortunately the result was no different. Only then did I turn to Google for help on grub's (hd0,1) partition counting (in true "jump into action first, read directions later" fashion : - ) ...fth0 wrote:Are you sure about that? Because the partition number in "(hd0,2)" is counted from 1, so /dev/sda3 would rather be (hd0,3) ...jkmccarthy wrote:But here I have two Windows 10 hosts, with the Linux Guest OS as /dev/sda3 on both system disks and identical /boot/grub/grub.conf contents
Grub Installation for CentOS 5 and 6
... and according to wiki page above, the partition count for "(hd0,#)" in grub.conf is understood to begin at zero, making (hd0,2) ---what I correctly had originally--- the third partition ... /dev/sda3 or /dev/hda3.
Attached is the VBoxManage report of my desktop's disk layout on \.\\PhysicalDrive0 ... my Linux install is on the 32Gb ext3 partition, which is #3 on the list. I was a bit surprised to see that the first sector of partition 3 is the same as the last sector of partition 2, rather than being equal to the prior partition's last sector plus 1 (as is the case between the last sector of partition 1 and the first sector of partition 2 on the disk). Likely this was my fault when using the Host OS (Windows 10)'s Disk Management tool to "shrink" the Windows C:\ drive down to 40Gb ... is it worth going back to the Disk Management tool again and incrementally shrinking the C:\ drive further (the disk size increments are in Mb) until I see the end of partition 2 move into the previous sector? ((and then deleting partition 3 on the desktop hard drive and repeating my step to clone/copy the Linux Guest raw-disk-access partition from my laptop's drive to my desktop's drive ?))
For comparison, I'm also attaching the VBoxManage report for the laptop's disk layout (from which VirtualBox allows me to boot partition 3 successfully), and I see that here too the second and third partitions appear to stop and start on the same sector, yet on the laptop I have no problem booting the Linux Guest OS with VirtualBox. So this is probably(?) okay, or at least not the source of my original problem ....
Additional comments / ideas / suggestions welcome ... and thanks again fth0 for your reply and suggestion ... there still must be something here I'm missing, since what I'm trying to do *should* work, right ?
-- Jim
- Attachments
-
- Desktop-Drive0-PartitionsList.txt
- (544 Bytes) Downloaded 13 times
-
- Laptop-Drive0-PartitionsList.txt
- (547 Bytes) Downloaded 10 times
Last edited by jkmccarthy on 16. Dec 2020, 10:11, edited 1 time in total.
-
- Volunteer
- Posts: 5677
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Raw disk -based Linux Guest won't boot from partition copied sector-by-sector onto another host
Regarding the partition counting, I didn't notice that we're talking about GRUB Legacy, which is quite different from GRUB2, and that the partition counting was different in those ancient times.
Regarding the CHS values, 1023/254/63 is the maximum value fitting in the MBR partition table, and disks larger than 8 GB (!) use only the LBA values.
What you're maybe missing is where the GRUB boot loader is (not) located (see the Wikipedia article about GNU GRUB for details), especially the so-called Stage 1.5 ...
Regarding the CHS values, 1023/254/63 is the maximum value fitting in the MBR partition table, and disks larger than 8 GB (!) use only the LBA values.
What you're maybe missing is where the GRUB boot loader is (not) located (see the Wikipedia article about GNU GRUB for details), especially the so-called Stage 1.5 ...
-
- Posts: 3
- Joined: 8. Aug 2019, 23:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Scientifc Linux (RHEL) v5.8 32-bit, and rarely Windows XP
- Location: Los Angeles, CA USA
Re: Raw disk -based Linux Guest won't boot from partition copied sector-by-sector onto another host
Perfectly diagnosed, fth0 -- thank you very much!! ... Indeed I had not fully appreciated how the GRUB [Legacy] bootloader works, and my method of copying/cloning the working Linux Guest OS partition from the laptop's hard disk to the desktop's hard disk apparently wasn't capturing all the necessary bootloader stages within or adjacent to the MBR, such as the stage 1.5 you suspected ... I can't be sure. But given this new insight, tried a few things[*] that ended up being dead ends, before grabbing the next incremental version (v5.9) of the installation DVD-ROM for my Linux Guest OS (which was at v5.8 ), and booting the VirtualBox Guest from that, allowing it to minimally "update" my existing install on /dev/sda3 of the desktop computer. It proceeded to update the kernel and a handful of other packages, but most importantly I think, in the process it performed a proper GRUB installation on the disk partition as accessed by VirtualBox ... which I was then able to successfully(!!) boot from the desktop's hard disk partition /dev/sda3 using raw-disk-access. All my existing config files, add-on utilities, and custom software and data were preserved. So in spite of the struggles getting the disk partition copy/clone to boot, for me this was still much better than starting from a fresh install of the Linux Guest OS and then having to install and configure everything else I need.fth0 wrote:What you're maybe missing is where the GRUB boot loader is (not) located (see the Wikipedia article about GNU GRUB for details), especially the so-called Stage 1.5 ...
[*] First I tried the "linux rescue" option from my original (v5.8 ) installation DVD-ROMs, but this failed to load properly. I then took the disk out and attached it to my old workstation still setup to let me dual-boot into Linux, thinking I could chroot to the 3rd partition of the external disk and run grub myself manually, but for reasons I don't understand, when attempting this method grub did not find the /boot/grub partition nor the MBR, even though both were present (albeit incomplete and not booting successfully for me). I can see now why some bloggers (e.g., Whitson Gordon on Lifehacker) might recommend packaging-up a boot iso for the raw-disk-accessed Linux Guest OS to perform the boot and then look to the Linux disk partition for the LABEL=/ filesystem, rather than actually trying to boot from the raw-access disk partition itself (I gather the boot.iso approach also preserves the option to dual-boot the Linux OS directly, but I'm happier being able to work through VirtualBox ...).
Anyway, very many thanks again ... I much appreciated your insights (!!) that pointed me in the right direction, finally ....
-- Jim
.
Formerly --
- Long-time user of Windows/Linux dual-boot setup on desktop PC w/ dual-monitors;
- On the Linux boot, monitors were separate X11 screens, as I need :0.1 to be PseudoColor.
- I run VirtualBox on Windows 7 or 10 Host, with Linux Guest installs using raw disk access;
- VirtualBox Scientific Linux Guest runs X confined to display :0.0 only, on one Windows monitor;
- I run vncserver on Linux Guest to create a virtual PseudoColor display :1 (WUXGA);
- I use TigerVNC viewer on Windows to put Linux PseudoColor display :1 on 2nd Windows monitor.