Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #119404 > unrolled thread
| Started by | rs99tl@gmail.com |
|---|---|
| First post | 2018-11-09 17:32 -0800 |
| Last post | 2018-11-11 13:04 -0500 |
| Articles | 20 on this page of 83 — 14 participants |
Back to article view | Back to comp.sys.mac.system
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: APFS on HDD rs99tl@gmail.com - 2018-11-09 17:32 -0800
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-10 14:42 +1300
Re: APFS on HDD RSORLANDO <rs99tl@gmail.com> - 2018-11-09 18:15 -0800
Re: APFS on HDD Elden <usenet@moondog.org> - 2018-11-09 21:27 -0800
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-10 18:52 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-10 09:11 -0500
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-11 10:08 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-10 17:41 -0500
Re: APFS on HDD nospam <nospam@nospam.invalid> - 2018-11-10 19:18 -0500
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-11 18:03 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-11 13:21 -0500
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-12 03:09 +0000
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-12 02:10 -0500
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-12 12:32 +0000
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-13 08:14 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-12 20:29 -0500
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-13 18:15 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-13 09:20 -0500
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-12 02:30 -0500
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-12 12:45 +0000
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-12 18:31 -0500
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-13 00:04 +0000
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-13 13:46 +1300
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-11 15:55 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-10 23:38 -0500
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-11 07:18 +0000
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-11 12:39 -0500
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-12 09:10 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-11 19:26 -0500
Re: APFS on HDD Your Name <YourName@YourISP.com> - 2018-11-12 16:20 +1300
Re: APFS on HDD J Burns <burns@nospam.com> - 2018-11-12 01:46 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-14 02:05 +1300
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-11 07:13 +0000
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-12 02:10 -0500
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-12 02:02 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-12 21:57 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-12 18:26 -0500
Re: APFS on HDD Jolly Roger <jollyroger@pobox.com> - 2018-11-13 01:12 +0000
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-12 23:44 -0500
Re: APFS on HDD Jolly Roger <jollyroger@pobox.com> - 2018-11-13 18:17 +0000
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-13 19:38 +1300
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-13 10:21 +0000
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-13 05:55 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-14 01:28 +1300
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-13 13:40 +0000
Re: APFS on HDD Jolly Roger <jollyroger@pobox.com> - 2018-11-13 18:18 +0000
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-13 05:57 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-14 01:28 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-13 13:27 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-14 13:31 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-14 15:33 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-15 12:04 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-15 00:35 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-15 22:24 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-15 12:39 -0500
Re: APFS on HDD Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2018-11-16 13:45 -0500
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-16 20:13 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-18 18:37 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-18 17:40 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-19 13:42 +1300
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-19 02:08 +0000
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-19 15:52 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-18 22:31 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-20 13:23 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-19 23:32 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-20 22:05 +1300
Re: APFS on HDD "David B." <"David B"@nomail.afraid.org> - 2018-11-20 09:36 +0000
Re: APFS on HDD André G. Isaak <agisaak@gm.invalid> - 2018-11-20 06:12 -0700
Re: APFS on HDD "David B." <"David B"@nomail.afraid.org> - 2018-11-20 14:28 +0000
Re: APFS on HDD nospam <nospam@nospam.invalid> - 2018-11-20 09:36 -0500
Re: APFS on HDD nospam <nospam@nospam.invalid> - 2018-11-20 08:57 -0500
Re: APFS on HDD "David B." <"David B"@nomail.afraid.org> - 2018-11-20 14:34 +0000
Re: APFS on HDD nospam <nospam@nospam.invalid> - 2018-11-20 09:36 -0500
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-19 05:46 +0000
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-19 02:27 -0500
Re: APFS on HDD Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2018-11-19 11:42 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-20 13:23 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-19 21:57 -0500
Re: APFS on HDD dempson@actrix.gen.nz (David Empson) - 2018-11-20 16:28 +1300
Re: APFS on HDD JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-11-21 13:24 -0500
Re: APFS on HDD Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2018-11-19 11:34 -0500
Re: APFS on HDD Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-11-13 13:41 +0000
Re: APFS on HDD Alan Browne <bitbucket@blackhole.com> - 2018-11-11 13:04 -0500
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2018-11-19 02:08 +0000 |
| Message-ID | <slrnpv46p1.2did.g.kreme@Snow.local> |
| In reply to | #119579 |
In message <BTlID.572643$sO2.508519@fx41.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2018-11-18 00:37, David Empson wrote: >> That may have been the case in APFS version 1 (developer preview on >> Sierra), which Apple hasn't documented in detail. I haven't tried >> multi-volume boot scenerios yet, except in separate >> partitions/containers. > When I watched the APFS presentation in 2017, it mentiond that APFS > basically placed the boot information (block location, number of blocks > to load etc) in block 0 of the GPT partition where the EFI firmware > would look to see if the GPT partition was bootable. > So from an EFI point of view, it could only see one bootable volume in > the GPT partition that containes the APFS container which may contain > multiple bootable APFS volumes) I do not elive these two paragraphs are accurate or display am understanding of how file systems work or anything abotu APFS. We know for absolute fact that a disk in a mac can have multiple boot volumes. This has been true as long as the Mac has supported hard drives. Possibly longer. > But that would mean that at the EFI level, it cannot list all bootable > volumes, See, a normal person would take a statement like that as proof they didn't understand what was going on. You know damn well that APFS volumes are bootable and that a disk can have multiple bootable volumes and yet you persist. > I was really expecting/hoping for an APFS update at this year WWDC to > discuss how they tackled that challenge. The "Challenge" you invented? Based on... nothing? -- I noticed that but was still trying to work out a way of drawing it to everyone's attention that would be sufficiently satisfying, combining maximum entertainment value for readers with maximum humiliation for you. -- Laura
[toc] | [prev] | [next] | [standalone]
| From | dempson@actrix.gen.nz (David Empson) |
|---|---|
| Date | 2018-11-19 15:52 +1300 |
| Message-ID | <1nyiqcn.1rpsrwgn7nqxdN%dempson@actrix.gen.nz> |
| In reply to | #119582 |
Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > In message <BTlID.572643$sO2.508519@fx41.iad> JF Mezei <jfmezei.spamnot@ > vaxination.ca> wrote: > > On 2018-11-18 00:37, David Empson wrote: > > >> That may have been the case in APFS version 1 (developer preview on > >> Sierra), which Apple hasn't documented in detail. I haven't tried > >> multi-volume boot scenerios yet, except in separate > >> partitions/containers. > > > When I watched the APFS presentation in 2017, it mentiond that APFS > > basically placed the boot information (block location, number of blocks > > to load etc) in block 0 of the GPT partition where the EFI firmware > > would look to see if the GPT partition was bootable. > > > So from an EFI point of view, it could only see one bootable volume in > > the GPT partition that containes the APFS container which may contain > > multiple bootable APFS volumes) > > I do not elive these two paragraphs are accurate or display am > understanding of how file systems work or anything abotu APFS. Both paragraphs have details wrong but the basic concept is correct. > We know for absolute fact that a disk in a mac can have multiple boot > volumes. This has been true as long as the Mac has supported hard > drives. Possibly longer. That's true for drives with mulitple partitions with older file systems where each partition holds a single volume, but each APFS partition is a container which can hold multiple volumes. The EFI firmware understands nothing about APFS beyond identifying an APFS partition/container, and loading an EFI jumpstart driver (which is an EFI program) from the APFS container. The EFI jumpstart driver is pointed to by the container's superblock, which has a copy in block 0 of the partition. The EFI firmware is unaware of volumes inside the APFS container. That means if you have a single APFS container with mulitple bootable volumes inside it, the EFI Startup Manager (option key at startup) cannot offer those volumes to you, because it doesn't kwow they exist. It will show a single icon and name for the APFS container. Which APFS volume that boots is determined by the EFI jumpstart driver read from the container, and the information it reads from the Preboot volume. (It may divert to the recovery volume, e.g. by holding down the right keys at startup.) The preboot volume information is typically set by Startup Disk in System Preferences. Since EFI programs can present a user interface, if Apple wanted they could have the EFI jumpstart driver present an interface resembling the Startup Manager which let you pick between multiple bootable volumes inside the container. They probably don't think it is worth confusing the user by adding a second layer of bootable volume selection at startup for something which very few users would bother setting up, and those who do can use Startup Disk in System Preferences to change the boot volume. You _can_ have a drive which has multiple APFS partitions (containers) each with a single bootable volume, and pick between those containers in the Startup Manager. This prevents free space sharing between the APFS volumes because they are in different APFS containers. > > But that would mean that at the EFI level, it cannot list all bootable > > volumes, > > See, a normal person would take a statement like that as proof they > didn't understand what was going on. You know damn well that APFS volumes > are bootable and that a disk can have multiple bootable volumes and yet > you persist. Multiple bootable volumes in separate partitions, yes. You can't have multiple bootable volumes inside a single APFS container (partition) and expect to be able to pick among them at startup of the computer (while EFI is the only software running). -- David Empson dempson@actrix.gen.nz
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2018-11-18 22:31 -0500 |
| Message-ID | <L8qID.493597$um3.185246@fx32.iad> |
| In reply to | #119583 |
On 2018-11-18 21:52, David Empson wrote: > The EFI firmware understands nothing about APFS beyond identifying an > APFS partition/container, and loading an EFI jumpstart driver Technically, it identifies a GPT partition. Normally (outside of Apple environment), EFI accesses the "EFI" partition on the device which you are booting from, parses its FAT32 file system to get the EFI boot programme and branches to it. That program is specicfic to the OS and knows how to parse the file system of the system volume and then finds and loads the OS boot file and branches to it. Apple's implementation of the EFI firmware added the ability to peek at a specific location on the system GPT partition to find the location and size of the OS boot image which it loads and branches to. This avoids having to go through the EFI partition. On Macs, block 0 of the system GPT partition holds the location and block count of the OS boot image. This was part of the HFS+ design and Apple's EFI was hardcoded to look at that location to get the OS boot loader. So when Apple developped APFS, they arranged for block 0 of the GPT partition containing the APFS container to have the boot informatin ion the same place as on an HFS+ volume si that existing computers with Apple's EFI wuld find the boot info where they were told to look for it in block 0. However, because EFI has no knowledge of file systems other than FAT32, it does not understand what is inside that GPT partition and isn't able to know that it contains an APFS container which itself may contain multiple APFS volumes. My Mac is from 2013, well before APFS was developped and yet can boot without knowing about APFS. BUT, when you consider booting from an encrypted disk, or booting from the recovery volume which is inside an APFS container, since EFI doesn't have the knowledged to do that, it must mean that block 0 contains pointers not to the OS boot loader but some intermediate boot program which can see the "R" was pressed for recovery and parse through the APFS container to find the Recovery volume and then get the boot block from it and load it. Simularly, that intermediate boot program will need to ask for encryption password and use it to load and decrypt the operating system boot loader (boot.EFI) otherwise that data would be gibberish. Since Apple doesn't provide command line access to EFI console, all those details are hidden to users. But they are there. The only way for the console to boot from recovery partition for instance is for it to boot the GPT partition and let whatever is there device whether to boot the OS or the recovery partition.
[toc] | [prev] | [next] | [standalone]
| From | dempson@actrix.gen.nz (David Empson) |
|---|---|
| Date | 2018-11-20 13:23 +1300 |
| Message-ID | <1nyiu5v.1byex6aaoj7cdN%dempson@actrix.gen.nz> |
| In reply to | #119584 |
JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2018-11-18 21:52, David Empson wrote: > > > The EFI firmware understands nothing about APFS beyond identifying an > > APFS partition/container, and loading an EFI jumpstart driver > > Technically, it identifies a GPT partition. EFI on the Mac also understands a particular set of supported file systems inside GPT partitions. > Normally (outside of Apple environment), EFI accesses the "EFI" partition > on the device which you are booting from, parses its FAT32 file system Actually it is the EFI file system, which is based on FAT32 but not necessarily identical to it. > to get the EFI boot programme and branches to it. That program is > specicfic to the OS and knows how to parse the file system of the system > volume and then finds and loads the OS boot file and branches to it. Apple doesn't use that method to boot HFS+ volumes, and I don't think it is used for APFS either. > Apple's implementation of the EFI firmware added the ability to peek at > a specific location on the system GPT partition What is a "system GPT partition"? I'll assume you mean any GPT partition which contains a bootable system. > to find the location and size of the OS boot image which it loads and > branches to. This avoids having to go through the EFI partition. > > On Macs, block 0 of the system GPT partition holds the location and > block count of the OS boot image. This was part of the HFS+ design and > Apple's EFI was hardcoded to look at that location to get the OS boot > loader. That last paragraph is completely wrong. HFS+ has a startup file referenced from its volume header. The volume header begins 1024 bytes after the start of the partition (assuming no HFS wrapper). The startup file is identified by its file ID number. Locating it requires searching the HFS+ catalog tree for that file ID number. The extents of the startup file can then be read from the catalog file, and used to load the startup file into memory, from where it is executed. APFS has a container superblock, a copy of which is at the start of the partition (logical block 0, no matter what size your sectors might be). That superblock includes fields listing the extents of the EFI jumpstart driver, so reading the EFI jumpstart driver only requires reading and verifying the superblock then reading the extents of the driver, not understanding anything about APFS volumes or anything inside them. Booting from either HFS+ or APFS requires direct support in the EFI firmware to recognise the GPT GUIDs indicating an HFS+ or APFS partition, then code which is different for each file system to read far enough to load the driver for the next boot stage. HFS+ support has been there since the introduction of Intel Macs. APFS support only exists in models new enough to boot High Sierra, and was probably added via a firmware update for models between late 2009 and somewhere in the ballpark of 2016-2017. > So when Apple developped APFS, they arranged for block 0 of the GPT > partition containing the APFS container to have the boot informatin ion > the same place as on an HFS+ volume si that existing computers with > Apple's EFI wuld find the boot info where they were told to look for it > in block 0. Wrong. They are in different places and are structured differently. See above. > However, because EFI has no knowledge of file systems other than FAT32, Generic EFI might not support anything but its own FAT32-based file system, but the Mac implementation defintely knows enough about HFS+ to boot from it, including parsing the catalog tree. > it does not understand what is inside that GPT partition and isn't able > to know that it contains an APFS container which itself may contain > multiple APFS volumes. My Mac is from 2013, well before APFS was > developped and yet can boot without knowing about APFS. That's because it had an EFI firmware update at some point, which added support for booting from APFS. My 2012-2015 Macs still running Sierra are all able to boot APFS. They have been getting firmware updates via security updates. My 2011 MacBook Pro is running from an APFS High Sierra volume (internal SSD). It also got a firmware update at some point to add support for booting APFS. My 2009 Mac Mini can't even see an APFS boot volume in Startup Manager, let alone try to boot from one. If your claim was right, my 2009 Mac Mini should attempt to boot from an APFS volume but the kernel would reject the model because it is too old. It can't even get that far. There is no way to even choose an APFS volume to boot from, because the firmware doesn't recognise the partition type or that it contains an EFI boot driver. > BUT, when you consider booting from an encrypted disk, or booting from > the recovery volume which is inside an APFS container, since EFI doesn't > have the knowledged to do that It doesn't need to. EFI boots via the EFI jumpstart driver, which can then reference other files in the Preview volume. That volume is not encrypted. That code works out whether to boot from Recovery, present the FileVault unlock screen or continue booting from an unencrypted startup volume. > it must mean that block 0 contains pointers not to the OS boot loader but > some intermediate boot program which can see the "R" was pressed for > recovery and parse through the APFS container to find the Recovery volume > and then get the boot block from it and load it. Did you even bother looking at the table of contents in Apple's APFS technical document which Stephen referenced and you claimed you had (tried) reading? It has a major heading titled "EFI Jumpstart" which at least partly explains the APFS boot process. -- David Empson dempson@actrix.gen.nz
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2018-11-19 23:32 -0500 |
| Message-ID | <C7MID.598255$OM2.367723@fx37.iad> |
| In reply to | #119595 |
On 2018-11-19 19:23, David Empson wrote: > EFI on the Mac also understands a particular set of supported file > systems inside GPT partitions. Yet, EFI on Macs looks at specific fields inside block 0 of a GPT partition to obtain the location and size of the data to load from disk and branch to. And it is this file-system-blind tecnique which allows older Macs to boot an APFS volume without knwing about APFS. > Apple doesn't use that method to boot HFS+ volumes, and I don't think it > is used for APFS either. The EFI partition is necessary for other operating systems which use a file system unknwon to EFI so EFI needs to boot an EFI program which understands how to boot that operating system. Apple chose to bypass that and augment its EFI firmware to add the logic of lookijg at block 0 of a GPT partition to find location/size of the boot file. Macs can boot "EFI native" (load the code from the EFI partition and let that code then choose/load the operating system boot file) but it requires some persuasion to get it to do that. > What is a "system GPT partition"? I'll assume you mean any GPT partition > which contains a bootable system. When EFI gets to the boot phase, it uses the boot volume (sourced from nvram) and considers that GPT partition to be the system disk. It loads blocks from that disk and branches to that code. That code which is no longer EFI then has more knowledged about the file system environment. There is no need for EFI firmware to understand HFS or APFS. The specs only call it to understand FAT32 (or some variant) to access files by name in the EFI partition. > HFS+ has a startup file referenced from its volume header. The volume > header begins 1024 bytes after the start of the partition (assuming no > HFS wrapper). The startup file is identified by its file ID number. > Locating it requires searching the HFS+ catalog tree for that file ID > number. The extents of the startup file can then be read from the > catalog file, and used to load the startup file into memory, from where > it is executed. You may recall when APFS was first announce, my asking how EFO woudl hadle that. I eventually found either in the Apple WWDC presentation or other documents that EFI did not understand HFS file system, only read block 0 and that APFS would maintain this compatibility. Obviously, what is contained in the initial code read from disk by EFI is very different when booting from a GPT partition that contains APFS container/volumes. But EFI itself need not be different. Looking at current behaviour, I suspect this data in block 0 points to data in the Preboot partition instead of blocks where the traditional /points to blocks that contain a file in the "Preboot" APFS volume. Had Apple wanted EFI to parse through the file system to get to the boot file, it would have used the EFI partition mechanism to gain understanding of the HFS and now APFS file system. Instead, it appears that the Preboot partition plays that role and is contained inside the APFS container which Apple has better control over during installations. So while in the past, block 0 pointed to blocks that contained the file /System/Library/CoreServices/boot.efi in the operating system volume, I suspect it now point to blocks that contain data from a boot file in the preboot partition and that code may contain the code that can list the APFS volumes, ask for decryption password etc and eventually find and load the /System/Library/CoreServices/boot.efi in the desired operating system volume. But that is way beyond what the EFI firmware does. > APFS has a container superblock, a copy of which is at the start of the > partition (logical block 0, no matter what size your sectors might be). > That superblock includes fields listing the extents of the EFI jumpstart > driver, so reading the EFI jumpstart driver only requires reading and > verifying the superblock then reading the extents of the driver, not > understanding anything about APFS volumes or anything inside them. But you just said that I was wrong claiming that. > Booting from either HFS+ or APFS requires direct support in the EFI > firmware to recognise the GPT GUIDs indicating an HFS+ or APFS > partition, then code which is different for each file system to read far > enough to load the driver for the next boot stage. No. It would need support to verify that block 0 looks like, smells like and talks like an HFS block 0 with certain fields in certain locations of that block and if valid, load X blocks starting at block Y and branch to that code once loaded. What is loaded from disk has much greater uderstanding of the file system, ability to parse some of the plist and raw data stored in the nvram parameters etc. But that is no longer EFI running. (although EFI services such as listing of devices, system config remain available). > APFS support only exists in models new enough to boot High Sierra, and > was probably added via a firmware update for models between late 2009 > and somewhere in the ballpark of 2016-2017. Apple's prresentatioN/document stated that EFI would continue to run as before, load x blocks starting at block Y, where x and Y are taken from block 0 at specific locations. > If your claim was right, my 2009 Mac Mini should attempt to boot from an > APFS volume but the kernel would reject the model because it is too old. > It can't even get that far. There is no way to even choose an APFS > volume to boot from, because the firmware doesn't recognise the > partition type or that it contains an EFI boot driver. EFI on Macs has no ability to let you choose the boot volume. It automatically boots into a volume stored in nvram or acts based on what keys were pressed. The only way to choose a startup volume is from system prefernecs in a fully booted system (and older versions woudln't know about APFS so wouldn't let you choose that as startup volume). If you could manage to set the boot volume in nvram (or perhaps clear NVRAM to force EFI to "guess" a new boot volume, it might work. You'd have to make sure to press the right key to invoke the menu that presents possible boot menus and that menu should come from the new APFS volume and let you select the OS APFS volume. (after which you would have kernel complaints about model number being incompatible). > It doesn't need to. EFI boots via the EFI jumpstart driver, which can > then reference other files in the Preview volume. "EI jusmpstart driver" is not a driver, it is code that EFI transfers controls to. EFI doesn't know what that code will do, nor does it care. However, it appears Apple uses that terminology. it is wrong. And EFI driver would be called by the EFI firmware. It is the opposite thyat happens as the boot file runs and then calls EFI subroutines (such as getting list of devices which EFI has obtained on power up). And since you p]oint me to "EFI Jumpstart" section on the APFS reference, I will quote the first paragraph of that section: "You can locate the EFI driver by reading a few data structures, starting at a known physical address on disk. *****You donʼt need any support for reading or mounting Apple File System to locate the EFI driver.********" (emphasis mine) What Apple calles "EFI jumpstart" is actually the boot file. It is the datra which EFI loads in RAM and then transfers control to, expecting that code to do what it has to do to boot the system. When such a file doesn't actually boot an OS, it is often called an EFI programme as it remains in basic consolme mode. (for instance, to get console mode on a Mac, you would install an EFI program in the EFI partition and then coax the Mac to boot from it. - On others sytsems, the EFI console is part of firmware).
[toc] | [prev] | [next] | [standalone]
| From | dempson@actrix.gen.nz (David Empson) |
|---|---|
| Date | 2018-11-20 22:05 +1300 |
| Message-ID | <1nyks3h.13xeh6o16jbdj6N%dempson@actrix.gen.nz> |
| In reply to | #119599 |
JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2018-11-19 19:23, David Empson wrote: > > > EFI on the Mac also understands a particular set of supported file > > systems inside GPT partitions. > > Yet, EFI on Macs looks at specific fields inside block 0 of a GPT > partition to obtain the location and size of the data to load from disk > and branch to. The initial part of the boot information for HFS+ and APFS happens to be within the first 4096 bytes of the partition (which you could arguably call "block 0" if you pretend all disks have 4096 byte blocks) but the internal structure of that data is completely different. Interpreting either of them requires knowledge of the data structure used by the specific file system. The boot file information is in a different place and is structured in a completely different format, and for APFS it requires reading a second block elsehwere on the disk before the boot file can be read. > And it is this file-system-blind tecnique which allows > older Macs to boot an APFS volume without knwing about APFS. No, it updated firmware which allows Macs to boot APFS. > > Apple doesn't use that method to boot HFS+ volumes, and I don't think it > > is used for APFS either. > > The EFI partition is necessary for other operating systems which use a > file system unknwon to EFI so EFI needs to boot an EFI program which > understands how to boot that operating system. Irrelevant to booting a Mac from HFS+ or APFS. > Apple chose to bypass that and augment its EFI firmware to add the logic > of lookijg at block 0 of a GPT partition to find location/size of the > boot file. No, Apple added specific support in firmware for booting HFS+ and APFS. > Macs can boot "EFI native" (load the code from the EFI partition and let > that code then choose/load the operating system boot file) but it > requires some persuasion to get it to do that. > > > > What is a "system GPT partition"? I'll assume you mean any GPT partition > > which contains a bootable system. > > When EFI gets to the boot phase, it uses the boot volume (sourced from > nvram) and considers that GPT partition to be the system disk. It loads > blocks from that disk and branches to that code. That code which is no > longer EFI Wrong again. EFI loads a boot driver (e.g. boot.efi for HFS+ volumes) which is code that runs within EFI. It is an EFI application. > then has more knowledged about the file system environment. > > There is no need for EFI firmware to understand HFS or APFS. The specs > only call it to understand FAT32 (or some variant) to access files by > name in the EFI partition. I don't care what the EFI specs say. Apple modified standard EFI, adding special support for booting HFS+ and now APFS. > > HFS+ has a startup file referenced from its volume header. The volume > > header begins 1024 bytes after the start of the partition (assuming no > > HFS wrapper). The startup file is identified by its file ID number. > > Locating it requires searching the HFS+ catalog tree for that file ID > > number. The extents of the startup file can then be read from the > > catalog file, and used to load the startup file into memory, from where > > it is executed. > > You may recall when APFS was first announce, my asking how EFO woudl > hadle that. I eventually found either in the Apple WWDC presentation or > other documents that EFI did not understand HFS file system, only read > block 0 and that APFS would maintain this compatibility. A correction to my previous post: EFI does not need to understand the HFS file system. I didn't have time to do another fact check and missed one detail in my quick re-read of the HFS+ technical note. The volume header includes a list of extents for the startup file, therefore to boot from HFS+ it is only necessary for EFI to: 1. Identify it is an HFS+ partition. 2. Read the volume header from byte offsets 1024 to 1535 from start of partition (block 2 if using 512 byte blocks). 3. Verify the volume header appears sane (limited since HFS+ doesn't have any checksum on the volume header, but it does have a signature and other fields could be checked for values in a legal range). 4. Look at the startupFile field to get file length and list of extents for the startup file. 5. Read each of the extents into memory. 6. Call the code just loaded. For APFS (simplifying slightly compared to Apple's document): 1. Identify it is an APFS partition. 2. Read the copy of the superblock from block 0 (using 4096 byte blocks). 3. Verify it is a valid APFS superblock. There are several fields with values that can be checked, and the entire superblock has a checksum. 4. Look at the nx_efi_jumpstart field to get the physical block address of the EFI jumpstart information. 5. Read that block into memory and verify it. 6. Look into the data in that block to get the file length and list of extents for the EFI jumpstart file. 7. Read each of the extents into memory. 8. Call the code just loaded. Compared to HFS+, for APFS the initial read is slightly bigger and starts slightly earlier, the data structure is completely different, and an extra block read is needed to get the information for loading the startup file. They are conceptually similar but use different data structures. > Obviously, what is contained in the initial code read from disk by EFI > is very different when booting from a GPT partition that contains APFS > container/volumes. But EFI itself need not be different. EFI needs to know how to interpret the data in the block. Older firmware can't parse an APFS superblock because it has a completely differerent structure from the first 4096 bytes of an HFS+ volume. EFI support for booting HFS+ does not help for booting APFS. > Looking at current behaviour, I suspect this data in block 0 points to > data in the Preboot partition instead of blocks where the traditional > /points to blocks that contain a file in the "Preboot" APFS volume. I can't parse that paragraph. > > APFS has a container superblock, a copy of which is at the start of the > > partition (logical block 0, no matter what size your sectors might be). > > That superblock includes fields listing the extents of the EFI jumpstart > > driver, so reading the EFI jumpstart driver only requires reading and > > verifying the superblock then reading the extents of the driver, not > > understanding anything about APFS volumes or anything inside them. > > But you just said that I was wrong claiming that. No, I said you were wrong claiming that HFS+ and APFS had identically structured boot information in block 0. > > Booting from either HFS+ or APFS requires direct support in the EFI > > firmware to recognise the GPT GUIDs indicating an HFS+ or APFS > > partition, then code which is different for each file system to read far > > enough to load the driver for the next boot stage. > > No. Yes. > It would need support to verify that block 0 looks like, smells like > and talks like an HFS block 0 with certain fields in certain locations > of that block and if valid, load X blocks starting at block Y and branch > to that code once loaded. Yes, but the details differ between HFS+ and APFS (see above). > What is loaded from disk has much greater uderstanding of the file > system, Yes, that would be boot.efi (HFS+) or the EFI jumpstart driver (APFS). > ability to parse some of the plist and raw data stored in the > nvram parameters etc. But that is no longer EFI running. (although EFI > services such as listing of devices, system config remain available). That file is an EFI application (written for the platform neutral EFI byte code virtual machine). EFI certainly is still running, because it interprets and executes that boot code. > > APFS support only exists in models new enough to boot High Sierra, and > > was probably added via a firmware update for models between late 2009 > > and somewhere in the ballpark of 2016-2017. > > Apple's prresentatioN/document stated that EFI would continue to run as > before, load x blocks starting at block Y, where x and Y are taken from > block 0 at specific locations. Apple's presentations at WWDC 2016 or 2017 did not say exactly how APFS boots. Booting wasn't even supported in 2016 and was only mentioned in passing in 2017 without going into details beyond that it was future proofed to protect against possible implementation changes, was easy for VMs to implement, and APFS could boot from encrypted and Fusion drives. > > If your claim was right, my 2009 Mac Mini should attempt to boot from an > > APFS volume but the kernel would reject the model because it is too old. > > It can't even get that far. There is no way to even choose an APFS > > volume to boot from, because the firmware doesn't recognise the > > partition type or that it contains an EFI boot driver. > > EFI on Macs has no ability to let you choose the boot volume. Yes it does. That's the whole point of the Startup Manager (in firmware), which lets you override the configured startup disk and pick a different volume or network boot server. > It automatically boots into a volume stored in nvram or acts based on what > keys were pressed. The only way to choose a startup volume is from system > prefernecs in a fully booted system (and older versions woudln't know > about APFS so wouldn't let you choose that as startup volume). > > If you could manage to set the boot volume in nvram (or perhaps clear > NVRAM to force EFI to "guess" a new boot volume Or simply remove the drive from the system. I just did that with my 2011 MacBook Pro: shut down, pulled its internal drive (no external drive connected), started up with Option key and got the Startup Manager. Again, where do you imagine that graphical user interface came from if there was no storage device connected to the computer? It is in the firmware of the Mac. At that point it was only offering to join a Wi-Fi network (with a popup menu showing available networks). I plugged in my APFS test drive (three bootable volumes in one container) and it showed them as the usual list of bootable volume icons, and I was able to boot from one of them. >, it might work. You'd have to make sure to press the right key to >invoke the menu that presents possible boot menus and that menu should >come from the new APFS volume and let you select the OS APFS volume. >(after which you would have kernel complaints about model number being >incompatible). Here is a further clue: if you have macOS installed in a virtual machine, it does NOT have the Mac Startup Manager, because virtual machines use something close to standard EFI (complete with a BIOS-like text mode boot selection menu), rather than a copy of the Mac firmware. If the Startup Manager was part of the boot driver loaded from the startup disk then it would be available in a standard installation of any macOS version in VM software and you could get to it via the Option key. That does not happen. > > It doesn't need to. EFI boots via the EFI jumpstart driver, which can > > then reference other files in the Preview volume. > > "EI jusmpstart driver" is not a driver, That's what Apple calls it. > And since you p]oint me to "EFI Jumpstart" section on the APFS > reference, I will quote the first paragraph of that section: > > "You can locate the EFI driver by reading a few data structures, > starting at a known physical address on disk. *****You don?t need any > support for reading or mounting Apple File System to locate the EFI > driver.********" (emphasis mine) I never said EFI needed APFS file system support to boot, just the ability to recognise an APFS partition and understand the superblock so it can load the EFI jumpstart driver for booting. (I did say that EFI needed basic HFS+ file system support to boot HFS+, which was a mistake on my part that I didn't catch in time.) -- David Empson dempson@actrix.gen.nz
[toc] | [prev] | [next] | [standalone]
| From | "David B." <"David B"@nomail.afraid.org> |
|---|---|
| Date | 2018-11-20 09:36 +0000 |
| Message-ID | <aAQID.36614$sG.7727@fx16.fr7> |
| In reply to | #119601 |
On 20/11/2018 09:05, David Empson wrote: > Here is a further clue: if you have macOS installed in a virtual > machine, it does NOT have the Mac Startup Manager Mr Empson What OTHER indications would the user of an iMac have to show that his macOS Mojave was operating in a virtual machine environment? I'm interested because I am unable to boot my iMac into Safe Boot mode by pressing down the shift key when starting or restarting my machine. -- David B.
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2018-11-20 06:12 -0700 |
| Message-ID | <pt118q$rf1$1@dont-email.me> |
| In reply to | #119602 |
On 2018-11-20 2:36 a.m., David B. wrote: > On 20/11/2018 09:05, David Empson wrote: >> Here is a further clue: if you have macOS installed in a virtual >> machine, it does NOT have the Mac Startup Manager > > Mr Empson > > What OTHER indications would the user of an iMac have to show that his > macOS Mojave was operating in a virtual machine environment? Well, the obvious indicator would be a running Parallels Desktop or VMWare Fusion icon in your dock... André > I'm interested because I am unable to boot my iMac into Safe Boot mode > by pressing down the shift key when starting or restarting my machine. > -- To email remove 'invalid' & replace 'gm' with well known Google mail service.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <"David B"@nomail.afraid.org> |
|---|---|
| Date | 2018-11-20 14:28 +0000 |
| Message-ID | <rSUID.106207$eY4.79807@fx30.fr7> |
| In reply to | #119604 |
On 20/11/2018 13:12, André G. Isaak wrote: > On 2018-11-20 2:36 a.m., David B. wrote: >> On 20/11/2018 09:05, David Empson wrote: >>> Here is a further clue: if you have macOS installed in a virtual >>> machine, it does NOT have the Mac Startup Manager >> >> Mr Empson >> >> What OTHER indications would the user of an iMac have to show that his >> macOS Mojave was operating in a virtual machine environment? > > Well, the obvious indicator would be a running Parallels Desktop or > VMWare Fusion icon in your dock... Thanks, André I don't have such icons on my dock! :-) I've noticed this new thread on ASC, "How do I install OS X 14.1 as a VMWare Fusion guest?" https://discussions.apple.com/message/34193711?ac_cid=tw123456#34193711 -- David B. (My ABC: Assume Nothing, Believe No one, Challenge Everything).
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2018-11-20 09:36 -0500 |
| Message-ID | <201120180936170371%nospam@nospam.invalid> |
| In reply to | #119607 |
In article <rSUID.106207$eY4.79807@fx30.fr7>, David B. < B"@nomail.afraid.org> wrote: > > I've noticed this new thread on ASC, stop hijacking threads.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2018-11-20 08:57 -0500 |
| Message-ID | <201120180857381165%nospam@nospam.invalid> |
| In reply to | #119602 |
In article <aAQID.36614$sG.7727@fx16.fr7>, David B. < B"@nomail.afraid.org> wrote: > I'm interested because I am unable to boot my iMac into Safe Boot mode > by pressing down the shift key when starting or restarting my machine. if only you were unable to boot it on a permanent basis.
[toc] | [prev] | [next] | [standalone]
| From | "David B." <"David B"@nomail.afraid.org> |
|---|---|
| Date | 2018-11-20 14:34 +0000 |
| Message-ID | <EXUID.18106$RL.10523@fx01.fr7> |
| In reply to | #119606 |
On 20/11/2018 13:57, nospam wrote: > In article <aAQID.36614$sG.7727@fx16.fr7>, David B. < > B"@nomail.afraid.org> wrote: > >> I'm interested because I am unable to boot my iMac into Safe Boot mode >> by pressing down the shift key when starting or restarting my machine. > > if only you were unable to boot it on a permanent basis. Sadly, that's exactly what happened to my old iMac. I took it apart to see how well made it was. I've retained some parts but the case and internal wiring have gone to be recycled at our local waste tip. I confess that I do like this new machine! :-) -- David B. (My ABC: Assume Nothing, Believe No one, Challenge Everything).
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2018-11-20 09:36 -0500 |
| Message-ID | <201120180936190436%nospam@nospam.invalid> |
| In reply to | #119608 |
In article <EXUID.18106$RL.10523@fx01.fr7>, David B. < B"@nomail.afraid.org> wrote: > >> I'm interested because I am unable to boot my iMac into Safe Boot mode > >> by pressing down the shift key when starting or restarting my machine. > > > > if only you were unable to boot it on a permanent basis. > > Sadly, that's exactly what happened to my old iMac. excellent news. > I took it apart to > see how well made it was. now do that to the new one and compare.
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2018-11-19 05:46 +0000 |
| Message-ID | <slrnpv4ji7.2rih.g.kreme@Snow.local> |
| In reply to | #119583 |
In message <1nyiqcn.1rpsrwgn7nqxdN%dempson@actrix.gen.nz> David Empson <dempson@actrix.gen.nz> wrote:
> Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>> In message <BTlID.572643$sO2.508519@fx41.iad> JF Mezei <jfmezei.spamnot@
>> vaxination.ca> wrote:
>> > On 2018-11-18 00:37, David Empson wrote:
>>
>> >> That may have been the case in APFS version 1 (developer preview on
>> >> Sierra), which Apple hasn't documented in detail. I haven't tried
>> >> multi-volume boot scenerios yet, except in separate
>> >> partitions/containers.
>>
>> > When I watched the APFS presentation in 2017, it mentiond that APFS
>> > basically placed the boot information (block location, number of blocks
>> > to load etc) in block 0 of the GPT partition where the EFI firmware
>> > would look to see if the GPT partition was bootable.
>>
>> > So from an EFI point of view, it could only see one bootable volume in
>> > the GPT partition that containes the APFS container which may contain
>> > multiple bootable APFS volumes)
>>
>> I do not elive these two paragraphs are accurate or display am
>> understanding of how file systems work or anything abotu APFS.
> Both paragraphs have details wrong but the basic concept is correct.
>> We know for absolute fact that a disk in a mac can have multiple boot
>> volumes. This has been true as long as the Mac has supported hard
>> drives. Possibly longer.
> That's true for drives with mulitple partitions with older file systems
> where each partition holds a single volume, but each APFS partition is a
> container which can hold multiple volumes.
And yet we know that a single APFS continer can hold multiple bootable partitions.
> The EFI firmware understands nothing about APFS beyond identifying an
> APFS partition/container, and loading an EFI jumpstart driver (which is
> an EFI program) from the APFS container. The EFI jumpstart driver is
> pointed to by the container's superblock, which has a copy in block 0 of
> the partition.
> The EFI firmware is unaware of volumes inside the APFS container.
Right.
> That means if you have a single APFS container with mulitple bootable
> volumes inside it, the EFI Startup Manager (option key at startup)
> cannot offer those volumes to you, because it doesn't kwow they exist.
Wrong.
> It will show a single icon and name for the APFS container.
Nope. My startup drive has six APFS volumes on it
/dev/disk2 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +959.3 GB disk2
Physical Store disk1s2
1: APFS Volume Jaka 625.4 GB disk2s1
2: APFS Volume Preboot 45.4 MB disk2s2
3: APFS Volume Recovery 1.0 GB disk2s3
4: APFS Volume VM 2.1 GB disk2s4
5: APFS Volume Mojave 13.7 GB disk2s5
6: APFS Volume High 11.9 GB disk2s7
If I hold down the option key at boot I am offered a choice between
Jaka (Current Mojave with all the user data), Mojave (has 10.14.0 with
no user data), and High (10.13.$LATEST) with no user data.
> Which APFS volume that boots is determined by the EFI jumpstart driver
> read from the container, and the information it reads from the Preboot
> volume. (It may divert to the recovery volume, e.g. by holding down the
> right keys at startup.) The preboot volume information is typically set
> by Startup Disk in System Preferences.
It does appear that preboot is the mechanism that Apple uses to decide
which volume boots, but it also appears it has the information that EFI
needs to list all the bootable volumes (except recovery, but that was a
deliberate choice by Apple).
> Since EFI programs can present a user interface, if Apple wanted they
> could have the EFI jumpstart driver present an interface resembling the
> Startup Manager which let you pick between multiple bootable volumes
> inside the container. They probably don't think it is worth confusing
> the user by adding a second layer of bootable volume selection at
> startup for something which very few users would bother setting up, and
> those who do can use Startup Disk in System Preferences to change the
> boot volume.
There is no second layer at all, it simply lists each bootable volume.
> You _can_ have a drive which has multiple APFS partitions (containers)
> each with a single bootable volume, and pick between those containers in
> the Startup Manager. This prevents free space sharing between the APFS
> volumes because they are in different APFS containers.
Which is why I didn't do it. And I'm not sure it works since I've never
tried it. However, multiple bootable volumes in one container absolutely
does work.
> Multiple bootable volumes in separate partitions, yes.
> You can't have multiple bootable volumes inside a single APFS container
> (partition) and expect to be able to pick among them at startup of the
> computer (while EFI is the only software running).
You absolutely can, and I've had this setup since the Mojave beta.
--
And east is east and west is west and if you take cranberries and stew
them like applesauce they taste much more like prunes than rhubarb does.
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2018-11-19 02:27 -0500 |
| Message-ID | <8BtID.254008$mJ1.14500@fx24.iad> |
| In reply to | #119585 |
On 2018-11-19 00:46, Lewis wrote: > Nope. My startup drive has six APFS volumes on it > > /dev/disk2 (synthesized): > #: TYPE NAME SIZE IDENTIFIER > 0: APFS Container Scheme - +959.3 GB disk2 > Physical Store disk1s2 > 1: APFS Volume Jaka 625.4 GB disk2s1 > 2: APFS Volume Preboot 45.4 MB disk2s2 > 3: APFS Volume Recovery 1.0 GB disk2s3 > 4: APFS Volume VM 2.1 GB disk2s4 > 5: APFS Volume Mojave 13.7 GB disk2s5 > 6: APFS Volume High 11.9 GB disk2s7 > > If I hold down the option key at boot I am offered a choice between > Jaka (Current Mojave with all the user data), Mojave (has 10.14.0 with > no user data), and High (10.13.$LATEST) with no user data. This means that EFI has loaded a program from your boot drive and it is that program which has the knoeldge to parse an APFS container and list APFS volumes which appear to be bootable. This is beyond the capabilities of EFI. > It does appear that preboot is the mechanism that Apple uses to decide > which volume boots, but it also appears it has the information that EFI > needs to list all the bootable volumes (except recovery, but that was a > deliberate choice by Apple). Once EFI reads blocks from the boot drive and branches to it, it ceases to run because it is that program which is running. That program has access to EFI services (such as obtaining hardware config and primitive access to a display). > There is no second layer at all, it simply lists each bootable volume. But that isn't the firmware EFI running at that point. EFI firmware only knows about GPT partitions, and if one is called EFI, it expects that partition to have FAT32 format. It has no knowledge of HFS or APFS. Apple's EFI knows to look for a block address and block count located in block 0 at a specific location which allowes it to fetch blcoks into memory and branch to it (aka: the OS bootloader). It doesn't know that whart it is actually loading is a intermediate boot manager which then scans what js available on that drive and enables decryption if one volume is encrypted.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2018-11-19 11:42 -0500 |
| Message-ID | <psup5h$s75$1@dont-email.me> |
| In reply to | #119586 |
On 2018-11-19 07:27:00 +0000, JF Mezei said: > This means that EFI has loaded a program from your boot drive and it is > that program which has the knoeldge to parse an APFS container and list > APFS volumes which appear to be bootable. > > This is beyond the capabilities of EFI. It's quite possible to modify EFI to support additional file systems beyond FAT. Out of the box, EFI supports FAT12, FAT16 and FAT32 (FAT28). Apple implemented those modifications in their firmware, as there are no FAT partitions on existing macOS disks, partitions which would otherwise be required for an EFI bootstrap. It's also possible to have a transitional bootstrap implemented, where EFI searches for a GUID of a FAT partition and then finds and loads a binary from that FAT partition and that binary then chains to a separate volume structure, though that too gets dicy. But Apple didn't do that. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | dempson@actrix.gen.nz (David Empson) |
|---|---|
| Date | 2018-11-20 13:23 +1300 |
| Message-ID | <1nyjfdg.1hv789t1vxto1uN%dempson@actrix.gen.nz> |
| In reply to | #119585 |
Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > In message <1nyiqcn.1rpsrwgn7nqxdN%dempson@actrix.gen.nz> David Empson > <dempson@actrix.gen.nz> wrote: > > The EFI firmware is unaware of volumes inside the APFS container. > > Right. Except it isn't right given what you say below. EFI's Startup Manager application is apparently showing multiple volumes inside an APFS container. > > That means if you have a single APFS container with mulitple bootable > > volumes inside it, the EFI Startup Manager (option key at startup) > > cannot offer those volumes to you, because it doesn't kwow they exist. > > Wrong. > > > It will show a single icon and name for the APFS container. > > Nope. My startup drive has six APFS volumes on it > > /dev/disk2 (synthesized): > #: TYPE NAME SIZE IDENTIFIER > 0: APFS Container Scheme - +959.3 GB disk2 > Physical Store disk1s2 > 1: APFS Volume Jaka 625.4 GB disk2s1 > 2: APFS Volume Preboot 45.4 MB disk2s2 > 3: APFS Volume Recovery 1.0 GB disk2s3 > 4: APFS Volume VM 2.1 GB disk2s4 > 5: APFS Volume Mojave 13.7 GB disk2s5 > 6: APFS Volume High 11.9 GB disk2s7 > > If I hold down the option key at boot I am offered a choice between > Jaka (Current Mojave with all the user data), Mojave (has 10.14.0 with > no user data), and High (10.13.$LATEST) with no user data. Thanks for the heads up and corrections. Clearly I'm missing some information. Apple's document on APFS refers to a single "EFI jumpstart driver" for the container and evidence points to that being in the Preboot volume, but I'm wondering where it fits into the Startup Manager puzzle. This is mostly of academic interest, and difficult to test without a machine in the right state, but here's what I've (now) confirmed for my own edification: I set up an external drive with a single APFS partition/container with three bootable APFS volumes (one Mojave, cloned from the original software that came with my 2018 Mac Mini; the other two are fresh installs of 10.13.6 without any updates). As explained by Lewis, the Startup Manager does show all three of those volumes, and it does that on all my 2012 and later Macs, even the ones which have never been upgraded beyond Sierra. All those Macs have had the latest security updates installed, which included firmware updates matching the firmware installed by 10.14.1. My 2011 MacBook Pro (unable to boot Mojave but has been running High Sierra) also shows all three volumes in Startup Manager. Its firmware is somewhat out of date (July 2018, from 10.13.6 but I haven't installed the latest security update yet). The capability must have existed for some time prior to that version, since it worked for Lewis with an early Mojave developer beta. My 2009 Mac Mini can't run anything later than El Capitan. Its Startup Manager shows nothing from my APFS-only drive. I have another test drive which contains multiple bootable macOS versions up to 10.13 in separate HFS+ partitions, plus one APFS partition/container with a single bootable 10.14 volume. The 2009 Mac Mini's Startup Manager shows all the HFS+ partitions (including the 10.12 and 10.13 ones it can't boot) but doesn't show anything for the APFS partition. This implies the ability to see APFS volumes at all in the Startup Manager requires a firmware update, which this Mac never got because Apple never released that firmware for a Mac too old to boot High Sierra. What I can't narrow down from my own computers (without a lot more digging) is exactly where Startup Manager support for multiple volumes in an APFS container is implemented: it might have been added in a firmware update, or the firmware might just need basic APFS support, and the APFS multi-volume support comes from a loaded EFI driver. -- David Empson dempson@actrix.gen.nz
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2018-11-19 21:57 -0500 |
| Message-ID | <OKKID.690429$cL2.332255@fx43.iad> |
| In reply to | #119594 |
On 2018-11-19 19:23, David Empson wrote: > Except it isn't right given what you say below. EFI's Startup Manager > application is apparently showing multiple volumes inside an APFS > container. Does the startup manager have anything more than text VGA console ? If so the startup manager runs code loaded from disk, not firmware code. aka: putting this into a "console mode" context (hidden on Macs), it means the startup manager appears after EFI firmware has begun the "boot" process (load code from disk and branch to it). Machines built prior to APFS being designed would have no knowledge about APFS and ability to decide that the GPT partition contains an APFS container which itself contains the following APFS volumes that are bootable. Yet, the Startuyp Manager on those machines does that. It must be code that is part of the boot process and not part of EFI firmware.
[toc] | [prev] | [next] | [standalone]
| From | dempson@actrix.gen.nz (David Empson) |
|---|---|
| Date | 2018-11-20 16:28 +1300 |
| Message-ID | <1nykn4g.hu7ekw3xspluN%dempson@actrix.gen.nz> |
| In reply to | #119596 |
JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2018-11-19 19:23, David Empson wrote: > > > Except it isn't right given what you say below. EFI's Startup Manager > > application is apparently showing multiple volumes inside an APFS > > container. > > Does the startup manager have anything more than text VGA console ? Have you never booted a Mac while holding down the Option key? The Startup Manager is entirely graphical, showing a row of icons for bootable volumes, with names underneath. It has changed appearance and features slightly over the years. The modern version dynamically resizes icons, truncates names, and lets you navigate with keyboard or mouse/trackpad. The Startup Manager predates Apple's use of EFI: the first version was for PowerPC Macs running Open Firmware, around the time of the PowerMac G4 (AGP Grahpics), iMac G3 (DVI) and PowerBook G4 (Firewire). > If so the startup manager runs code loaded from disk, not firmware code. Bzzzt. Try again. How can a Startup Manager be loaded from disk at a point where no disk is connected to the computer? On a Mac with no drives, you can still bring up the Startup Manager via the Option key but it initially shows no bootable volumes. Plug in an external bootable volume and it appears in the list. The Startup Manager and other screens such as the "folder with question mark" (for no boot disk found) are generated by the firmware. > aka: putting this into a "console mode" context (hidden on Macs) Not "hidden". Nonexistent. There is no text console in the EFI firmware on Intel Macs. Apple uses a modified version of EFI. There was a text console in the firmware for PowerPC Macs (Open Firmware). > it means the startup manager appears after EFI firmware has begun the >"boot" process (load code from disk and branch to it). Wrong. > Machines built prior to APFS being designed would have no knowledge > about APFS and ability to decide that the GPT partition contains an APFS > container which itself contains the following APFS volumes that are > bootable. Yet, the Startuyp Manager on those machines does that. It must > be code that is part of the boot process and not part of EFI firmware. I don't yet know how the Startup Manager finds out about multiple bootable volumes in an APFS container. That is either built into the firmware or achieved via an EFI driver loaded from disk which extends the firmware Startup Manager. -- David Empson dempson@actrix.gen.nz
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2018-11-21 13:24 -0500 |
| Message-ID | <dphJD.1096081$RN2.443580@fx40.iad> |
| In reply to | #119598 |
On 2018-11-19 22:28, David Empson wrote: > Have you never booted a Mac while holding down the Option key? > The Startup Manager predates Apple's use of EFI: The firmware in a PPC mac was totally different and proprietary to Apple. That the statup manager on an 8086 may appear similar in function does not mean it was implemented in the same way. > How can a Startup Manager be loaded from disk at a point where no disk > is connected to the computer? On a Mac with no drives, OK, touché. I hadn't thought of that. I have to wonder how it is done since EFI standards don't provide for a GUI. And you're correct, if it is able to parse through an APFS volume to find bootable media, then it must have APFS knowledge. However, consider a case when the startup manager is an EFI application. As such the EFI itself still doesn't need to understand APFS. This may be semantics, but consider a case where machine boots itself after a power failure. This would be an EFI only process where it reads block 0 of default boot volume type of stuff at which point it doesn't need knowledge of the file system (as per the APFS reference manual). But, if the startup manager is available without any disks, then it must be stored in firmware. So I was wrong on that. Whether it is part of EFI or an EFI application does have important distinctions though. > Not "hidden". Nonexistent. There is no text console in the EFI firmware > on Intel Macs. Apple uses a modified version of EFI. Text consoles are provided on many types of server machines. They are considered EFI applications. There is a big distinction though between EFI booting, and in doing so seeks to boot an OS, and loading an application with no intentions to boot. (such as loading a text console or a hardware test programme) The startup manager is invoked as part of a boot process which is switched to a different boot file (sicha s startup manager EFO programme) because of keys being pressed on keyboard. As such, the EFI has begun to transfer control to the file/program it has loaded with no expectation of a return to it. > I don't yet know how the Startup Manager finds out about multiple > bootable volumes in an APFS container. That is either built into the > firmware or achieved via an EFI driver loaded from disk which extends > the firmware Startup Manager. Must be firmware. Your experiment of booting startup manager with no disks, and then seeing AFPS volumes appear when you plug the drive in would mean the Startup Manager code would already have the knowledge to parse that newly connected drive. In another message, you mentioned the byte code interpreter. When IA64 (Itanic) came out, they decided EFI programs should be in x86 code, so on platforms that were not X86, the EFI had a built-in X86 translator into IA64 instructions. The EFI programs would be compiled with X86 output. (as opposed to a Java environment where it has its own instruction set which is then interpreted). Not sure how this works on a native X86 box where the EFI need not translate the EFI programs. But even if it did translate them, it doesn't mean it would control them. EFI would simply provide the environment for the EFO program to run. In a boot scenario without any expectation that control would return to it since the EFO program would load the OS boot file and branch to it. While EFI no longer run the logic, its syystem calls remain available for the booting OS. There are services to provide hardware config, read the boot disk, and output to screen with primitive text interface (and access keyboard). So when you boot -V , the text display you see is text which OS-X asks EFO to display before OS-X has setup its own graphics software. Simularly, the initial part of the boot reads the system disk using EFI drivers until OS-X itself has loaded its disk drivers. (I learned the hard way with Yosemite which disabled a kernel extension I had, so boot would hang at the place where OS-X trioed to mount the boot drive itself) With APFS encryption, I am not sure how they worked the early boot sequence in terms of disk access. The EFI boot loader program on disk will ask for the password and be able to read the OS' boot blocks using EFI disk reading and decrypt the data. But once it branches to the OS instance's BOOT.EFI, not sure how long the OS-X relies on the EFIO disk driver (and then manually decrtpt stuff) before loading its own disk driver that reads and decrupts.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web