Re: RCS file ownership?
Sorry, but my mail goes further.
It says it should be correct. For some definition of correct. It
should either behave somehow for a logical reason, or it should behave
in the historical fashion. Or once the historical behaviour is looked
at, if there is an argument that is wrong, then it should be changed
with logic about "this is an improvement" backing the argument.
I think it is wrong to document how *this* rcs implimentation behaves,
without comparing it against others.
My guess is 50% that the others don't unlink, but rewrite the file.
And the changes it might require to be compatible are not substantial.
At most a 20 line diff, to a few programs in the family.
athom...@athompso.net wrote:
> Thank you for that detail!
>
> Addressing this one corner case would require substantial changes, I think.
> Not worth
> it, in my opinion.
>
> I think it would be worthwhile describing the multi-user mode of operation of
> RCS in
> the manual, as it's currently completely absent/omitted. Patch coming soon,
> maybe
> tomorrow if I can make time.
>
> -Adam
>
> On Apr. 29, 2020 21:28, Theo de Raadt wrote:
>
> athom...@athompso.net wrote:
>
> > Heh, good point. Didn't even occur to me because as it happens, I am
> > running as root and would like to not change the ownership.-Adam
> > On Apr. 29, 2020 13:32, Anders Andersson wrote:
> >
> > On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson
> > wrote:
> > >
> > > When I use co(1) with "-l" to check out a file (and/or "ci -l") is
> > there
> > > any way to preserve file ownership and *not* have it reset to the
> > user
> > > running co(1) or ci(1)?
> > > I don't see anything in rcs(1), co(1) or ci(1) that even mentions
> > the
> > > fact that the file will wind up owned by the user running the
> > command.
> > > Ideas? Pointers to documentation?
> >
> > How could it possibly do anything else unless you always run co as
> > root?
>
> Our rcs tools do:
>
> 52628 co RET kbind 0
> 52628 co CALL unlink(0x7f7ed1f3)
> 52628 co NAMI "ls.c"
> 52628 co RET unlink -1 errno 2 No such file or directory
> 52628 co CALL open
> (0x7f7ed1f3,0x601,0100444 |S_IRGRP|S_IROTH|S_IFREG>)
> 52628 co NAMI "ls.c"
> 52628 co RET open 4
> 52628 co CALL kbind(0x7f7ec908,24,0x847da2a816b5d817)
>
> Which appears to be this:
>
> else {
> (void)unlink(dst);
>
> if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode)) == -1)
> err(1, "%s", dst);
>
> I don't know what older or gnu rcs do. I guess whichever way this is done
> it must balance concerns between atomicity of concurrent reads performed
> by earlier processes, versus replacement of a potentially active file.
>
> If the latter is chosen, it would unlink(), perform the open more
> carefully, check that it is in the right place with fstat, but then
> it needs some work for ftruncate (to get rid of extra file contents
> at the end). If the open() failed, it might try an unlink followed by
> open()?
>
> Other rcs implimentations need to be checked. It is better if they work
> the same.
>
Re: RCS file ownership?
Thank you for that detail!
Addressing this one corner case would require substantial changes, I
think. Not worth it, in my opinion.
I think it would be worthwhile describing the multi-user mode of
operation of RCS in the manual, as it's currently completely
absent/omitted. Patch coming soon, maybe tomorrow if I can make time.
-Adam
On Apr. 29, 2020 21:28, Theo de Raadt wrote:
athom...@athompso.net wrote:
> Heh, good point. Didn't even occur to me because as it happens, I
am
> running as root and would like to not change the ownership.-Adam
> On Apr. 29, 2020 13:32, Anders Andersson
wrote:
>
> On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson
> wrote:
> >
> > When I use co(1) with "-l" to check out a file (and/or "ci -l")
is
> there
> > any way to preserve file ownership and *not* have it reset to
the
> user
> > running co(1) or ci(1)?
> > I don't see anything in rcs(1), co(1) or ci(1) that even
mentions
> the
> > fact that the file will wind up owned by the user running the
> command.
> > Ideas? Pointers to documentation?
>
> How could it possibly do anything else unless you always run co
as
> root?
Our rcs tools do:
52628 co RET kbind 0
52628 co CALL unlink(0x7f7ed1f3)
52628 co NAMI "ls.c"
52628 co RET unlink -1 errno 2 No such file or directory
52628 co CALL
open(0x7f7ed1f3,0x601,0100444)
52628 co NAMI "ls.c"
52628 co RET open 4
52628 co CALL kbind(0x7f7ec908,24,0x847da2a816b5d817)
Which appears to be this:
else {
(void)unlink(dst);
if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode)) == -1)
err(1, "%s", dst);
I don't know what older or gnu rcs do. I guess whichever way this is
done
it must balance concerns between atomicity of concurrent reads
performed
by earlier processes, versus replacement of a potentially active
file.
If the latter is chosen, it would unlink(), perform the open more
carefully, check that it is in the right place with fstat, but then
it needs some work for ftruncate (to get rid of extra file contents
at the end). If the open() failed, it might try an unlink followed
by
open()?
Other rcs implimentations need to be checked. It is better if they
work
the same.
Re: RCS file ownership?
athom...@athompso.net wrote:
> Heh, good point. Didn't even occur to me because as it happens, I am
> running as root and would like to not change the ownership.-Adam
> On Apr. 29, 2020 13:32, Anders Andersson wrote:
>
> On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson
> wrote:
> >
> > When I use co(1) with "-l" to check out a file (and/or "ci -l") is
> there
> > any way to preserve file ownership and *not* have it reset to the
> user
> > running co(1) or ci(1)?
> > I don't see anything in rcs(1), co(1) or ci(1) that even mentions
> the
> > fact that the file will wind up owned by the user running the
> command.
> > Ideas? Pointers to documentation?
>
> How could it possibly do anything else unless you always run co as
> root?
Our rcs tools do:
52628 co RET kbind 0
52628 co CALL unlink(0x7f7ed1f3)
52628 co NAMI "ls.c"
52628 co RET unlink -1 errno 2 No such file or directory
52628 co CALL
open(0x7f7ed1f3,0x601,0100444)
52628 co NAMI "ls.c"
52628 co RET open 4
52628 co CALL kbind(0x7f7ec908,24,0x847da2a816b5d817)
Which appears to be this:
else {
(void)unlink(dst);
if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode)) == -1)
err(1, "%s", dst);
I don't know what older or gnu rcs do. I guess whichever way this is done
it must balance concerns between atomicity of concurrent reads performed
by earlier processes, versus replacement of a potentially active file.
If the latter is chosen, it would unlink(), perform the open more
carefully, check that it is in the right place with fstat, but then
it needs some work for ftruncate (to get rid of extra file contents
at the end). If the open() failed, it might try an unlink followed by
open()?
Other rcs implimentations need to be checked. It is better if they work
the same.
Re: boot drive hide and seek on new notebook
On 2020-04-29, f.holop wrote:
> f.holop - Wed, 29 April 2020 at 14:57:46
>> i'll try to make a similar test with some linux live distro to see
>> if i get similar results.
>
> I have tested MX linux install ISO that also doubles as a Live distro.
>
> In the end it's apples and oranges because I use the openbsd USB key to
> boot the system from the internal drive ("boot hd1a:bsd"),
> while the Live Linux boots from the USB key and runs from RAM (so more
> like a beefed up "boot hd0a:bsd.rd")...
>
> Nevertheless linux detects the nvme drive in all cases (entering
> BIOS/not entering BIOS).
Of course, because by that point it's running its own nvme driver
in the kernel, not relying on bios/uefi.
> This inspired me to let the openbsd USB key boot up all the way when the
> internal drive was not detected in the first stage boot. The internal
> drive was right there in `dmesg`, `sysctl hw`, `disklabel`, etc. I
> could mount it while running off of the USB key.
That's totally expected. As with Linux, by that point it's running
its own nvme driver in the kernel.
> "Elemental." With all these reboots I have worked out how this sorry
> excuse for a BIOS's boot order mechanism works, and it's horrible:
sounds pretty standard tbh :)
Re: VLAN syntax in hostname.vlanxxx
On 2020-04-29, Denis Fondras wrote: > On Wed, Apr 29, 2020 at 09:58:27PM +0200, Lars Bonnesen wrote: >> On an obsd 6.6, I use the vmx device, but the syntax: >> inet 172.18.11.9 255.255.255.252 NONE vlandev vmx2 description VLAN703 >> > > vlandev is not supported any more. > You have to use parent and vnetid, check man ifconfig. > > The aliases have been kept, but the specific thing is you must now specify the vlan id whereas before it was automatically set to "the numeric part of the interface name".
Re: boot drive hide and seek on new notebook
f.holop - Wed, 29 April 2020 at 14:57:46
> i'll try to make a similar test with some linux live distro to see
> if i get similar results.
I have tested MX linux install ISO that also doubles as a Live distro.
In the end it's apples and oranges because I use the openbsd USB key to
boot the system from the internal drive ("boot hd1a:bsd"),
while the Live Linux boots from the USB key and runs from RAM (so more
like a beefed up "boot hd0a:bsd.rd")...
Nevertheless linux detects the nvme drive in all cases (entering
BIOS/not entering BIOS).
This inspired me to let the openbsd USB key boot up all the way when the
internal drive was not detected in the first stage boot. The internal
drive was right there in `dmesg`, `sysctl hw`, `disklabel`, etc. I
could mount it while running off of the USB key.
I think this makes the case less clear cut... Who knows what the BIOS
is doing with/without entering, but the kernel has no difficulties
seeing the drive in either case, just like linux.
Astute readers will notice that there is discrepancy in my story:
I said I can't change the boot order without entering the BIOS, but
entering the BIOS makes the internal disk show up. How could I have
this then:
probing: pc0 mem[636k 1928M 14304M]
disk: hd0
"Elemental." With all these reboots I have worked out how this sorry
excuse for a BIOS's boot order mechanism works, and it's horrible:
It is not possible to select a generic slot like "USB media" or such.
Only when the device is bootable and is recognized by the BIOS, only
then does it show up in the dropdown and can be put in the first boot
slot. Even then, it is remembered between reboots only until it's not
removed from the port.
It is between these types of reboots (not entering the BIOS, but the USB
key is still "remembered") that the system is booting from USB (without
entering the BIOS), however the internal drive does not show up in first
stage boot.
I wonder how many of the newer ASUS notebooks behave like this and if
this is the future, or just some frankenstein experiment...
When clearing the secure boot keys disappears from the BIOS menus,
I guess it's game over.
-f
--
Re: VLAN syntax in hostname.vlanxxx
That did it... thanks! On Wed, Apr 29, 2020 at 10:42 PM Sebastian Benoit wrote: > Lars Bonnesen(lars.bonne...@gmail.com) on 2020.04.29 21:58:27 +0200: > > In earlier obsd versions I have been having success with this in > > hostname.vlan703 > > inet 172.18.11.9 255.255.255.252 NONE vlandev em5 description VLAN703 > > > > On an obsd 6.6, I use the vmx device, but the syntax: > > inet 172.18.11.9 255.255.255.252 NONE vlandev vmx2 description VLAN703 > does > > not work as expected. If I do a tcpdump, I can find the packages reaching > > vmx2, but they are never passed on to vlan703 > > > > How to to if I have configured a trunk on a switch, I want to configure > say > > VLAN id 703 on a vmx device? > > Between OpenBSD 6.1 and 6.2 the syntax for configuring VLAN interfaces was > changed. > > You now have to use the 'vnetid' and 'parent' options, as well as 'up'. > > # cat /etc/hostname.vlan7 > vnetid 7 parent em0 > up > lladdr random > # ifconfig vlan7 > vlan7: flags=8843 mtu 1500 > lladdr 60:e8:d7:0d:10:6d > index 7 priority 0 llprio 3 > encap: vnetid 7 parent: em0 > groups: vlan > status: active > >
Re: installation hangs/crashes on 2007 iMac
(To misc@ readers, this reply includes an earlier reply from me that inadvertently wasn't copied to the list). Allan Streib writes: > multifred writes: > >> To boot OpenBSD you have to use the internal SATA or ATA devices. > > Thanks, I will try that. Was about to report that a 6.7 snapshot (with > bootx64 3.50) also didn't work (at least when booting from USB flash > drive). Yes, using the install67.iso worked. Thanks again! I wasn't on a network; the built-in wifi was not recognized, but the install went normally otherwise. I'll plug in an ethernet cable later and try running the fw_update. >> EFI-Booting (32-bit on my setup) works fine. To speed up boot time >> after the installation of OpenBSD, use the Mac-proprietary bless(1) >> command [2] once (by booting some MacOS or MacOS installation >> medium). It writes your preferred boot volume into NV-RAM, thus skips >> the boot volume search (grey boot screen after turning the machine on) >> and continues booting OpenBSD immediately. > > Is bless required even if there is only one bootable volume? I don't > have any need for MacOS on this machine. As you indicated, there's a delay (perhaps 30 seconds), but with only OpenBSD on the disk it does eventually boot up on its own without being "blessed." I can live with that. Allan
Re: VLAN syntax in hostname.vlanxxx
Lars Bonnesen(lars.bonne...@gmail.com) on 2020.04.29 21:58:27 +0200: > In earlier obsd versions I have been having success with this in > hostname.vlan703 > inet 172.18.11.9 255.255.255.252 NONE vlandev em5 description VLAN703 > > On an obsd 6.6, I use the vmx device, but the syntax: > inet 172.18.11.9 255.255.255.252 NONE vlandev vmx2 description VLAN703 does > not work as expected. If I do a tcpdump, I can find the packages reaching > vmx2, but they are never passed on to vlan703 > > How to to if I have configured a trunk on a switch, I want to configure say > VLAN id 703 on a vmx device? Between OpenBSD 6.1 and 6.2 the syntax for configuring VLAN interfaces was changed. You now have to use the 'vnetid' and 'parent' options, as well as 'up'. see ifconfig(8) and https://www.openbsd.org/faq/upgrade62.html: The vlan(4) and svlan(4) specific configuration options in ifconfig(8) and hostname.if(5) have been deprecated in favour of the generic parent and vnetid handling. The vlan, vlandev, and -vlandev options are now deprecated in favour of vnetid, -vnetid, parent, and -parent when using ifconfig(8) or in hostname.if(5) configuration files. Use of the vlan option must be replaced with vnetid. Because VLAN tag 0 is invalid according to the relevant VLAN specifications, the vnetid option does not accept 0 as a valid network identifier. To use VLAN tag 0 on the wire the vnetid can be unconfigured with -vnetid. Use of vlandev and -vlandev must be replaced with parent and -parent respectively. Unlike vlan and vlandev, vnetid and parent do not implicitly bring the vlan interface up. Similarly, the vlan option is no longer implied by the interface's minor when it is not explicitly set. ifconfig(8) no longer outputs a vlan specific status line, or separate vnetid and parent lines. The vnetid and parent lines have been merged into a single encap line containing the VLAN tag and parent information. An example of the changes to a vlan(4) configuration file and the ifconfig(8) output is below. Before the changes: # cat /etc/hostname.vlan7 vlandev em0 # vlan 7 and up are implied lladdr random # ifconfig vlan7 vlan7: flags=8843 mtu 1500 lladdr 70:a7:3a:75:da:2d index 7 priority 0 llprio 3 vlan: 7 parent interface: em0 vnetid: 7 parent: em0 status: active After the changes: # cat /etc/hostname.vlan7 vnetid 7 parent em0 up lladdr random # ifconfig vlan7 vlan7: flags=8843 mtu 1500 lladdr 60:e8:d7:0d:10:6d index 7 priority 0 llprio 3 encap: vnetid 7 parent: em0 groups: vlan status: active > And while we are at it, what if the switch is an access port? > > Regards, Lars. > --
Re: VLAN syntax in hostname.vlanxxx
On Wed, Apr 29, 2020 at 09:58:27PM +0200, Lars Bonnesen wrote: > On an obsd 6.6, I use the vmx device, but the syntax: > inet 172.18.11.9 255.255.255.252 NONE vlandev vmx2 description VLAN703 > vlandev is not supported any more. You have to use parent and vnetid, check man ifconfig.
VLAN syntax in hostname.vlanxxx
In earlier obsd versions I have been having success with this in hostname.vlan703 inet 172.18.11.9 255.255.255.252 NONE vlandev em5 description VLAN703 On an obsd 6.6, I use the vmx device, but the syntax: inet 172.18.11.9 255.255.255.252 NONE vlandev vmx2 description VLAN703 does not work as expected. If I do a tcpdump, I can find the packages reaching vmx2, but they are never passed on to vlan703 How to to if I have configured a trunk on a switch, I want to configure say VLAN id 703 on a vmx device? And while we are at it, what if the switch is an access port? Regards, Lars.
Re: RCS file ownership?
Heh, good point. Didn't even occur to me because as it happens, I am running as root and would like to not change the ownership.-Adam On Apr. 29, 2020 13:32, Anders Andersson wrote: On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson wrote: > > When I use co(1) with "-l" to check out a file (and/or "ci -l") is there > any way to preserve file ownership and *not* have it reset to the user > running co(1) or ci(1)? > I don't see anything in rcs(1), co(1) or ci(1) that even mentions the > fact that the file will wind up owned by the user running the command. > Ideas? Pointers to documentation? How could it possibly do anything else unless you always run co as root?
Re: RCS file ownership?
On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson wrote: > > When I use co(1) with "-l" to check out a file (and/or "ci -l") is there > any way to preserve file ownership and *not* have it reset to the user > running co(1) or ci(1)? > I don't see anything in rcs(1), co(1) or ci(1) that even mentions the > fact that the file will wind up owned by the user running the command. > Ideas? Pointers to documentation? How could it possibly do anything else unless you always run co as root?
RCS file ownership?
When I use co(1) with "-l" to check out a file (and/or "ci -l") is there any way to preserve file ownership and *not* have it reset to the user running co(1) or ci(1)? I don't see anything in rcs(1), co(1) or ci(1) that even mentions the fact that the file will wind up owned by the user running the command. Ideas? Pointers to documentation? Thanks, -Adam
Re: bad AGGREGATOR, AS 0 not allowed
On Wed, Apr 29, 2020 at 05:45:30PM +0200, Marko Cupać wrote: > Hi, > > on 6.6-RELEASE amd64, (sys)patched up to 019_smtpd_exec, I am noticing > these: > > Apr 29 17:23:33 bgp1 bgpd[42338]: neighbor IP.ADD.RE.SS (desc): bad > AGGREGATOR, AS 0 not allowed, attribute discarded > > My bgpd.conf is almost default, announcing my AS to two upstream peers. > > I wrote to my peer, they said they are not sending me AS 0, and to clear my > session. > > After 'bgpctl neighbor desc clear' I'm still getting these messages. > > Is this related to: > [https://marc.info/?l=openbsd-tech=156510627921885=2] > > Can I safely disregard this, and wait for next release for these messages to > disappear? At the moment this warning as not been removed, so you will see it even in the next release. It has indeed todo with the fact that AS 0 is not allowed even in the AGGREGATOR attribute. Now your neighbor is sending you such an attribute which indicates that their routers do not handle RFC7607 correctly. At the moment there are a handful of prefixes in the DFZ that are sent with an AGGREGATOR attribute that has AS 0 and this is what triggers. You normally get the error on the initial sync. I wanted to make the error better an include ASPATH / prefix but at the time this problem happens this information is not available. Time to look at this again so that the finger pointing is more helpful. -- :wq Claudio
bad AGGREGATOR, AS 0 not allowed
Hi, on 6.6-RELEASE amd64, (sys)patched up to 019_smtpd_exec, I am noticing these: Apr 29 17:23:33 bgp1 bgpd[42338]: neighbor IP.ADD.RE.SS (desc): bad AGGREGATOR, AS 0 not allowed, attribute discarded My bgpd.conf is almost default, announcing my AS to two upstream peers. I wrote to my peer, they said they are not sending me AS 0, and to clear my session. After 'bgpctl neighbor desc clear' I'm still getting these messages. Is this related to: [https://marc.info/?l=openbsd-tech=156510627921885=2] Can I safely disregard this, and wait for next release for these messages to disappear? Thank you in advance, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: installation hangs/crashes on 2007 iMac
I have an Macmini2,1 from mid 2007 with similar specs [1] and presumably similar firmware. I tested a whole lot of combinations for booting it and came to the following conclusion: To boot OpenBSD you have to use the internal SATA or ATA devices. That means you need to use the CD/DVD-drive as installation medium (installXX.iso). Alternatively you can replace the CD/DVD-drive with a hard drive and use that as installation medium. Booting from USB only works for MacOS X. EFI-Booting (32-bit on my setup) works fine. To speed up boot time after the installation of OpenBSD, use the Mac-proprietary bless(1) command [2] once (by booting some MacOS or MacOS installation medium). It writes your preferred boot volume into NV-RAM, thus skips the boot volume search (grey boot screen after turning the machine on) and continues booting OpenBSD immediately. --multifred [1]: https://everymac.com/systems/apple/mac_mini/specs/mac-mini-core-2-duo-2.0-specs.html [2]: https://ss64.com/osx/bless.html
Re: boot drive hide and seek on new notebook
Stuart Henderson - Wed, 29 April 2020 at 12:24:50 > The boot loader only has access to what bios/uefi makes available, > it looks like it isn't setting up your nvme device if you boot from USB > unless you go through that menu. There isn't much OpenBSD can do about this. i'll try to make a similar test with some linux live distro to see if i get similar results. -f --
Re: Sound is good on OpenBSD
On Wed, Apr 29, 2020 at 11:46:06AM +0200, Moises Simon wrote: > On Tue, Apr 28, 2020 at 03:38:58PM -0500, Abel Abraham Camarillo Ojeda wrote: > > I think increasing -b option in sndiod helps to prevent audio jumping, I > > hear music with a local mpd with music directory over nfs, plus a lot of > > firefox and chrome and hear no jumps , etc > > > > regards > > I can confirm. For me setting -b 8640 stops the audio jumping. > > Thanks Abel. > what devices are you using? azalia? usb?
Re: boot drive hide and seek on new notebook
On 2020-04-28, f.holop wrote: > hi, > > i am trying to run openbsd on a very new notebook and it kind of works. > > i have taken away some space from win10 and created a partition, and the > installation went well. atm i dont want to create a boot menu, so i > just insert a usb key with openbsd installed on it, and i select the > kernel from the internal drive. however... this is a normal boot: > > > probing: pc0 mem[636k 1928M 14304M] > disk: hd0 >>> OpenBSD/amd64 BOOTX64 3.50 > boot> machine diskinfo > DiskBlkSiz IoAlign SizeFlags Checksum > hd0 512 0 3919MB 0x2 0xa3b9b69 Removable > > > the internal nvme disk is nowhere to be seen. > but i have just installed openbsd on it... > > another boot, this time i enter the BIOS, and it has a menu to select > the boot device manually, so i select the USB key: > > > probing: pc0 mem[636k 1928M 14304M] > disk: hd0 hd1 >>> OpenBSD/amd64 BOOTX64 3.50 > boot> machine diskinfo > DiskBlkSiz IoAlign SizeFlags Checksum > hd0 512 0 3919MB 0x2 0xa3b9b69 Removable > hd1 512 4 953GB 0x2 0x122409ee > boot> b hd1a:/bsd > ... > > and success. but unless i enter the bios, the internal drive is not in > that list. i think the installation process went well because i also > had to enter the BIOS to select the usb key to boot from. The boot loader only has access to what bios/uefi makes available, it looks like it isn't setting up your nvme device if you boot from USB unless you go through that menu. There isn't much OpenBSD can do about this.
Re: boot drive hide and seek on new notebook
On April 29, 2020 12:06:02 PM GMT+03:00, "f.holop" wrote: >Chris Bennett - Tue, 28 April 2020 at 23:03:32 >> Some BIOS's require you to select legacy boot and legacy boot before >> UEFI in order to boot off of a USB. Also might need to turn off boot >> security option, too. >> >> A lot of BIOS's suck nowadays. Who woulda thought that examining the >> BIOS would become a purchasing decision? > >couple of points i did not go into (but i plan to make a longer >writeup): > >1. legacy boot is NOT an option in this BIOS. the ASUS knowledge >base site says this option was removed for any Coffee Lake or later >CPU, >so it's not coming back. For me this is an issue only because my old >notebook cannot boot UEFI, and this new one cannot boot legacy :D >so i cannot share the usb key between them. > >2. secure boot MUST be disabled. no way to boot a usb key otherwise >without mucking with platform keys or such. In this particular (full >GUI) BIOS with a "dumb mode" and an "advanced mode", there is no >"disable secure boot" option and the installed secure keys must be >NUKED >for secure boot to be disabled. > >I agree that BIOS is very important, but it's impossible to use it as a >purchasing decision. It is never indicated in the tech specs, and i >havent bought a notebook in a shop where i MIGHT be allowed to enter >the >bios in more than a decade. Even then, an update might change anything >in a flash of an eye. > > >Besides sharing information in my email I was kind of asking if maybe >the boot program needs some changes to be able to detect the boot drive >even without entering the BIOS (which seems to initialize something >that >makes the detection work as it is). > >To reiterate: if the boot order is changed in BIOS and saved, at >startup >the USB key boots up, but sees only itself. If I enter the BIOS and >use >the boot order menu there to select the usb key, it boots up and sees >the internal drive as well. > >-f Have you tried to edit the windows boot loader and somehow boot the openBSD? I have done that approach ages ago where grub was on second disk and I made windows boot loader (legacy mode) to boot from the next disk and then grub kicked in. Of course , you can try the opposite - somehow openBSD to boot the windows :) Best Regards, Strahil Nikolov
Re: Sound is good on OpenBSD
On Tue, Apr 28, 2020 at 03:38:58PM -0500, Abel Abraham Camarillo Ojeda wrote: > I think increasing -b option in sndiod helps to prevent audio jumping, I > hear music with a local mpd with music directory over nfs, plus a lot of > firefox and chrome and hear no jumps , etc > > regards I can confirm. For me setting -b 8640 stops the audio jumping. Thanks Abel.
Re: boot drive hide and seek on new notebook
Chris Bennett - Tue, 28 April 2020 at 23:03:32 > Some BIOS's require you to select legacy boot and legacy boot before > UEFI in order to boot off of a USB. Also might need to turn off boot > security option, too. > > A lot of BIOS's suck nowadays. Who woulda thought that examining the > BIOS would become a purchasing decision? couple of points i did not go into (but i plan to make a longer writeup): 1. legacy boot is NOT an option in this BIOS. the ASUS knowledge base site says this option was removed for any Coffee Lake or later CPU, so it's not coming back. For me this is an issue only because my old notebook cannot boot UEFI, and this new one cannot boot legacy :D so i cannot share the usb key between them. 2. secure boot MUST be disabled. no way to boot a usb key otherwise without mucking with platform keys or such. In this particular (full GUI) BIOS with a "dumb mode" and an "advanced mode", there is no "disable secure boot" option and the installed secure keys must be NUKED for secure boot to be disabled. I agree that BIOS is very important, but it's impossible to use it as a purchasing decision. It is never indicated in the tech specs, and i havent bought a notebook in a shop where i MIGHT be allowed to enter the bios in more than a decade. Even then, an update might change anything in a flash of an eye. Besides sharing information in my email I was kind of asking if maybe the boot program needs some changes to be able to detect the boot drive even without entering the BIOS (which seems to initialize something that makes the detection work as it is). To reiterate: if the boot order is changed in BIOS and saved, at startup the USB key boots up, but sees only itself. If I enter the BIOS and use the boot order menu there to select the usb key, it boots up and sees the internal drive as well. -f --
Re: Sound is good on OpenBSD
On Tue, Apr 28, 2020 at 3:21 PM Consus wrote: > On Tue, Apr 28, 2020 at 03:01:15PM +0300, Yury Grebenkin wrote: > > OpenBSD gives a better sound experience on my machine than several > > Linux distributions I have used and FreeBSD. Just want to say thank > > you to all the people involved and state the fact that OpenBSD does > > make a difference. > Blood virgin sacrifice tends to make FLAC even better. Maybe. But not for me. -- Yury https://yvgrebenkin.wordpress.com/
