Lately I am finding that local stores sell 2.5" SSD’s relatively cheaply. I spotted a 240GB SSD for $70. I would like to take this opportunity to load up on multiple Operating systems on secondary SSD.
My laptop can take in an external caddy to hook up secondary SSD/HDD to my CD/DVD slot, and I haven’t used CD/DVD in quite some time.
Here’s what I wish to accomplish.
Out of the 240GB:
Windows 7 64 bit, 150GB (Many Softwares/USB devices in scientific community is somhow linux-unfriendly)
Linux Mint 17.1 64 bit, 30GB, testing (I started out my linux “Adventures” with Linux Mint, I wish to use it occasionally at least)
Archlinux, 30GB, building/learning (I want to go Arch, but I have a lot left to learn, once I am confident with this partition, I will make it main eventually)
Priorities:
a) My main OS OpenSuse 13.2 64 bit KDE in my 1.5" 120GB SSD will be the default and primary boot at all times
b) I wish to on special occasion, boot to other OS’s.
c)The laptop MUST have no problem booting with the secondary SSD (240GB) removed.
Basically, I wish to setup my laptop such that it boots automatically to OpenSuse partition in main SSD at all times.
I wish to have the option to access other OS ONLY when I make special effort during boot.
I have attempted this with Windows7 main with Linux Mint 16 secondary last year and it went horribly wrong. I wish to ask if and or how I can achieve my goal.
Well,
Especially if you want to be able to boot so many different OS,
I’d suggest you first consider virtualization instead of multi-boot. Multi-boot will always be a bit fragile and especially so if you ever want/need to upgrade your BIOS and/or try more dissimilar OS which at the least may require additional chain loading for different OS.
With virtualization, you’d always boot to one chosen main OS, and then can boot to as many other additional OS simultaneously as you have resources on your system (The more RAM and CPU the better) handling whatever you want to do in each running OS. Many things can be done just fine in a paravirtualized Guest (like KVM, VBox, VMware, Xen). Some things might require direct hardware access(like high performance first person shoot gaming) so won’t likely perform well in a Guest.
Your OS will then be portable in case you might want to run on another machine, and various maintenance like upgrades and updates of your main OS are simplified and likely to survive any manufacturer’s release.
Although the study is about 3.5" drives, some of things described can reasonably be extrapolated to any/all drives made by HGST, Seagate and WD. If you use a drive <very> infrequently, for instance only backup archives and is powered and running only for those short times to transfer data, then the study may not be too relevant. On the other hand, if you run your drive(s) harder and longer or store <very> important data that would be extremely painful to lose, then reliability might be more important to you. Keep in mind though that even when a drive <starts> to fail you usually have a couple weeks, maybe even a month to get your data transferred without significant loss (especially if the drive is not close to full). And, you can always run your smartctl utilities which can be found in the standard OSS like any other major distro.
Hello, thank you for the suggestions but I would like the whole OS’s.
I already have Windows 7 32 bit vdi but here’s an issue I bump into:
We have specialized connector for RS-232 to USB and the cable is connected to specialized lab apparatus. The company made Windows machine and LabView specific drivers. The USB doesn’t get recognized by the host OS, therefore, it cannot be connected to guest OS.
As for BIOS update, I did one a few months ago to the latest version. There hasn’t been a new release in 3 years and I doubt there will be another update ever considering my laptop is 2010 release.
Also virtualization eliminates possible incompatibilities (With Linux Mint 17, I experienced zero incompatibilities within the VM with windows 7 host, but as standalone, my touchpad and keyboard were incompatible).
The eventual goal is to build archlinux(god knows how long it’ll take me to figure it out) and be familiar with it enough to make it the primary and only OS other than Windows 7.
If you might want to investigate virtualization options and possible issues, I’d recomend re-posting to the virtualization forum since your issues sound like they could be specific to the type of virtualization you decide to use (and each might support things like direct hardware access differently).
And that is perhaps the first issue you might want to look at.
Personally, I’ve had mixed results using USB<>RS232 devices, they work and sometimes less so and that is without virtualization. Unless you’re running on a laptop or don’t have any PCI slots, I’d <highly> recommend just geting a PCI serial card (cheapest won’t cost more than $15, maybe only half that) for rock solid serial connectivity without worries. You’ll likely get satisfaction with the cheapest card with a UART you can buy, cost is no indication of performance/reliability and may even be worse if it’s supposed to have unusual features.
Of course, if you install a “real” UART device in your machine, there will be configuration and management aspects you’ll need to configure, it’s a thowback to times before PlugNPlay, auto-sensing and auto-configuration. You may even need to find a copy of HyperTerm to run in your Windows (to “see” what’s happening), Linux tools are not so unusual.
Regardless your USB and/or RS232 hardware, all virtualization support direct hardware access, called a number of different ways like “bypass” - The idea is that instead of virtualized serial drivers (in the case of a serial port) you’re configuring direct hardware access for the Guest. This generally means that Guest will have monopolistic access, the Host and any other Guests won’t be able to see the device once it’s been assigned.
BIOS updates will be released “whenever.” Decide for yourself how you want to manage that. Elsewhere in another thread, I mentioned I maintain a “Windows installed directly on hardware” on my laptop because HP releases BIOS updates which can be run only from within Windows. Sure, someone else mentioned you can extract the Update and attempt to run from a command line, but for a procedure that can turn my machine into a doorstop (AFAIK the BIOS chip is soldered to my systemboard) I’d rather not try to explain that to HP Repair if something goes wrong. And, I don’t know if I would do anything that would prevent applying future BIOS updates, usually there’s goodness in them.
You should strongly consider running openSUSE in both Guests and as the Host if you virtualize. Although LTS OS (like Ubuntu and CentOS) exist, I’ve always felt that distros like openSUSE should often be preferred particularly for “foundation” or simple purpose deployments because we receive and integrate new developments and improvements quicker. I’d probably feel differently if the deployment is particularly complex with greater potential for breakage. Things like what you experienced with your touchpad and mouse are very rare in openSUSE (search our forums to verify for yourself, and note the date of any postings). Don’t start with archlinux unless you’re reasonably advanced. Archlinux requires you to have rather advanced knowledge just to create basic functionality. Installing distros like openSUSE leaves you with a reasonable middle of the road “working” configuration you can further customize.
I should probably mention this for the archive. Everything worked out perfectly and nicely, exactly as I wanted.
1.Only W7SSD placed inside main HDDbay and installed. Full installation, update and etc.
2. W7SSD replaced with a fresh OpenSUSE13.2 SSD. Full installation, updated and etc.
3. W7SSD mounted on a caddy
4. Caddy mounted on the the laptop.
Result:
At any time, computer boots to OpenSUSE 13.2, no delay, no pause.
Only if I interrupt the boot, and select it to boot from the drive in the caddy, it loads Windows 7, and everything is good.
With the caddy removed, everything works perfectly on OpenSUSE 13.2.
Caddy can be inserted into any compatible computer, and runs perfectly fine.