- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 18 2017
Oct 13 2017
In D10447#262729, @imp wrote:I wonder why we even have boot1 anymore after these changes.... It's turning into a mini loader.efi. I wonder why we don't just kill it entirely. We don't need boot volume selection (that's supposed to be the EFI boot BIOS's job). We seem to duplicate a lot of code just to load /boot/loader.efi off of UFS or ZFS partitions. However, we could just use loader.efi directly (though some of the root detection code would need to be tweaked). boot1 used to be small, limited and basically unchanging (so updates weren't needed). Now that boot1.efi has hitched its wagon to loader.efi, I wonder why have an extra boot stage that seems to be good at messing up it's partition guessing...
I'm going to go ahead and commit this (after adding back the bits I keep saying were bogusly deleted), but I'm thinking strongly that we consider just moving to loader.efi installed into \efi\freebsd\loader.efi starting in FreeBSD 12 since we'll be able to point efibootmgr at it by then.
Oct 2 2017
Sep 25 2017
Sep 22 2017
In D12466#258441, @tsoome wrote:In D12466#258432, @sbruno wrote:In D12466#258416, @tsoome wrote:This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?
I'm unsure as what I can tell is that the current version of pxeboot won't tftp an MFSroot + Kernel in its current state.
Its possible that I just don't know what the magical incantation is in dhcpd.conf to get it to work right, but tcpdump doesn't show a TFTP req if this code isn't in place.
I can not check the man pxeboot right now, but we have tftp:// prefix etc. I am not sure if the man has received the update, or it is just a,bout the source.
In D12466#258432, @sbruno wrote:In D12466#258416, @tsoome wrote:This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?
I'm unsure as what I can tell is that the current version of pxeboot won't tftp an MFSroot + Kernel in its current state.
Its possible that I just don't know what the magical incantation is in dhcpd.conf to get it to work right, but tcpdump doesn't show a TFTP req if this code isn't in place.
This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?
Sep 21 2017
Sep 18 2017
Sep 14 2017
update after cstyle fix commit.
In D12368#256547, @emaste wrote:The whitespace changes make this a bit hard to read - do you have them as a separate local change that could be committed first?
Sep 13 2017
Sep 12 2017
Sep 11 2017
svn update
Sep 10 2017
Sep 9 2017
Sep 1 2017
Aug 15 2017
Aug 7 2017
Aug 5 2017
use memset instead of initializer
Added missing newlines.
Aug 4 2017
Aug 3 2017
In D10447#245408, @imp wrote:Also, the current change in size for boot1.efi from these changes is going to present problems for the upgrade path since we foolishly chose such small FAT partitions in the past, in violation of the UEFI standard (though to be honest, even at work where we have acres of disk space, I only make 50MB partitions). Some thought may need to be given to the upgrade path since the old installs won't be able to upgrade to the new boot1.efi.
Jul 31 2017
Jul 25 2017
Are there some specific examples about systems needing this?
Jul 20 2017
Jul 1 2017
Jun 29 2017
Jun 28 2017
Use the struct based array.
Jun 23 2017
Jun 16 2017
Jun 13 2017
Comments updated.
Comment wording as suggested by allanjude
In D11174#231247, @allanjude wrote:Looks good to me. What needs to be done for the GELI bits?
Jun 5 2017
In D7600#229139, @delphij wrote:Thanks for the work! (I thought this was already landed last year :)
The change looks good to me (and I appreciate it as a step forward -- duplicated copies of cryptographic code is a big headache for us) overall.
(Totally optional: I wonder if the cryptoboot library could be folded into libstand? Or is there some specific reasons we have to create a new library instead? I'm asking because doing so would avoid building it multiple times, and the license of the source are all BSD compatible.)
Updated to revision 319604.
May 31 2017
In D11007#228039, @kczekirda wrote:It's the only one from pxeloader. I can safety remove the same from iPXE and in summary, during boot chain I have less a half of DHCP request in network. Let's say grain by grain...
May 28 2017
May 27 2017
May 25 2017
ok, that explanation does make sense, LGTM.
IMO if it is really supposed to be default, then the correct place is in /boot/defaults/loader.conf - overloading /boot/loader.conf will only confuse people.