Re: time keeping fallback mechanics during reboot on octeon
I suspect this is due to how powerpc64 and octeon boot. Their bootblocks are a special kernel called BOOT which mounts the ffs filesystem diretly. I suspect during the transition to loading GENERIC.MP something wrong happens with the on-disk time information, which misleads the next kernel.
Installing OpenBSD amd64 on UTM on Intel Mac?
Hi. Since there's some uncertainty around the future of VMware Fusion on the Mac, I've decided to switch to UTM (with QEMU under the covers) -- but I can't seem to get OpenBSD .isos (7.3 or 7.4) to boot -- instead, I get dumped into the UEFI shell, which is a dead end. I've done a number of searches (on the mailing list and the web in general), and all of the results are for running the ARM64 port on the M-series Macs -- but my target machine has an Intel CPU. Can anyone provide some insight into running OpenBSD under UTM on a Mac? Thanks.
Re: time keeping fallback mechanics during reboot on octeon
On Fri, Jan 12, 2024 at 07:15:43PM +0100, Christian Weisgerber wrote: > Otto Moerbeek: > > > http://man.openbsd.org/octrtc seems to suggest EdgeRouter does not have > > an RTC. A dmesg should give more certainty. > > I think the original poster is aware of this. > > If I understand correctly, he expects that on reboot the system > clock is restored to the last value from before the reboot (so only > a minute or so is lost), and that this value is transported by a > time stamp on the root filesystem. Apparently that doesn't happen. Which is strange as the code to fall back to fs time is MI. That's why I asked for a dmesg, it might give a clue of what is going on. -Otto
Re: time keeping fallback mechanics during reboot on octeon
Otto Moerbeek: > http://man.openbsd.org/octrtc seems to suggest EdgeRouter does not have > an RTC. A dmesg should give more certainty. I think the original poster is aware of this. If I understand correctly, he expects that on reboot the system clock is restored to the last value from before the reboot (so only a minute or so is lost), and that this value is transported by a time stamp on the root filesystem. Apparently that doesn't happen. -- Christian "naddy" Weisgerber na...@mips.inka.de
We desire more map format compatibility for OPENSOURCE game. C
sourceforge.net/p/chaosesqueanthology/tickets/2/ We desire more map format compatability so our code can be used using more maps. We have found C++ OPENSOURCE (RMS I used the word you do not like: because you won't help me get contributors at all) code to load UNREAL format 3d maps. But our engine is in C and we do not know C++ and ALSO: Anyone who does more than one significant thing in the engine per year goes crazy. And we already did 1 significant thing this year (more map compat). For instance: Lord Havoc became "lady havock" That is insane and white. A bad thing. He worked on the engine too much. Cloudwalk had 2 mental breakdowns. Again: same issue. Worked on the engine too much. So you see: we make sure we don't work on the engine too much. So we need you to help. However we have been told that we will NEVER get any contributors because we are not "GIRLS NOT BRIDES" dick-chopping faggots. And if that is the case: if you will not help us because we are NOT faggots: then you have made an enemy. We hope the muslims win and re-institute marraige of little girls to men (ashia was a young girl in the bukari hadiths: which you white, and white adjacant faggots do not like) (Sahih Bukhari 5:58:236, Sahih Bukhari 7:62:64,Sahih Bukhari 8:73:151) YHWH allows child brides. It's called virgin marraige. You opensource scum hate that. You support dick-chopping and faggotry. You support feminism. You are an enemy of... MMLLLE (as you call us all) (Devarim 22, 28. greek, hebrew, latin (padia, na'ar, puella)) (moses was a crying na'ar when pulled from the river: yes white fucks: na'ar means child) So if you will not help us beause we do not subscribe to your FAGGOT beliefs. If that is the reason. Then you have made an enemy. In real life. FUCK YOU. And FUCK your FreeSoftware faggot coven. Lying piece of fucking shit. Marry Little Girls. Also we'd like Unreal map support in this engine.
Re: time keeping fallback mechanics during reboot on octeon
On Fri, Jan 12, 2024 at 04:47:06PM +0100, Christian Gut wrote: > Hi Otto, > > > > On 12. Jan 2024, at 15:52, Otto Moerbeek wrote: > > > > On Fri, Jan 12, 2024 at 02:35:47PM +0100, Christian Gut wrote: > > > >> Hi, > >> > >> Could somebody point me to documentation or tell me where OpenBSD gets the > >> time from, when the system has no RTC and ntpd is not working? > >> > >> I am using an EdgeRouter / octeon and at every reboot, the date/time gets > >> reset to the exact same date. > >> > >> I tried to read the source code of boot(9) and inittodr(9). I can see, > >> that there seems to be a fallback to some timestamp that comes from the > >> filesystem. Maybe when the root filesystem is mounted as of > >> ffs_mountroot() for example. But my understanding did not go so far to > >> identify from which file, directory, superblock or other filesystem > >> metadata the information really comes from. > >> > >> It seems to me, that either my system is broken or something on octeon > >> does not work correctly for this fallback to happen correctly. > >> > >> Kind Regards, > >> Christian > >> > > > > When there is no RTC or reading it fails, the "last written" timestamp > > of the root filesystem is used. > > Somehow this does not seem to work on that system. > > > What are you observing exactly? You did not tell any details. How > > does ntpd fail? Please show some logs (/var/log/daemon should have some > > lines). > > I know why ntpd does not work. The system operates in a very constrained > environment. No ntp servers reachable, no https reachable. > > I am okay if the time stays roughly the same during reboot. Like the same > day, even only some days off is okay. But on that 7.4 system it always gets > reset to Oct 9, 2023. > > I checked the root filesystem. It is clean after reboot. > When the system runs and time has been corrected the following output > suggests, that fallback from the filesystem should work correctly, but it > doesnt: > > # file -s /dev/rsd0a > /dev/rsd0a: Unix Fast File system [v2] (big-endian) last mounted on /, last > written at Fri Jan 12 16:45:42 2024, clean flag 0, readonly flag 0, number of > blocks 441848, number of data blocks 425527, number of cylinder groups 5, > block size 16384, fragment size 2048, average file size 16384, average > number of files in dir 64, pending blocks to free 0, pending inodes to free > 0, system-wide uuid 0, minimum percentage of free blocks 5, TIME optimization > > Anything I could check? > Maybe it has to do with the way Octeon boots? > > Kind Regards, > Christian http://man.openbsd.org/octrtc seems to suggest EdgeRouter does not have an RTC. A dmesg should give more certainty. If you have ann RTC that is read but gives a wrong value you should see a consistency check messages from inittodr(). So can you show the dmesg? It contains the relevant kernel messages at the end and allow us to see if you actually have an RTC. -Otto
Re: time keeping fallback mechanics during reboot on octeon
Hi Otto, > On 12. Jan 2024, at 15:52, Otto Moerbeek wrote: > > On Fri, Jan 12, 2024 at 02:35:47PM +0100, Christian Gut wrote: > >> Hi, >> >> Could somebody point me to documentation or tell me where OpenBSD gets the >> time from, when the system has no RTC and ntpd is not working? >> >> I am using an EdgeRouter / octeon and at every reboot, the date/time gets >> reset to the exact same date. >> >> I tried to read the source code of boot(9) and inittodr(9). I can see, that >> there seems to be a fallback to some timestamp that comes from the >> filesystem. Maybe when the root filesystem is mounted as of ffs_mountroot() >> for example. But my understanding did not go so far to identify from which >> file, directory, superblock or other filesystem metadata the information >> really comes from. >> >> It seems to me, that either my system is broken or something on octeon does >> not work correctly for this fallback to happen correctly. >> >> Kind Regards, >> Christian >> > > When there is no RTC or reading it fails, the "last written" timestamp > of the root filesystem is used. Somehow this does not seem to work on that system. > What are you observing exactly? You did not tell any details. How > does ntpd fail? Please show some logs (/var/log/daemon should have some > lines). I know why ntpd does not work. The system operates in a very constrained environment. No ntp servers reachable, no https reachable. I am okay if the time stays roughly the same during reboot. Like the same day, even only some days off is okay. But on that 7.4 system it always gets reset to Oct 9, 2023. I checked the root filesystem. It is clean after reboot. When the system runs and time has been corrected the following output suggests, that fallback from the filesystem should work correctly, but it doesnt: # file -s /dev/rsd0a /dev/rsd0a: Unix Fast File system [v2] (big-endian) last mounted on /, last written at Fri Jan 12 16:45:42 2024, clean flag 0, readonly flag 0, number of blocks 441848, number of data blocks 425527, number of cylinder groups 5, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 5, TIME optimization Anything I could check? Maybe it has to do with the way Octeon boots? Kind Regards, Christian
Re: time keeping fallback mechanics during reboot on octeon
On Fri, Jan 12, 2024 at 02:35:47PM +0100, Christian Gut wrote: > Hi, > > Could somebody point me to documentation or tell me where OpenBSD gets the > time from, when the system has no RTC and ntpd is not working? > > I am using an EdgeRouter / octeon and at every reboot, the date/time gets > reset to the exact same date. > > I tried to read the source code of boot(9) and inittodr(9). I can see, that > there seems to be a fallback to some timestamp that comes from the > filesystem. Maybe when the root filesystem is mounted as of ffs_mountroot() > for example. But my understanding did not go so far to identify from which > file, directory, superblock or other filesystem metadata the information > really comes from. > > It seems to me, that either my system is broken or something on octeon does > not work correctly for this fallback to happen correctly. > > Kind Regards, > Christian > When there is no RTC or reading it fails, the "last written" timestamp of the root filesystem is used. What are you observing exactly? You did not tell any details. How does ntpd fail? Please show some logs (/var/log/daemon should have some lines). -Otto
time keeping fallback mechanics during reboot on octeon
Hi, Could somebody point me to documentation or tell me where OpenBSD gets the time from, when the system has no RTC and ntpd is not working? I am using an EdgeRouter / octeon and at every reboot, the date/time gets reset to the exact same date. I tried to read the source code of boot(9) and inittodr(9). I can see, that there seems to be a fallback to some timestamp that comes from the filesystem. Maybe when the root filesystem is mounted as of ffs_mountroot() for example. But my understanding did not go so far to identify from which file, directory, superblock or other filesystem metadata the information really comes from. It seems to me, that either my system is broken or something on octeon does not work correctly for this fallback to happen correctly. Kind Regards, Christian
Re: relayd forward with tls
> Em qui., 11 de jan. de 2024 às 13:35, Michael Hekeler
> escreveu:
> >
> > > Jan 9 07:10:24 stable relayd[29792]: relay wwwtls, session 1 (1 active),
> > > fqdn1, 127.0.0.1 -> 127.0.0.1:8080, done, GET -> 127.0.0.1:8080;
> > > Jan 9 07:10:25 stable relayd[28442]: relay wwwtls, session 1 (1 active),
> > > fqdn2, 127.0.0.1 -> 127.0.0.1:8081, done, GET -> 127.0.0.1:8081;
> > > Jan 9 07:10:31 stable relayd[29792]: relay wwwtls2, session 2 (1
> > > active), 0, 127.0.0.1 -> 127.0.0.1:8080, done, GET
> > > Jan 9 07:10:35 stable relayd[28442]: relay wwwtls2, session 2 (1
> > > active), 0, 127.0.0.1 -> 127.0.0.1:8080, done, GET
> >
> > Please examine your log:
> > The first and the second request are processed by "relay wwwtls"
> > The first is tagged "fqdn1" and the second request is tagged "fqdn2"
> > The first is relayed to 127.0.0.1:8080
> > The second is relayed to 127.0.0.1:8081
> > All is fine here :-)
> >
> > Now look to the third and fourth requests.
> > They are both processed by wwwtls2.
> > But they are not tagged (see tag 0) and thats the problem!
> > Because the request stays untagged in the protocol the relay wwwtls2
> > chooses simply the first found forward rule: 127.0.0.1:8080
> >
> > So examine your requests:
> > This is fine: 'curl https://fqdn1'
> > But this not: 'curl https://fqdn1:4430'
> >
> > See the difference?
> >
> > The second sets in HTTP-Header "[HTTP_HOST] => fqdn1:4430"
> > Thats why you should match "fqdn1:4430" in relayd.conf:
> >
> > match request header "Host" value "fqdn1:4430" tag "fqdn1"
> > - or -
> > match request header "Host" value "fqdn1*" tag "fqdn1"
> >
>
> That was exactly the problem.
> I didn't know how to read the logs nor the definition of HTTP_HOST.
Most browsers can show the HTTP-Header.
E.g. in firefox -> developer tools -> network -> just click on any
object and it will show headers (and much more)
Or you can place a simple script in httpd that dumps the header.
In PHP for example you can do: print_r($_SERVER);
What I do is placing a simple C program in /cgi-bin:
#include
int
main(int argc, char *argv[])
{
extern char **environ;
printf("Content-Type: text/plain\n\n");
for (int i = 0; environ[i] != NULL; i++) {
printf("%s\n", environ[i]);
}
}
