[solved] 2.2.3 nanobsd - packages reinstall after upgrade totally screwed

[jimp]

Yeah, that's the patch that was removed. At least the part of it that actually affected the filesystem.

I'd be interested to know if the problem could be repeated with the disk set to be permanently rw (Diag > NanoBSD, check the box and save)

The switch to RO is a crutch/safety net/etc to give people a warm and fuzzy about disk writes but in truth, aside from maybe a stray package here and there, things won't write to the disk willy-nilly so it's reasonably safe to do. All of the volatile things on NanoBSD are held in RAM disks anyhow, that's where the real danger is with a full install, constant writes to things in /tmp and logs that happen in RAM on NanoBSD.

[doktornotor]

@jimp:

Yeah, that's the patch that was removed. At least the part of it that actually affected the filesystem.

Hmmm… Seems to have pretty bad performance impact on these poor Alix boxes (even with UDMA) :(

@jimp:

I'd be interested to know if the problem could be repeated with the disk set to be permanently rw (Diag > NanoBSD, check the box and save)

Will that stick/work on the post-upgrade reboot? I can do that if that's the case, still lots of boxes left to upgrade where's I'd love to avoid this screw-up.

[jimp]

It varies from CF to CF – I have one CF that is really obnoxious to use with it, on the order of 45s-1m delays on each save. A different card is only ~3-4s, barely worse than without the patch.

If you set the flag in your config then it is consulted before any potential RO switch done at any time, essentially making conf_mount_ro() a no-op.

[doktornotor]

@jimp:

It varies from CF to CF – I have one CF that is really obnoxious to use with it, on the order of 45s-1m delays on each save. A different card is only ~3-4s, barely worse than without the patch.

Well, the cards are what PC Engines sells. This: http://www.pcengines.ch/cf2slc.htm

@jimp:

If you set the flag in your config then it is consulted before any potential RO switch done at any time, essentially making conf_mount_ro() a no-op.

Sounds good.

[jimp]

I have had no luck with those cards over the years. They've all died on me fairly soon.

The "good" card I'm using at the moment is a Sandisk. The one that is awful is a Kingston. Though I have another Kingston that is OK, so… shrug

Generally speaking, the faster the card the less likely you will be to see problems.

[doktornotor]

@jimp:

I have had no luck with those cards over the years. They've all died on me fairly soon.

Hmmm… interested. Out of some ~20, only one is dead here so far. Granted, there's not much done with them. Those Alixes are replacement for shitty ISP-supplied junk, with writing done when new pfS versions comes out, pretty much nothing to write home about in between.

Kingston, I won't touch. Can't even count how many SD cards have dies on me in phones. The higher the was class, the shittier product. Some of them even DoA.  >:( >:( >:(

[xbipin]

i have 3 alix boxes and 4 full installs with 1 of them running on nanobsd and in general i see some issue with package reinstalls

the first alix with nanobsd had cron package and that reinstalled fine on reboot after upgrade
the second nanobsd machine is a full PC with nanobsd on it and that runs squid and cron only, on reboot cron installs fine but squid got stuck on extracting, so i aborted it and reupgraded it and the next time it installed squid just fine and all errors vanished

i dont know y but extracting gets stuck for some packages and for some it works fine

[doktornotor]

@jimp:

I'd be interested to know if the problem could be repeated with the disk set to be permanently rw (Diag > NanoBSD, check the box and save)

Well, good news is that this totally avoided any issue described in the OP on two Alix boxes…  8)

[jimp]

@doktornotor:

@jimp:

I'd be interested to know if the problem could be repeated with the disk set to be permanently rw (Diag > NanoBSD, check the box and save)

Well, good news is that this totally avoided any issue described in the OP on two Alix boxes…  8)

That is good news. I added a note to the changelog doc about that yesterday, I may add a note to the upgrade guide as well.

[robi]

@jimp:

Yeah, that's the patch that was removed. At least the part of it that actually affected the filesystem.

Guys, it really sucks now.
Every config action is delayed 4 seconds now, this is very anti-productive. I'm using brand new SanDisk CF cards, 2015 model, on Supermicro A1SRi-2758F with a CF-to-SATA adapter.
/etc/rc.conf_mount_rw followed by /etc/rc.conf_mount_ro is also 4 to 5 seconds.
Previously it was working in an instant.

I am using exclusively only NanoBSD version in all kinds of setups, Jetway systems, SuperMicro and various thin clients and never had any boot problems or whatsoever.

Can you please consider putting back the patch with a configurable option/system tunable? Because I definitely vote to keep using it.

I see the option of keeping it RW all the time, but NanoBSD exists exactly because of the super-great capability to keep the system RO, and we should really keep relying on that professional feature, as an extra security measure.

[doktornotor]

@robi:

@jimp:

Yeah, that's the patch that was removed. At least the part of it that actually affected the filesystem.

Guys, it really sucks now.
Every config action is delayed 4 seconds now, this is very anti-productive. I'm using brand new SanDisk CF cards, 2015 model, on Supermicro A1SRi-2758F with a CF-to-SATA adapter.
/etc/rc.conf_mount_rw followed by /etc/rc.conf_mount_ro is also 4 to 5 seconds.
Previously it was working in an instant.

I am using exclusively only NanoBSD version in all kinds of setups, Jetway systems, SuperMicro and various thin clients and never had any boot problems or whatsoever.

Can you please consider putting back the patch with a configurable option/system tunable? Because I definitely vote to keep using it.

I see the option of keeping it RW all the time, but NanoBSD exists exactly because of the super-great capability to keep the system RO, and we should really keep relying on that professional feature, as an extra security measure.

Consider yourself lucky with those 4 seconds. It's virtually minutes for some people, plain unusable without switching to permanent RW. Plus this - https://redmine.pfsense.org/issues/4803 – dunno how exactly this helped with filesystem corruption, appears the cure is worse than the disease.

[robi]

Oh shit.

Put back the patch, please, please…

[ShutterBC]

I have noticed that after the first reboot, packages don't seem to fully reinstall until I reboot a second time. Is that normal?

[xbipin]

For most of my boxes packages just don't reinstall, some finally did and the others I had to roll back to 2.2.2 until this package reinstall issue is fixed

[bfeitell]

I have been bitten by this too.  Config changes take about 5 minutes to complete.  I have three nearly identical systems on which the 4GB nanobsd image is written on a brand new HP 8GB v221 USB stick.  Since the 2.2.3 upgrade my systems are pretty well unusable from an administration standpoint.

Is there a workaround for this?  The thread above is not very clear.

Thanks,
Bennett

[doktornotor]

@bfeitell:

Is there a workaround for this?  The thread above is not very clear.

I don't know what's not very clear from the huge hint at the top of the very first post.

[bfeitell]

I'm not sure what you are seeing in the first post, but all I see is a bold faced advisory that explains nothing, and I read every post in the thread.

"tl;dr: Preferably before upgrade, go to Diagnostics - NanoBSD and"

AND nothing.

Might you grace me with a more fulsome explanation?

If making my flash permanently read/write is the workaround you are cryptically alluding to, I'm not keen on it.


[doktornotor]

@bfeitell:

Might you grace me with a more fulsome explanation?

Read the fine thread.

[robi]

@bfeitell:

AND nothing.

Your browser or network might block inline pictures. The next sentence is actually a screenshot of the setting you have to do, but for some reason it doesn't appear in your browser.

[gazoo]

I don't want to start a new thread about this, but I've had to move back to 2.2.2 because of the 2-3 min config change time. So are some saying now that the change is to just set RW all the time? I could do this but I believed from others saying over the years that CF cards didn't like this. I'm wondering if USB sticks don't like this either. I know SSD have wear leveling so those probably don't apply.

Anyhow, is this now what must be done to run this normally or has anyone committed to patching this or at least fixing it next release?

Last question, is the broken limiter fixed in 2.2.3?

Thanks.