Good luck with the restore
Sorry to read this cost you an extra $59.
On both my wife’s PC Windows7, and my mother’s PC Windows7, MS-Windows7 had an option where one could create their own restore disks and not have to spend a cent.
It really surprises me that Lenovo can disable this (if that is indeed the case). …
current update is the disks were sent 1 day air UPS by Lenovo; should have them tomorrow.
Hopefully this weekend I will have the system running. The partition scheme of the disk, as I recall, is about a 423 gig C , and a 29 gig D and a 14 gig E. The DVD is F. The 29 gig partition is a sub partition of a 29 gig extended partition (not sure why this is). The disk is rated 500 gig, but only formats to about 466 NTFS. The D and the E hold the backup MS Win 7 and pre-installed applications.
The Lenovo V470 comes with an app to make a restore/backup disk set which I used two days ago and created the two DVD’s which would read the D,E sections and RESTORE the system, but unfortunately I deleted all that when I tried to do a clean OS 12.1 install, since the installer insisted I had to do this. The only way to get the old system back is the Lenovo restore disks. These will repart the drive and put the data back into C,D,E;
After that I guess I will have to live in an MS world with this system, at least until Linux figures out how to boot these boxes. On a side note, last night in my haze of anger, fatigue, and cognac, I installed Solaris 10 onto it for a lark, and it boots! The only problem with keeping that are the video drivers for X and the wireless drivers; otherwise it was fine. Solaris uses GNOME now.
Not sure why Solaris boots the drive and Linux does not; perhaps someone knows the answer to this mystery.
Currently the drive is wiped clean using my Acronis disk utilities; it awaits the restore disks.
If the installer insists on something you don’t want just go to expert mode. Note because all 4 of the primary partitions are used there is little choice for an automated system. It is best to simply leave free space for the new OS and let the installer partition. but the funny extended partition is the real problem. resizing or removing the one logical in it would give room to dual boot.
I suspect the BIOS is the real problem.
This could be in part openSUSE specific … or saying it differently, I have read of Ubuntu users of different versions failing to install on this Lenovo v470, and read of Ubuntu users of other versions succeeding, in installing their GNU/Linux version on the Lenovo v470. It appears to be a bit of a difficult beast wrt GNU/Linux.
epilogue: up and running on the V470 again - back to OpenSuse in a VM.
epilogue: up and running on the V470 again - back to OpenSuse in a VM.
At least you’re up and running again. Your pain may be helpful to others.
For others who come searching here, this ‘Booting from GPT’ article illuminating:
BIOS-based computers, whether they use MBR or GPT, rely on a boot loader in the first sector of the disk to help get the computer booted. In fact, the first 440 bytes of the MBR data structure are devoted to this boot loader. DOS and Windows place a very simplistic boot loader in this space. Other OSes and third-party utilities enable placing more sophisticated boot loaders in the MBR, although these boot loaders usually rely on multiple stages—the boot loader code loads a secondary boot loader that’s located elsewhere, and that boot loader may even load a third stage. In principle, these boot loaders can work just fine when the MBR is in fact a GPT protective MBR. In practice, the boot loader needs to be GPT-aware in order to work. The GRUB 2 boot loader, when used on a GPT disk, works best when you to have a BIOS Boot Partition (GPT fdisk code EF02) on the disk. Most boot loaders, including the patched versions of GRUB Legacy (version 0.97) that include GPT support, don’t require a BIOS Boot Partition. If you do need it, the BIOS Boot Partition can be quite small—perhaps as small as 32 KiB, although I recommend making it 100-200 KiB, if possible, and if you align your partitions to 1 MiB boundaries, 1 MiB is the logical size.
Old versions of GNU Parted (such as version 1.7.1) tend to wipe out the MBR boot loader from GPT disks. Thus, you should be very cautious about using GNU Parted on a GPT boot disk if your computer is BIOS-based. (Parted’s behavior in this respect shouldn’t affect EFI-based systems.) A retest with GNU Parted 1.9.0 produced no such problem, so it seems to have improved in that respect. More recent versions (up to at least version 2.3), though, wipe out the Legacy BIOS Bootable flag that’s used by SYSLINUX’s GPT loader.
At a convenient opportunity, you might try booting to a liveCD, and if you succeed, then very very VERY carefully, make a backup copy of your MBR with MS-Windows code in the MBR. I say carefully as if you mess up the commands I provided in post #10 above, you will wipe out, instead of backing up, your MBR.