Date: Wed, 23 Aug 2017 11:19:25 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-sysinstall@FreeBSD.org Subject: [Bug 221674] Installer can't back up when it finds MBR Message-ID: <bug-221674-2920-blx2TP6eTc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-221674-2920@https.bugs.freebsd.org/bugzilla/> References: <bug-221674-2920@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221674 --- Comment #5 from MMacD <scratch65535@att.net> --- (In reply to Nathan Whitehorn from comment #4) "It's one installer, the issue is that it has no idea if the machine has CS= M or not. You can't know that unless you booted CSM. " I apologise if this is a dopey question, but I've never had occasion to loo= k at specific load-and-go problems. Despite being comfortable with assembly languages, my interests have always been up at the human end (not surprisin= g, perhaps, in someone trained as a psychologist). My mental model of what's going on is that the bios (or equivalent) spins up the cd drive (or equivalent), loads the primary boot, and jumps to its well-known start address, carrying on from there. I.e., it's at least a somewhat agnostic operation at that point, capable of going down either of = two paths. Why wouldn't that be a good place to add somebody who could take a diagnost= ic look at the disc and present something like my menu suggestion? Such code would have the same access as any later code for doing low-level reads in a= id of figuring out what's on the disc. Again: apologies if this is a dopey question, and I'd be happy in that case= to be clued up if you feel you can take the time. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221674-2920-blx2TP6eTc>