Nifty partitioning scheme for Win7/Linux dual-boot
Hello,
it's been a few years since I last set up a dual-booting system and today I find a lot of tips around the web. I'm somewhat unsure on the strategy I should adopt, so I'm asking you some guidance. I'm working on a ASUS notebook with 500GB HD and 4GB RAM. 100GB or so are reserved for Win7 and OEM recovery partition. I'm planning to use Linux more than Windows and I'd like to have some data to be shared among systems. First there's my e-book collection, which may pose no problem to be shared, but being able to access entire filesystems, via the ntfs driver in linux or the ext2 driver in windows would be cool too. The first question then is: is it best to access ext2 on Windows or NTFS on Linux? Or something else? Then the boot loader. I heard that some windows updates may overwrite the MBR, and so a windows-aware boot loader may be necessary, as suggested here . What's your opinion on this? Do you know other boot managers to suggest? I even found a somewhat dated article where they suggested to have a shared partition in which store the configurations of programs like Firefox and Thunderbird. In this way, their configuration may be transparently accessible by both systems. What do you think about it? TIA H. |
I'd just use a virtual machine. Can't get much safer, easier and still protect W7 and easy to share folders.
I might be tempted to boot to a live usb flash before I went to dual boot. In fact I would. Linux installers have been much better in installing correctly for dual boots. They still fail and people still pick wrong partitions to install to. I'd say backup and understand how to recover your system in Windows. Test it. Then simply follow the installer of the distro. It should work.... maybe. |
Quote:
|
Well, I'm not sure about using virtualization.
I need to write numerical software, and it may end up eating a lot of resources in little time, which depends on the presence of bugs and the maximum size of istances I can solve on the notebook in reasonable time. IMLE,having an additional software layer could slow down things a lot. |
Quote:
So you have the OEM recovery partition (almost never used) in the first cylinders, followed by Win7 which you intend to use less than Linux. If HDD performance matters in your Linux use, you might want to correct that. A Linux GUI partitioning program booted from liveCD or USB memory stick can move the existing OEM and/or Win7 partitions. Usually Win7 can still be used after being moved. I'm not as sure about the OEM recover partition. Quote:
Quote:
2) Expect Windows to someday (but not very often) destroy your Linux MBR. Keep a Linux liveCD or bootable USB stick and know (at least where to find) the instructions for repairing the Linux MBR after Windows trashes it. I didn't dig through the details of that link you posted. But I know there is a valid alternative for dual boot that is basically what they described: Put the Linux boot sector code in the partition boot sector instead of the MBR and then leave Windows in charge of the main boot and set up Windows boot menu to optionally chain load Linux instead of Linux boot menu to optionally chain load Linux. That isn't a terrible choice, but I think it is harder to set up without being less fragile, so it wouldn't be my choice. Quote:
|
"Why would you want to do most of your work in a VM?"
Faster or just as fast, way too easy to copy and reproduce, transportable and offers snapshots and other options that I can't as easy run in a real OS. I can run many VM's at a time if I want to. I can build a systems and deploy it and I can find and run instantly pre-made vm's send to me. Offers an new user a great option that was unavailable many years ago. Hey, I played with bochs a long time ago and paid a lot for virtualPC. Free VM's on supported system simply fly like they would on a real system only easier. I see no downsides. Only positive things. Saves the original OS for times when some windows only app needs to run and I have some. |
All times are GMT -5. The time now is 08:03 PM. |