Dockstar, currently on U-Boot 2016.05-tld-1, with the Jessie rootfs 4.40.

Want to upgrade to the Buster rootfs. And might as well go to the latest kernel at the same time. But I am confused about the instructions.

My envs are mostly the default from U-Boot 2016.05-tld-1, and per the instructions thats the same for 2017.07.

The kernels only have a step 4 that includes either A, modify envs or B from stock u-boot (I guess Seagate/Pogoplug?), but this is for kernels before and after the 5.2.9 rootfs which didn't have these steps.

Do I need to do step 4A envs for my setup, U-Boot 2016.05-tld-1 with a fresh rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi, and immediately going to linux-5.5.1-kirkwood-tld-1-bodhi?

cde,

> Dockstar, currently on U-Boot 2016.05-tld-1, with
> the Jessie rootfs 4.40.
>
> Want to upgrade to the Buster rootfs. And might as
> well go to the latest kernel at the same time. But
> I am confused about the instructions.
>
> My envs are mostly the default from U-Boot
> 2016.05-tld-1, and per the instructions thats the
> same for 2017.07.
>
> The kernels only have a step 4 that includes
> either A, modify envs or B from stock u-boot (I
> guess Seagate/Pogoplug?), but this is for kernels
> before and after the 5.2.9 rootfs which didn't
> have these steps.

Correct. No need to do Step 4 (append the DTB to uImage) if you already are running my new u-boot builds (2016.05-tld-1 is new) with my released rootfs Debian-4.4.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2.

> Do I need to do step 4A envs for my setup, U-Boot
> 2016.05-tld-1 with a fresh rootfs
> Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi, and
> immediately going to
> linux-5.5.1-kirkwood-tld-1-bodhi?

You can create the new rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi and boot with it without changing anything.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 03/02/2020 04:12AM by bodhi.

Done so and it worked. But I'm having a few issues with the Buster image.

One, it takes a while to boot, and on top of that, SSHD takes 4 minutes after boot to kick in. This may be an entropy thing. The latest kernel seems to have helped by a minute.

And NTP isn't picking up the correct time for over 5 minutes.

Last, I'm getting kswapd0 alerts like https://forum.doozan.com/read.php?2,92059,92074

Never seen either of the 3 on the jessie build.

Oh, and procps isn't running? So sysctl doesn't run or doesn't read /etc/sysctl.conf or sysctl.d on boot.

Update: Looks like previous versions had a ntpdate updating the clock before ntpd took over? I can't find an instance of ntpdate on the buster /etc files.



Edited 1 time(s). Last edit at 03/02/2020 11:44PM by cde.

cde,

> One, it takes a while to boot, and on top of that,
> SSHD takes 4 minutes after boot to kick in. This
> may be an entropy thing. The latest kernel seems
> to have helped by a minute.

Yes, it is the entropy problem.

> And NTP isn't picking up the correct time for over
> 5 minutes.
>
> Last, I'm getting kswapd0 alerts like
> https://forum.doozan.com/read.php?2,92059,92074

You need to create a swap file on the new rootfs.

> Update: Looks like previous versions had a ntpdate
> updating the clock before ntpd took over? I can't
> find an instance of ntpdate on the buster /etc
> files.

Right, ntpdate is obsolete. Only ntp should be used.

Upgrade the kernel, upgrade Debian, and boot a few times. It should boot faster after you use this rootfs a while. You can reinstall ntpdate back if you like (I would not, because it has been deprecated, so will cause problem later).

If the clock update is too slow to your liking, then you should try different ntp servers in /etc/ntp.conf. Something such as using the Debian default pool.ntp.org servers.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Part of the ntpdate depreciation is that they removed the ifuphooks that would set the time once the interface goes up.

I worked around this by having the following in rc.local:

service ntp stop
ntpd -gq
service ntp start

ntpd -gq is a one shot set and quit command for ntpd. You have to have the service stopped so that it can bind to the ports. Then you can turn it back on. Not as good as having it happen earlier, networking comes up after 2 minutes while ntpd and rc.local kick in after 4 minutes.

I'll look into a swap file, but it sucks that after a few years without one, now I need one. And I guess I'll just deal with the reboot to ssh time. At this point I'm back to working successfully.

cde,

> ntpd -gq is a one shot set and quit command for
> ntpd. You have to have the service stopped so that
> it can bind to the ports. Then you can turn it
> back on. Not as good as having it happen earlier,
> networking comes up after 2 minutes while ntpd and
> rc.local kick in after 4 minutes.

ntpd -gq is always executed implicitly when ntp starts.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

The ntp init files show that it starts as -g.

-gq is set time, ignoring any large drift, and immediately quit. If it does it implicitly, then it doesn't work. Messages show that it's binding to the right interfaces by that point, so networking is up. By bringing it down, running the one shot, and bringing it back up, the time is updated immediately instead of 10+ minutes past boot.

Side note, on the rootfs, what's the owner and group supposed to be for /var/lib/ntp/ ? It's currently 100:106 which is uuidd : ntp instead of 105:106 for ntp : ntp . As such ntpd can't write to the drift file specified in /etc/ntp.conf. Is this by design to prevent flash wear?

drwxr-xr-x  2 uuidd ntp     4.0K May 12  2012 /var/lib/ntp/

Mar  3 19:28:52 DockStar daemon.err ntpd[1803]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied

> The ntp init files show that it starts as -g.

That seems to be different from the maintainer expected.

> Side note, on the rootfs, what's the owner and
> group supposed to be for /var/lib/ntp/ ? It's
> currently 100:106 which is uuidd : ntp instead of
> 105:106 for ntp : ntp . As such ntpd can't write
> to the drift file specified in /etc/ntp.conf. Is
> this by design to prevent flash wear?

Not by my design. I took the Debian debootstrap default from way back (it was Debian squeeze when I created this roots using debootstrap).

When you apt-get upgrade ntp, it might report new settings that current Debian distro wants.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Per https://salsa.debian.org/pkg-ntp-team/ntp/-/blob/master/debian/ntp.postinst the current and the previous few versions even before Jessie should have had

chown ntp:ntp /var/lib/ntp /var/log/ntpstats

The config is not set to use /var/log/ntpstats so the wrong uid isn't an issue, but it is set to use the drift file, and that's likely part of my clock issue in buster. My jessie backups do show /var/lib/ntp with valid ownership and the ntp.drift was being used.

Of course that means an hourly write of a 7 byte file to the flash drive. Bugfix needed for the buster rootfs or non-issue?

Couldn't you link the file to /tmp?

Unless your tmp is non-volatile, it would defeat the purpose. drift file is used to help ntpd sync faster as the service starts, and that's typically after reboot.

The bug fix would be to correct the folder permissions on the buster rootfs, not a custom configuration of the drift file location.