Recovering UEFI boot entries after clear CMOS

How do you do that easily? Must I always keep a recovery disc ready? If
so, wouldn't it make things more complex than MBR boot?

The old MBR method can always boot even after a CMOS reset.

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

On Tue, 25 Apr 2017 18:20:07 +0800, "Mr. Man-wai Chang"
wrote:


How do you do that easily? Must I always keep a recovery disc ready? If
so, wouldn't it make things more complex than MBR boot?

The old MBR method can always boot even after a CMOS reset.

The old would boot if the hardware is installed for its defaults (for
instance it might not default to Boot from USB or Boot from RAID).

I've never used UEFI, although a recent budget MB I've been looking
at, (neither entirely sure it would be a UEFI board, for that matter,
per se), has two physically chipped and redundant BIOS sets. Which
begs the question whether a changed BIOS set on one can be copied to
the other for the event of a failure, then and if provided for
overriding default settings should the first fault in error.
(Logically it doesn't quite make sense to me without pin-MB jumpers
for "hardwiring" the condition.)

On 25/4/2017 10:59 PM, Flasherly wrote:
I've never used UEFI, although a recent budget MB I've been looking
at, (neither entirely sure it would be a UEFI board, for that matter,
per se), has two physically chipped and redundant BIOS sets. Which
begs the question whether a changed BIOS set on one can be copied to
the other for the event of a failure, then and if provided for
overriding default settings should the first fault in error.
(Logically it doesn't quite make sense to me without pin-MB jumpers
for "hardwiring" the condition.)

You got time to do a simple experiment? Just disable CSM and Secured
Boot, install Windows 10 via UEFI and GPT partitions, reboot, power off
PC, clear CMOS, then power it up!

My bet: it would no longer boots the Windows like MBR scheme.

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

On Tue, 25 Apr 2017 23:37:18 +0800, "Mr. Man-wai Chang"
wrote:

You got time to do a simple experiment? Just disable CSM and Secured
Boot, install Windows 10 via UEFI and GPT partitions, reboot, power off
PC, clear CMOS, then power it up!

My bet: it would no longer boots the Windows like MBR scheme.

I didn't say, but it was in the back of mind when I wrote that: I'll
just bet Manwai Chang is screwing with Windows 10!

Thanks all the same, but I just about had my fill of cat-scratching
hair-pulling, when removing all my (other) harddrives to install
Windows 7 64-bit, then reinstalling them, so to arrange for a Legacy
MB Boot off the hard drive of my choice, not Windows 7, as first
determined and defined from a (*nix-rooted variant and freeware)
software OS Boot Arbitrator.

No help, of course, that the MB, though a Legacy board that's quite
old for still a most splendid one, wouldn't necessarily lend to take
(along with some dated software I'd also have attempted to consort) in
migrating to SSDs at the time then as part of the Windows 7 install.

You're quite out of league, altogether, with your updated UEFI MB;- in
fact I'm thinking of pulling that Windows 7 64-bit install for the
same 32-bit release. Willingly to give up, of course concede certain
hardware concessions...USB3, memory limits, structurally PCI-slotted
solid state storage memory that's approaching speeds for being
incorporated into a shared system memory resource architecture;-
tentatively an immediate present, a limit within 2T hard drives,
(although a larger GPT scheme should also be readily available to me,
at a minimum of W7 32bit);- rather tempting to think in 2T capacities
with SSDs only, as prices may sooner be indicative, or to stop
buying mechanical drives altogether.

Depends on where -- on that line of hardware advancements,
traditionally exceeding any industrial or individual motive, as of
late I'm to defer, where we're to play along and catch up with
appropriately demanding software and resources to utilize benefits
actually implemented.

CPU speeds hit the brick wall at about 4GHz, 10 years ago, so they
spread laterally across multiple cores;- at present code works are
averaged across and optimized for quad cores. Storage is becoming
increasingly trivial, as it seems to me;- All good things of course.

What's left? A cadre of dedicated and long-standing gamers;...I gave
up games long ago. A WEB from the perspective of tablets . . . a
tighter WEB, decidedly, and one certainly more restrictively focused
from a distinction between services, come-ons for advertising purposes
and a finer discernment for positions between intent and what's
actually possible.

Thankfully, from my limited knowledge of UEFI, seems at least on some
MB makes I've seen, that UEFI is "switchable": It can be turned off
for a LEGACY override, no?

On 26/4/2017 12:38 AM, Flasherly wrote:
....
Thankfully, from my limited knowledge of UEFI, seems at least on some
MB makes I've seen, that UEFI is "switchable": It can be turned off
for a LEGACY override, no?

I think the number one problem UEFI wanna address was installing of
Window$/Linux to hard disks bigger than 2TB. If you don't do that (for
example, using small-sized SSD), then there is no need to go UEFI.

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

On Wed, 26 Apr 2017 00:44:39 +0800, "Mr. Man-wai Chang"
wrote:

I think the number one problem UEFI wanna address was installing of
Window$/Linux to hard disks bigger than 2TB. If you don't do that (for
example, using small-sized SSD), then there is no need to go UEFI.

Gee...nothing in new features awe inspiring, jaw-dropping to look
forward to if I get my paws on a UEFI board. That's OK. I still
haven't implemented a hard drive 2T on my present MBs:
Gigabyte G41MT-S2PT F2 (Intel quad q8200)
Gigabyte m61pme-s2 ( Phenom X4 9550)

On 26/4/2017 1:14 AM, Flasherly wrote:
Gee...nothing in new features awe inspiring, jaw-dropping to look
forward to if I get my paws on a UEFI board. That's OK. I still
haven't implemented a hard drive 2T on my present MBs:
Gigabyte G41MT-S2PT F2 (Intel quad q8200)
Gigabyte m61pme-s2 ( Phenom X4 9550)

Then I should expect UEFI 3.0? Which would prevent the loss of boot
entries stored in CMOS... very much like the good, old MBR booting.

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
�借貸! ��騙! ��交! �打交! �打劫! �自殺! 請考慮綜� (CSSA):
http://www.swd.gov.hk/tc/index/site_...sub_addressesa

On Wed, 26 Apr 2017 01:18:35 +0800, "Mr. Man-wai Chang"
wrote:

Then I should expect UEFI 3.0? Which would prevent the loss of boot
entries stored in CMOS..

Is it all UEFI? If you have a MB that you can you turn UEFI off, and
a LEGACY that then might address to solve the issues with your entries
-- that could be right.

"Mr. Man-wai Chang"
news alt.comp.hardware.pc-homebuilt, wrote:

How do you do that easily? Must I always keep a recovery disc
ready? If so, wouldn't it make things more complex than MBR boot?

https://duckduckgo.com/?q=how+to+rec...es&t=hc&ia=web

You could always opt to image the system firmware...And reload the
image in the event you needed it. But, umm, if you're having to ask
questions like this, it's probably not something you should be ****ing
with.

The old MBR method can always boot even after a CMOS reset.

Yes and no... just depends on the age of the computer we're discussing
here. Really old machines, couldn't just auto detect your HD and
proceed to fire up.




--
I would like to apologize for not having offended you yet.
Please be patient. I will get to you shortly.

Flasherly
Tue, 25 Apr 2017
14:59:16 GMT in alt.comp.hardware.pc-homebuilt, wrote:


I've never used UEFI, although a recent budget MB I've been
looking at, (neither entirely sure it would be a UEFI board, for
that matter, per se), has two physically chipped and redundant
BIOS sets. Which begs the question whether a changed BIOS set on
one can be copied to the other for the event of a failure, then
and if provided for overriding default settings should the first
fault in error. (Logically it doesn't quite make sense to me
without pin-MB jumpers for "hardwiring" the condition.)

The second BIOS chip isn't a full fledged duplicate, based on the
boards i've seen so far. Not saying one doesn't exist, just that I
haven't, personally run across it yet. The secondary BIOS exists to get
the machine up (post) and allow you to reflash the firmware damaged
actual BIOS. It's a second layer of defense to keep you from accidently
turning your board into a paperweight. Some of us have the required
hardware to be able to pull the dead BIOS and reflash it outside of the
mainboard, but, this can't always be done easily. If the chip is
soldered, the chances are much smaller. If it's removable, the chances
are better.




--
I would like to apologize for not having offended you yet.
Please be patient. I will get to you shortly.