Install to machine with UEFI -- dual boot Win7-- Do I dare?

[please_try_again]

On 2012-01-24 07:36, please try again wrote:

> But @oldcpu, why not saving the partition table (in the following
> bytes)?

Because they change. The original windows mbr does not, unless you
overwrite it with grub or yast version of generic boot code.

But that's exactly the point! You 're going to back up what is going to change (and possibly get screwed up), not what is NOT going to change, hence my question.
I can understand why you would only save the bootcode - if you want to modify the partition table and restore the bootcode (which as you noticed is not going to change unless you overwrite it).
But if something has to be backed up and you want to be able to restart Windows (or something else) if something goes wrong while repartitioning (it happens), that would be the partition table. Otherwise if could be over ... or at least not fun to repare (I'm not kidding).

So this is the command to do it:

dd if=/dev/sda of=mbr-backup-windows7-512 bs=512 count=1

Or you could save only the partition table (but why would you?). Actually this command:

dd if=/dev/sda of=ptable-backup-windows7 bs=1 skip=446 count=64

is more useful than this one:

dd if=/dev/sda of=mbr-backup-windows7-440 bs=440 count=1

or at least might help you restore Windows. The first 440 bytes of the MBR won't and those are easy to rewrite with fixmbr (or whatever it is called under WIndows 7. I know it's not fixmbr). On the other hand, repairing the partition table when you don't know how it originally looked like is much more tricky, and the majority of users won't do it and just reinstall. I always recommend users to make a hard print of their partition table. It can save you a lot of time and trouble.

[adomeij]

please_try_again,

<-- Snip -->

Exactly.

<-- Snip -->

Absolutely.


Short, concise and to the point, what a lovely answer!
/Anders

[robin_listas]

On 2012-01-24 14:26, please try again wrote:
>
> robin_listas;2433549 Wrote:


> But that's exactly the point! You 're going to back up what is going to
> change (and possibly get screwed up), not what is NOT going to change,
> hence my question.

There is no interest in backing the partition table, just the booting code.
The partition table is best to restore using fdisk or similar, so that it
agrees with the current partitions at the time.

Alternatively, you can save both, but once you create a partition for linux
or reduce the size of windows, it is useless.


> or at least might help you restore Windows. The first 440 bytes of the
> MBR won't and those are easy to rewrite with fixmbr (or whatever it is
> called under WIndows 7. I know it's not fixmbr).

Provided you can boot Windows or have a rescue disk. Mine does not bring a
install disk, just a rescue partition that wipes it all.

> and just reinstall. I always recommend users to make a hard print of
> their partition table. It can save you a lot of time and trouble.

me too.

--
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)

[oldcpu]

Actually this command:

dd if=/dev/sda of=ptable-backup-windows7 bs=1 skip=446 count=64

is more useful than this one:

dd if=/dev/sda of=mbr-backup-windows7-440 bs=440 count=1

I do not believe that correct.

Just the contrary.

Please read this big report: https://bugzilla.novell.com/show_bug.cgi?id=396444#c61

If one adopts 446 with count=1 (I have no idea about count =64 but I suspect the same problem) like you suggest they will break vista and possibly windows7.

Note post61 there:

Yep, that's it. I can reproducibly break Vista by changing the mbr signature.
(4 bytes at 0x1b8 [=440]). We should really be more careful here as we,
too, are relying on it (to assign disk drives to BIOS ids - probably Vista
does the same).

So, in short: don't write 446 bytes of mbr boot loader code but only 440.

so with count=1 the value of 446 is not correct. It is 440.

I would be very suspicious that count=64 with 446 will also break Vista and possibly windows7. Please again read the bug report I quoted.

[please_try_again]

I do not believe that correct.

You can believe me. maybe not about everything though.

Just the contrary.

Yes, the contrary. What you mean is not the contrary.

Please read this big report: https://bugzilla.novell.com/show_bug.cgi?id=396444#c61

This is interesting! I will read these 4 bytes and display this info in findgrub. It will be an easy check (once you know where to look)

Yep, that's it. I can reproducibly break Vista by changing the mbr signature. (4 bytes at 0x1b8 [=440]). We should really be more careful here as we, too, are relying on it (to assign disk drives to BIOS ids - probably Vista does the same). So, in short: don't write 446 bytes of mbr boot loader code but only 440.

I don't write 446 bytes. I skip 446 bytes. I save the next 64 bytes.

dd if=/dev/sda of=ptable.sda  skip=446 bs=1 count=64

If one adopts 446 with count=1 (I have no idea about count =64 but I suspect the same problem) like you suggest they will break vista and possibly windows7.

64 = 4 x 16 => 4 16 bytes entries, one for each primary partition (the extended partition is just a primary for the MBR).

You copy the first 440 bytes. I copy the last 64 bytes (actually not the two last ones).
None of the two commands include the MBR signature. Copying these 64 bytes back at the same place won't break any OS (at least not because of the MBR).

[oldcpu]

I don't write 446 bytes. I skip 446 bytes. I save the next 64 bytes.

dd if=/dev/sda of=ptable.sda  skip=446 bs=1 count=64

Indeed, I missed the 'skip'.

This is all above my 'head' wrt what is where in the MBR. So I'll be taking notes on any information that I can 'glean' here from this thread.

I do note that I have successfully used

dd if=/dev/sda of=mbr-backup-windows7-440 bs=440 count=1

to backup a Windows7 MBR a few times, so I know it works and it works well (for me).

[oldcpu]

I do note that I have successfully used

dd if=/dev/sda of=mbr-backup-windows7-440 bs=440 count=1

to backup a Windows7 MBR a few times, so I know it works and it works well (for me).

I guess I should add I restored the 'MS-Windows' MBR with the backup file 'mbr-backup-windows7-440' by re-inserting the USB stick (when doing a GNU/Linux liveCD boot) and backing up from a terminal with:

dd if=mbr-backup-windows7-440 of=/dev/sda bs=440 count=1

... and needless to say, its important to NOT get the 'of' mixed up with the 'if' as that will totally break one's MBR.

[please_try_again]

I wonder where the wrong signature comes from though. Actually If you copy Vista or Windows 7 "original" MBR or 446 bytes (including the signature), it should not break itself. The offending signature has to come from somewhere else, either be different in openSUSE generic MBR or remains from and older Grub in MBR.

[oldcpu]

I wonder where the wrong signature comes from though. Actually If you copy Vista or Windows 7 "original" MBR or 446 bytes (including the signature), it should not break itself. The offending signature has to come from somewhere else, either be different in openSUSE generic MBR or remains from and older Grub in MBR.

That's also my thinking.

I believe a plausible scenario is:
(1) one has windowsXP installed
(2) one installs openSUSE and puts a generic grub on the MBR ?? (and then backups the MBR with the 'bs=446'). WindowsXP still boots fine.
(3) one installs windows7 (which boots fine but clobbers grub)
(4) one restores the MBR with the 'bs=446' which somehow breaks the windows7 boot ?

That's a LOT of speculation on my part not knowing what goes where in the MBR.

I think if one avoids putting a generic Linux boot on the MBR (and leave windows7 on the MBR) one should be fine. I know your views on that, and I am in your 'camp' having followed your views successfully.

[please_try_again]

That's also my thinking.

I believe a plausible scenario is:
(1) one has windowsXP installed
(2) one installs openSUSE and puts a generic grub on the MBR ?? (and then backups the MBR with the 'bs=446'). WindowsXP still boots fine.
(3) one installs windows7 (which boots fine but clobbers grub)
(4) one restores the MBR with the 'bs=446' which somehow breaks the windows7 boot ?

Yes. It has to be something like that. It's easy to fix. Once you know the signature, you can dd it back to the MBR (you would use seek=440 in this way).

I think if one avoids putting a generic Linux boot on the MBR (and leave windows7 on the MBR) one should be fine. I know your views on that, and I am in your 'camp' having followed your views successfully.

Until today, I thought it had at least one advantage and I was about to test it (maybe I will) on a Windows 7 machine, on which I can not install service pack 1 (because it has and old Ubuntu's Grub in MBR right now). It's a Genuine Windows but it's a small Aspire Revo (they were just cute and cheap 3 years ago - I installed a small Linux web server on it but I never really used it). So I thought I would just install openSUSE, let it write its generic MBR (exceptionally ) and see if I can install Windows service pack 1 afterwards. But if it cannot even do that, this default has really no advantage. I have to try that. Well, once I have a generic MBR, if it doesn't work, I can still write the signature at byte 440-446. Maybe I'll ask someone to post it.

hexdump -v -s 440 -n 6 -e '"%x"' /dev/sda

or

dd if=/dev/sda skip=440 bs=1 count=6 2> /dev/null | od -x