Read and write all 4 label instances.

Mistake on dates

boot1 change was committed.

In D25512#563884, @darkfiberiru_gmail.com wrote:

@tsoome Is this purely refactoring or some additional features/improvements as the goal.

We do not want to change IOC list ordering (yet).

In D25324#559399, @jhb wrote:

FWIW, my hope had been to have a single gptboot that does both UFS + ZFS. I don't envy the logic to figure out which one to boot from if both are present though. :) What is the current size bsdinstall uses for freebsd-boot and how long ago has it been 128k?

shield ufs with LOADER_UFS_SUPPORT and do not include ufs support
for gptzfsboot (for now). We still do provide ufs for zfsboot.

In D25312#558449, @jhb wrote:

BTW, one thing this leaves ambiguous is our you can declare variables in the middle of blocks vs at the beginning. That is:

int
foo(int *p, size_t len)
{
    for (size_t i = 0; i < len; i++) {
        int one, two;

        one = p[i] * 2;
        two = bar(&one);
        ...
    }
}

vs.

int
foo(int *p, size_t len)
{
    for (size_t i = 0; i < len; i++) {
        int one = p[i] * 2;
        int two = bar(&one);
        ...
    }
}

I guess this is the second point kib@ made. Do we think relaxing this means it's ok to declare variables at the start of any block or do we think it's fine to define them in the middle of blocks? If the former you would perhaps want to replace the removed sentence with something like:

Place declarations at the start of blocks.

I had read the intention of removing this as being the former and not the latter FWIW.

Thanks:)

Looks good.

rename install_nextboot to install_bootonce

I can not tell much about lua bits, but the rest seems good. I was starting to think if using ! is complicating things (could just use environment variable - those are accessible via kenv), but I'm all good.

In D24920#549167, @oshogbo wrote:

In D24920#549047, @tsoome wrote:

In general, it seems nice. I'd like to see more for description; how the checkpoints would appear, what it means to the boot process, would it mean updates for some manual/handbook? It would nice to refer to zpool, not all people do know where to look for information.

It will appear only if you will if you have checkpoint in the system.
This is small demo: https://youtu.be/Flor6seU080
Please ignore some debug info I already removed them.
Yea probably it is good to update the handbook as well.
I'm never edited the handbook though.

In general, it seems nice. I'd like to see more for description; how the checkpoints would appear, what it means to the boot process, would it mean updates for some manual/handbook? It would nice to refer to zpool, not all people do know where to look for information.

Seems ok.

feedback from cem.

drop crc32 from libsa and use version provided by zlib.

In D24068#529184, @cem wrote:

I’d suggest using the zlib one unless it takes excessive space (bigger precomputed tables, for ex.).

missed stand/uboot/lib/glue.c

In D24041#528666, @greg_unrelenting.technology wrote:

hmm.. The kernel already reads from SPCR (dev/uart/uart_cpu_acpi.c), do we need to feed it duplicate info via comconsole_speed etc.? Or does the i386 legacy bios loader use this info for itself somehow? (I thought env is for the kernel mostly..)

Also, does the setenv("console", "comconsole", 1) mean it's not going to probe vidconsole? (The existence of SPCR should never mean there's no vidconsole ­— I have amd64 and arm64 devices that boot with both an SPCR-defined serial port and a graphical (EFI framebuffer) console at the same time.. )

Wait, that setenv would be overwritten by the ones just after the new biosacpi_detect() call, where the initial_howto & RB_MULTIPLE stuff is.. so is it meant for the case where none of these conditions are true?

In D24041#528666, @greg_unrelenting.technology wrote:

hmm.. The kernel already reads from SPCR (dev/uart/uart_cpu_acpi.c), do we need to feed it duplicate info via comconsole_speed etc.? Or does the i386 legacy bios loader use this info for itself somehow? (I thought env is for the kernel mostly..)

Also, does the setenv("console", "comconsole", 1) mean it's not going to probe vidconsole? (The existence of SPCR should never mean there's no vidconsole ­— I have amd64 and arm64 devices that boot with both an SPCR-defined serial port and a graphical (EFI framebuffer) console at the same time.. )

Wait, that setenv would be overwritten by the ones just after the new biosacpi_detect() call, where the initial_howto & RB_MULTIPLE stuff is.. so is it meant for the case where none of these conditions are true?

feedback from cem.

Suggestions from delphij, thanks!

replace if chain by switch. Print out entire zap_block_type.