On Sat, Jan 13, 2024 at 11:47:44AM +0100, Christian Gut wrote:
>
>
> > On 13. Jan 2024, at 10:03, Christian Gut <[email protected]> wrote:
> >
> >
> >
> >> On 13. Jan 2024, at 00:58, Theo de Raadt <[email protected]> wrote:
> >>
> >> 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.
> >
> > Any thing I could do my self or provide information to improve that?
> > I think I have one other of these machines where it seems to behave
> > differently.
>
> I might have found the reason:
>
> octeon seems to boot that special “BOOT” kernel, which has a ram disk. Inside
> that small boot process in
>
> src/sys/arch/octeon/stand/rdboot/disk.c
> disk_init() calls disk_proberoot()
>
> all possible filesystems are iterated over and are mounted to /mnt. This is
> done to find the root filesystem. I would assume inside that boot kernel, the
> time had been set to the ramdisk time. As it mounts the root filesystem
> temporarily, the time of that filesystem gets set back to the time that had
> been set from the ramdisk kernel.
>
> But that mount uses MNT_RDONLY?
>
> A lot of assumptions, maybe you can confirm with deeper understanding.
In that file there's also disk_open() that does an r/w mount. That
mount is used and later unmounted buy disk_close() (as the code in
kexec() shows). So the superblock gets updated with the ramdisk root
time, assuming the rest of your analysis is correct.
-Otto
