antiX repo reset after reboot

[Member GeoffC]

Helpful

Up

0

::

Can I ask if resetting the antiX repo at bootup, based on timezone, is the default behaviour too? It seems rather an odd choice.

I haven’t really changed much on my live USBs from the basic 19.3 32-bit distribution – certainly nothing major to do with the repos. So I’m just a bit puzzled whether it’s something I’ve caused and why nobody else seems to have this issue?

Removing the disable=lx boot menu options when I made this remaster months ago did have a lot of effects, but it doesn’t seem to be related to this issue – I tried replacing those options and it didn’t change the behaviour of resetting the repo at bootup.

[Anonymous]

Helpful

Up

0

::

If I use the Repo Manager utility to select a different mirror on the “antiX repos” tab,
the change doesn’t survive a reboot, despite static persistence being set.
Is there some way to make the repo change stick,

We have the (confusingly flexible) freedom to choose different options during each boot session.
As I mentioned in earlier post, I’m unsure which of the options DO vs DO NOT automatically “stick”.

Along with “norepo”, try also adding “dostore” (no quotes) as a parameter
( or if using LegacyBIOS bootscreen, the F8 Save option )
and recheck on the subsequent boot to determine whether that solves the “not remembered” issue.

resetting the antiX repo at bootup, based on timezone, is the default behaviour ?

Heh, after I spent the entire afternoon 47 seconds researching and came back to report that it is based on country, not timezone… you’re back to asking about timezone?!?

I only researched “what happens during live-remaster”.
To understand the “default” (every live boot) behavior…

https://gitlab.com/antiX-Linux/live-initrd.gz/-/blob/master/etc/init.d/live-init#L90

howabout that ~~ today I learnt:
norepo
norepo=*
-i --ignore=<list> Comma delimited list of [specific] MX/antiX mirrors to ignore

https://gitlab.com/antiX-Linux/live-initrd.gz/-/blob/master/etc/init.d/live-init#L584

if [ ${#IGNORE_REPO} -gt 0 ] && localize-repo --help | grep -q -- --ignore; then
     : ${args:=default}
        args="--ignore=$IGNORE_REPO --random $args"
fi

$ localize-repo --help
Usage:  [options] <timezone|country-code|"default">

Update the mirrors in the *.list files under /etc/apt/sources.list.d/
with the closest mirrors based on timezone city or two-letter
country code.  If "default" is given then use the timezone
in the /etc/timezone file.

Options:
    -c --codes          Only display codes for the servers that would
                        be used for the given timezone
    -d --dir=<dir>      Use <dir> instead of /etc/apt/sources.list.d
    -h --help           Show this help
    -H --hosts          Only show the hosts that would be used for the
                        given timezone
    -i --ignore=<list>  Comma delimited list of MX/antiX mirrors to ignore
                        Codes: au1 au2 at be bg br ca ch cn cz de dk ec es fr gb ge gr hk hu id in \
                           it jp ke kz la lt my nl ny nz ph pk pl ru se sg si sk th tr tw ua ut uy vn za
    -L --list           List all the mirror locations
    -p --pretend        Don't do anything just show what would be done
    -r --random         When a US city is closest, use any US mirror at random
    -q --quiet          Print less
    -v --verbose        Print more

So… I’m 94.2% sure that the answer to your Q is:
Yes, is default. Is a “feature”, not a bug.

resetting the antiX repo at bootup, based on [country or timezone], is the default behaviour ?

[Member GeoffC]

Helpful

Up

0

::

Oh, my goodness! So sorry, I didn’t mean to make all that work – I thought you might just know off the top of your head.

Ok, well it’s good to understand it is a ‘feature’ and I’ve learnt how to modify the behaviour with ‘norepo’, so all is good.

I still don’t really understand why this hasn’t been an issue for others, but such are the vagaries of life 🙂

[Member ModdIt]

Helpful

Up

0

::

GeoffC wrote:
I still don’t really understand why this hasn’t been an issue for others.

Because for our own usage we do a Personal remaster which keeps the changes we have made including repos.

antiX gives a lot of choices, you want to use boot codes fine, setting checkbox personal is easier, less work.

We all learn new tricks from threads like tis one. Anyways if you are happy please let us know so we can mark as
solved not a bug.

[Member GeoffC]

Helpful

Up

0

::

Oh sure, by all means, mark it as solved – I never meant to imply there was a bug. I was just looking for a setting to modify the behaviour (which I knew must exist given this is linux)

Moddit wrote:
…we do a Personal remaster which keeps the changes we have made including repos.

I still don’t see how a remaster will stop the default behaviour of localizing the repo at bootup time. The current live USB I am using is already a personal remaster that I did months ago after setting up the system, yet it still has this problem. Nevertheless, I will give it a try again – it will be an instructive exercise 🙂

Thanks again for your help.

[Member ModdIt]

Helpful

Up

0

::

Hi GeoffC
Weird stuff, I can confirm your observation now.
I setup a fresh stick with 19.3, did all updates after setting Göttingen as mirror using the CC tool
then tried to use it as I think you are doing.

If I do a remaster then just shutdown my repos are same as I set as are all my settings
After I do an antiX reboot without any further customising that is.

If the system does a persist save repos get reset.

So to me the system is also not behaving as I might reasonably expect. By design or not I do not know.

Why I did not see that before, I guess because after a remaster I do not continue to do any work or play, just shutdown,

[Member GeoffC]

Helpful

Up

0

::

Hmmm, that’s an interesting turn up.

I tend to remaster only occasionally, then use static persistence until the next remaster event. Maybe the reason my system was resetting the repo, but yours wasn’t, is due to me using the static persistence, where-as you weren’t, because you remaster frequently.

Personally, I think it would be more helpful if the repo localization only occurred when the system is first set up, not every reboot. Otherwise it has to be changed back to the desired mirror every time the system is updated.

Anyway, that’s just my opinion – I have been really enjoying antiX, so I certainly don’t mean to criticize it.

[Member ModdIt]

Helpful

Up

0

::

The problem may be due to the person developing was or is located in USA using local repos
and thus not noticing the issue could occur.

Maybe a person who understands remaster and persistence way better than I do can figure
out a permanent fix for this problem. With Bullseye coming and new user influx it could cause
quite a lot of irritation.

[Anonymous]

Helpful

Up

0

::

If the system does a persist save repos get reset.

So to me the system is also not behaving as I might reasonably expect. By design or not I do not know.

Why I did not see that before, I guess because after a remaster I do not continue to do any work or play, just shutdown,

I don’t use static persistence but have learned (probably the hard way) that
yes, if performing a live-remaster operation during a dynamic persistence session,
you should shutdown the machine immediately after performing a remaster operation.
-=-
said differently:
Subsequent to the remaster operation, further same-session changes to the system will not be saved.

This detail, coaching the user to shutdown now and restart, probably should be added into the “success” messagebox (or commandline output) displayed at the end of a live-remaster operation. Additionally, this detail could be mentioned in the docs. Wait, does a standalone docs page (beyond the –help output) exist for live-remaster? Yeah, but it doesn’t exactly “get into detail”, eh /FAQ/remaster.html

In the interim In the absence of such a notice of a the end of the live-remaster operation, or perhaps as an additional “heads up”… the l-r operation should place a /tmp/flagfile which the persist-save script (applicable to dynamic perisstence only, eh) would test for on each run, and if the flagfile is present would advise “subsequent to live-remaster, cannot save further changes until the system is restarted”.

^— hmm, the additional “persist-save would check and…” is too late ~~ amounts to “salt in the wound” of any caught-by-surprise user.

Ah, the biting edge(s) of “confusingly flexible functionality”.

Confusingly (to me, at the time), back around 2016 or 2017… live-remaster was “expanded, improved”, it grew a third-leg feature offering to optionally — in advance — create the fresh persistence container(s) which will be used (immediately//automatically) upon next reboot. Typically, at the start of each liveboot session, we have the opportunity (via bootmenu or or bootline) to choose/change the type of persistence to be used during the current session -OR- we may choose to altogether forego use of persistence for the current session.

I understand (and agree) that some aspects of the status quo behavior are “surprising”, are “unexpected”. I’m not trying to defend the status quo, am merely attempting to explain the status quo behavior.

Somehow, attention to “it might be inconvenient if live-remaster _forced_ the user to immediately shutdown following its completion” apparently outweighed attention to the prospect of cofusion induced by having too many options and choices available.

if performing a live-remaster operation during a dynamic persistence session

In that (dynamic) scenario, one of the steps during the live-remaster operation is to rename ‘rootfs’ to ‘rootfs.bak’. If the user optionally elects to “create, in advance” a new persistence container, a file named ‘rootfs.new’ is created. If/when persist-save is called subsequently later in the same session, it will be unable to find a ‘rootfs’ file to, so is unable to save any changes.

In the ‘static’ scenario, I do not know whether a similar “technical limitation” exists.

[Member GeoffC]

Helpful

Up

0

::

I’m not sure whether any of this remaster stuff relates to the issue of repos being localized at bootup actually.

Out of curiosity I performed a personal remaster and as I suspected, it made no difference. So first I set up the antiX repo to the one I wanted, using Repo Manager. Then I performed an update with apt. After that I did a personal remaster, including the final step of creating the new rootfs (as recommended), then immediately rebooted when it had finished successfully. As soon as I had logged in I checked repos with “inxi -r” and sure enough, the repo has been altered by localizing again, the same as before.

I also tried another live usb I have, which is a 64-bit build of antiX 19.3, to see if it was a problem caused by settings of that particular live usb. I tried it with both persist_static and persist_all boot menu options, by changing the antiX repo using Repo Manager, updating with apt, then rebooting. In all cases the repo is reset (i.e. altered by localizing) unless the ‘norepo’ parameter is set.

[Member ModdIt]

Helpful

Up

0

::

Hi GeoffC,
You are right this behaviour is Annoying/Irritating, for some maybe a reason to run back to windoze..

A change done yesterday on a recent stick stuck at first, an update changed the repo back to RTWH Aachen
and re added the default US English keyboard.

Any change to Default US keyboard is a pain for users with other layouts if symbols are used in passwords,
users are thinking the system is broken as unable to login.

I fixed that, remastered, shutdown then rebooted repo change is still set.

Looking at the remaster script I see a default timezone set to New York, wondering if changing that
will change part of the behaviour,

Nice would be if we can just set a standard repo of choice in our locality, setup keyboard and timezone and it
would stay that way unless/until a root or sudo user initiates a change.

[Forum Admin anticapitalista]

Helpful

Up

0

::

ModdIt wrote:

Hi GeoffC,
You are right this behaviour is Annoying/Irritating, for some maybe a reason to run back to windoze..

Didn’t know that windoze offered live remastering and persistence …

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member GeoffC]

Helpful

Up

0

::

The repo reset really doesn’t matter as long as you know to expect it, since it can be countered with ‘norepo’ at the boot commandline. I mostly raised the topic because I don’t remember having to set my mirror at every update when I first created these live USBs, so I was wondering if something had changed. Maybe I just didn’t reboot for weeks so it was never reset, or maybe my memory is failing 🙁

[Member Xecure]

Helpful

Up

0

::

I think this is related to you using the syslinux/isolinux boot menus to select a different timezone (or selecting a language, which will automatically also change the timezone).
On my UEFI system, I select the timezone once, and then remove the timezone bootcode from my live system grub.conf file. I suspect that using the syslinux/isolinux boot menus to select a timezone/language and saving the options will lead to the live system to reset the repo each time you boot (except if using the norepo or disable=r boot parameter).

If I am mistaken, please ignore my reply.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member GeoffC]

Helpful

Up

0

::

That would make sense. I’m using old hardware, so always BIOS. I very rarely change the boot menu options, (and never change the timezone) but maybe it doesn’t check to see if changes have been made – perhaps it just applies the options each time, so that would trigger the timezone change regardless (& consequently, repo localization).

I guess I should just install instead of running live, but live has some advantages too, so I’ll just use norepo now that I know about it. I learn a lot from these ‘problems’ 🙂

[Author]

Posts