Re: installer: disk crypto: always correct root disk default
On Sun, 2 Apr 2023 at 1:52 PM, Klemens Nanni wrote:
> For install, the root disk defaults to the first available [sw]d* disk.
>
> The new encryption question creates a softraid volume for you, which is
> obviously to be used as root disk.
>
> But on systems with multiple disks, the next one available may be another.
>
> Available disks are: sd0 sd1.
> Encrypt the root disk? (disk, 'no' or '?' for details) [no] sd0
> ...
> Available disks are: sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd1] ?
> sd0: VirtIO, Block Device (5.0G)
> sd1: VirtIO, Block Device (5.0G)
> sd2: OPENBSD, SR CRYPTO, 006 (5.0G)
> Available disks are: sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd1] sd1
>
> 'Encrypt the root disk?' is asked if and only if no softraid volume is
> assembled at that time, which means whatever volume exists afterwards is
> the intended root disk.
>
> Save and use it as default for the root question if set.
>
> This is nicely contained and has no behaviour change except for interactive
> crypto installs which now nail the default regardless of disk setup:
>
> Available disks are: sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd2]
>
> OK?
>
> Index: install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1239
> diff -u -p -r1.1239 install.sub
> --- install.sub 2 Apr 2023 00:58:07 - 1.1239
> +++ install.sub 2 Apr 2023 01:20:18 -
> @@ -310,6 +310,11 @@ get_softraid_chunks() {
> bioctl $_device 2>/dev/null | sed -n 's/.*<\(.*\).>$/\1/p'
> }
>
> +# Return list of softraid volumes.
> +get_softraid_volumes() {
> + bioctl softraid0 | sed -n 's/^softraid0.*\(sd[0-9]*\).*/\1/p'
> +}
> +
> # Return disk devices found in hw.disknames.
> get_dkdevs() {
> scan_disknames "${MDDKDEVS:-/^[sw]d[0-9][0-9]* /s/ .*//p}"
> @@ -2398,7 +2403,7 @@ is_rootdisk() {
>
> # Get global root information. ie. ROOTDISK, ROOTDEV and SWAPDEV.
> get_rootinfo() {
> - local _default=$(get_dkdevs_root) _dkdev
> + local _default=${CRYPTOVOLUME:-$(get_dkdevs_root)} _dkdev ml
> local _q="Which disk is the root disk? ('?' for details)"
>
> while :; do
> @@ -3078,7 +3083,7 @@ encrypt_root() {
>
> # Do not even try if softraid is in use already,
> # e.g. auto-assembled at boot or done in (S)hell.
> - [[ -z $(get_softraid_chunks) ]] || return
> + [[ -z $(get_softraid_volumes) ]] || return
>
> while :; do
> echo "Available disks are: $(get_dkdevs | sed
> 's/^$/none/')."
> @@ -3109,6 +3114,9 @@ __EOT
> done
>
> CRYPTOCHUNK=$_chunk
> + # No volumes existed before asking, but we just created one.
> + # Save it for later as sane root disk default.
> + CRYPTOVOLUME=$(get_softraid_volumes)
> }
>
> do_install() {
> @@ -3581,6 +3589,7 @@ NIFS=0
> export PS1="$MODE# "
> PUB_KEY=/etc/signify/openbsd-${VERSION}-base.pub
> CRYPTOCHUNK=
> +CRYPTOVOLUME=
> ROOTDEV=
> ROOTDISK=
> SETDIR="$VNAME/$ARCH"
>
>
Re: preliminary kabylake support for inteldrm
On 09/28/17 08:43, Peter N. M. Hansteen wrote: On 09/27/17 18:41, Peter N. M. Hansteen wrote: On 09/27/17 00:07, Robert Nagy wrote: Hi This is an updated diff for preliminary kabylake support for 6.2, this needs extensive testing on all inteldrm variants. This diff is also in snapshots now so please, test, test test! Installed the latest snapshot (OpenBSD 6.2 (GENERIC.MP) #114: Wed Sep 27 01:19:45 MDT 2017), now running the machine from http://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html with no xorg.conf, and it looks wonderful so far! Preserved dmesg and xdpyinfo output: https://home.nuug.no/~peter/20170927_dmesg_greyhame.txt https://home.nuug.no/~peter/20170927_xdpyinfo_greyhame.txt Following up on this, I see that there is a firmware load failure error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/kbl_dmc_ver1.bin (-22) I took my SSD from an older Dell (Optiplex 790) to a new Dell (Optiplex 7050). Before the recent snapshot I was without graphics. With the recent snapshot - I've got graphics (thank you), but I do see the same message (above) as Peter, but haven't noticed anything obviously amiss because of it (Google says: "DMC provides additional graphics low-power idle states. It provides capability to save and restore display registers across these low-power states independently from the OS/Kernel.") But I was getting these messages (below) /before/ the recent snapshot, when the SSD was in a different machine: Sep 22 09:52:50 devssd /bsd: error: [drm:pid46438:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A ... so these atomic update messages don't seem to be new (and didn't see anything not working because of them). Thanks, Richard. and later, repeated at intervals [Wed Sep 27 21:39:21] peter@greyhame:~/div/hailmary/2016$ grep drm /var/log/messages Sep 27 19:44:35 greyhame /bsd: error: [drm:pid46498:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A Sep 27 21:37:09 greyhame /bsd: error: [drm:pid46498:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A Then again, I'm not sure what if any functionality is impacted here - P
Re: printf(3) wording
On 11/18/15 07:16, Amit Kulkarni wrote: jan is right, interpretation is the correct word. Interpolate is using something to do mathematically. the program is going to work on, so interpret... Interpolate is a word I picked up when learning Perl and to do with strings, not just mathematically: https://en.wikipedia.org/wiki/String_interpolation I'm not arguing for either word being better, I'll leave that to others.
Re: wol for xl(4)
On 17/06/2011, at 8:40 PM, Thomas Gerlach wrote: > hello, > > i just confirmed wol is working with freebsd 8.2 standard installation on my > box. So it must be the openbsd xl driver, which isn't working properly. > i will try to fix it starting next week. :) > > > cheers, > > thomas > Hi, Thomas. This is the same point I reached with Stefan. http://marc.info/?l=openbsd-tech&m=130337513320970&w=2 I didn't have the coding smarts to progress any further ... Thanks.
Re: pf.conf, comments and continuation lines
On 15/06/2011, at 10:16 PM, Jason McIntyre wrote: > On Wed, Jun 15, 2011 at 11:09:35AM +0100, Stuart Henderson wrote: >> On 2011/06/15 10:03, Jason McIntyre wrote: >>> so i guess we're looking for a text only (i.e. no example) solution. >>> here is another stab. >> >> nicely crafted words, this is good. ok sthen@ >> >> I'll handle the other copies of this if you like. >> > > i think it makes sense to do this in one commit, so i'd appreciate if > you could do this one too. > > one thing for consideration: in the text below, i swithered whether > "the comment takes effect" would read better as "the comment will take > effect". i'm not sure which would be clearer (or read better) for most > people. > > jmc > How about "the comment is effective until the end of the entire block."? >>> Index: pf.conf.5 >>> === >>> RCS file: /cvs/src/share/man/man5/pf.conf.5,v >>> retrieving revision 1.494 >>> diff -u -r1.494 pf.conf.5 >>> --- pf.conf.5 20 May 2011 22:57:20 - 1.494 >>> +++ pf.conf.5 15 Jun 2011 09:02:10 - >>> @@ -62,9 +62,14 @@ >>> Some example rulesets. >>> .El >>> .Pp >>> +The current line can be extended over multiple lines using a backslash >>> +.Pq Sq \e . >>> Comments can be put anywhere in the file using a hash mark >>> .Pq Sq # , >>> and extend to the end of the current line. >>> +Take care when commenting out text which is part of a multi-line block: >>> +the comment takes effect until the end of the entire block. >>> +.Pp >>> Additional configuration files can be included with the >>> .Ic include >>> keyword, for example:
Re: wol for xl(4)
On 19/04/2011, at 8:57 PM, Stefan Sperling wrote: > On Tue, Apr 19, 2011 at 02:03:54AM +0200, Tobias Ulmer wrote: >> On Mon, Apr 18, 2011 at 10:17:33AM +0200, Stefan Sperling wrote: >>> On Mon, Apr 18, 2011 at 04:18:01AM +0200, Tobias Ulmer wrote: On Sun, Apr 17, 2011 at 11:05:38AM +0200, Stefan Sperling wrote: > On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote: >> This is an attempt to add wol support to xl(4). >> >> Unfortunately, while I have an xl(4) card to test with none of the >> motherboards I have will do WOL with it since they all lack an >> on-board WOL connector :( >> >> So test reports are needed. >> Please also check whether WOL is disabled by default. > > I haven't received any test reports yet. The (commited) diff has no effect on my onboard xl(4). The hardware supports this (BIOS setting checked): http://support.dell.com/support/edocs/systems/dvol/en/vol_mt/SETUP.HTM#Wakeup %20On%20LAN >>> >>> Please elaborate on "no effect". >>> >>> Does WOL work at all? Or does it not work at all? >> >> I've done tests with the integrated NIC and one in a PCI slot connected >> to the WOL connector. WOL does not work in any configuration I've tried. >> >>> Can it be enabled from the BIOS but not, independently, from ifconfig? >> >> The BIOS has 3 WOL settings: Off, Integrated NIC, WOL Connector. I've >> configured this according to which card was tested. WOL still did not >> work. >> >>> Can it be disabled via ifconfig even if enabled in the BIOS? >> >> I've tried enabling WOL using ifconfig for the PCI NIC and set the BIOS >> to WOL mainboard connector. WOL did not work. >> >> shutdowns were always done with "halt -p" >> >> No idea what else I could do... > > Thanks. I'll have to take another look at the FreeBSD driver so. > > Can you check whether WOL works with FreeBSD? > For the archives/if anyone is following this: I have dug out an i386 Dell with an on-board xl card. FreeBSD 8.2 WOL works; the changes in OpenBSD so far do not. Machine remotely poked with arp -W Thanks.
Re: rdist times out but will not die
On 24/03/2011, at 4:06 PM, Steven R. Gerber wrote: > On 3/20/2011 2:07 PM, Steven R. Gerber wrote: >> I want to do local/remote mirror/backup (or should that be local-mirror >> / offsite-backup). >> So a two-part question: >> 1. Even if there is a timeout, shouldn't the job/process exit? >> * * >> rdist@thedump: thedump: /mnt/mirror2/public/read_only/movies: chown from >> rdist:operator to cdripper:operator >> rdist@thedump: thedump: >> /mnt/mirror2/public/read_only/movies/The_Thomas_Crown_Affair_1999: chown >> from rdist:operator to root:operator >> rdist@thedump: >> /mnt/stripe2/public/read_only/movies/The_Thomas_Crown_Affair_1999/THOMAS_CROW N_AFFAIR_16X9.md5: >> updating >> rdist@thedump: >> /mnt/stripe2/public/read_only/movies/The_Thomas_Crown_Affair_1999/THOMAS_CROW N_AFFAIR_16X9.iso: >> installing >> rdist@thedump: LOCAL ERROR: Response time out >> rdist@thedump: updating of rdist@thedump finished >> $ ps -ax|grep rdist >> 26025 ?? I 0:00.00 tee /var/log/rdist/2011-03-20 >> 11059 ?? I 0:00.01 rdist -f /etc/Distfile >> 28446 ?? I 0:22.99 rdist: update rdist@thedump (rdist) >> 7795 ?? I 1:10.32 ssh -l rdist thedump r >> 13045 p0 S+ 0:00.00 grep rdist >> * * >> 2. I know that they happen from time to time. How can I avoid/prevent >> timeouts? The default is 900 sec AKA 15 min? How can this happen >> between two local machines? How big is the file? Sure it is not *something* like this? https://www-304.ibm.com/support/docview.wss?uid=isg1IY85396 client.c 869 /* 870 * Parse size 871 */ 872 size = (off_t) strtol(cp, (char **)&cp, 10); *Maybe* that strtol() should be strtoll()? Anyway, don't I think tech@ is necessarily the list for this - misc@ or file a bug. And/or keep debugging & digging - the source is all there! HTH. >> >> Thanks. >> >> >> > > Sorry to reply to myself, but I really need help with this. > The movies always timeout via rdist. If I transfer the movies myself > via sftp then there are no timeouts. > The processes continue to accumulate everyday unless I manually kill them. > I know that I am missing something. Should I edit /etc/daily to turn on > debugging? > > Please/Thanks.
