in one command due to wrong file size limit. Do not use bootcode size
to calculate partsize limit.
Also add report message about successful partcode writing.
Reported by: Trond Endrestøl
MFC after: 2 weeks
This flag indicates that the user wishes to use the GELIBOOT feature to boot from a fully encrypted root file system.
Currently, GELIBOOT does not support key files, and in the future when it does, they will be loaded differently.
Due to the design of GELI, and the desire for secrecy, the GELI metadata does not know if key files are used or not, it just adds the key material (if any) to the HMAC before the optional passphrase, so there is no way to tell if a GELI partition requires key files or not.
Since the GELIBOOT code in boot2 and the loader does not support keys, they will now only attempt to attach if this flag is set. This will stop GELIBOOT from prompting for passwords to GELIs that it cannot decrypt, disrupting the boot process
PR: 208251
Reviewed by: ed, oshogbo, wblock
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D5867
program without listening to the devd socket for all events. Define
two new pseudo variables $*, the entire event from devctl and $_,
the entire event without the type character, since it might be easier
to use in some circumstances.
Among other things this gives us the ability to find outthe syscall number of a dynamically loaded syscall that has a dynamicly allocated vector number.
MFC after: 1 week
Sponsored by: Panzura inc.
The standards in the QSFP diagnostics area are not clear when the
additional measurements are present or not. Use a valid temperature
reading as an indicator for the presence of voltage and TX/RX power
measurements.
MFC after: 1 week
Sponsored by: Mellanox Technologies
Tested by: Netflix
Differential Revision: https://reviews.freebsd.org/D5391
Reviewed by: gallatin
This displays the IE names in ifconfig but it doesn't yet decode things.
Submitted by: Idwer Vollering <vidwer@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3782
strlcpy(3) null terminates but does not zero-fill the buffer, so would
leave beind any portion of the previous volume label longer than the
new one.
Note that tunefs only allows -L args up to a length of MAXVOLLEN-1, so
the stored label will be null-terminated (whether or not required by
UFS).
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
After calling the cap_init(3) function Casper will fork from it's original
process, using pdfork(2). Forking from a process has a lot of advantages:
1. We have the same cwd as the original process.
2. The same uid, gid and groups.
3. The same MAC labels.
4. The same descriptor table.
5. The same routing table.
6. The same umask.
7. The same cpuset(1).
From now services are also in form of libraries.
We also removed libcapsicum at all and converts existing program using Casper
to new architecture.
Discussed with: pjd, jonathan, ed, drysdale@google.com, emaste
Partially reviewed by: drysdale@google.com, bdrewery
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4277
These are no longer needed after the recent 'beforebuild: depend' changes
and hooking DIRDEPS_BUILD into a subset of FAST_DEPEND which supports
skipping 'make depend'.
Sponsored by: EMC / Isilon Storage Division
If one does 'ifconfig tap create name blah', it will return error because the
'name' command doesn't properly populate the request sent to ioctl(...). The
'description' command has the same bug, and is also fixed with this patch.
If one does 'ifconfig tap create mtu 9000 name blah', it DOES work, but 'tap0'
(or other sequence number) is echoed, instead of the expected 'blah'. (assuming
the name change actually succeeded)
Submitted by: Marie Helene Kvello-Aune <marieheleneka@gmail.com>
Differential Revision: https://reviews.freebsd.org/D5341
of their individual packages based on MK_foo evaluation.
There is no intent to split inet/inet6 or other similar
combinations for package creation, since they are created
during build time.
Noticed/prodded by: lidl
Sponsored by: The FreeBSD Foundation
