I was wondering how the antix boot menu can be changed.
At the boot menu, the following is listed:
* Antix 13 - 386 base
* command line install
* root persistence
* static root persistence
* home persistence
* boot from HD
* memory test

I looked at the forum what the difference is between"root persistence","static root persistence", and"home persistence", and found that the difference between root and home persistence is probably that all files under / can be changed/saved with root persistence and all files under /home can be saved with home persistence. The home persistence, if it is what I think it is, seems rather useless to me as every user (for example in a school, ...) can simply make their own USB stick with Antix on it, so there would then not be an issue to accidentally corrupting the system, and if it does happen, it only happens with 1 user and this user can quickly format and rewrite the OS on the stick. I still don't know what static root persistence is, and what the difference is with the"Antix 13 - 386 base" option (I assume the latter just logs in as a user, and not as root, so you're unable to even change options or even access any drives). The boot from HD option seems useless (as people wanting to do this won't set their boot sequence to USB stick/Live CD first and then HD, and won't even have it inside the machine upon booting if they want to boot from HD.

What I'd like would be to have a following setup:
* log in as root
* log in as root + persistence
* log in as user
* log in as user + persistence
* install Antix to HD
* memory test

The install to HD option would eliminate the need to have an install link in the right-click menu, or an icon at the desktop. This seems safer, to avoid users accidentally installing Antix and corrupting any boot loaders (which can make loading other OS's also on the HD no longer possible)

The login-option of immediately becoming root, but the system doesn't not having persistence in that option would be useful for people wanting to try a program which requires a program install but get rid of the program upon reboot, for example to not alter any files of the OS in case the program doesn't fulfill the users' expectations.

As a bootmenu line item,"Antix 13 - 386 base" is equivalent to booting"factory fresh"
(ignores any customizations user has made to the distributed iso, ignores presence of any persistence files).
IIRC, when you remaster, you'll be prompted to replace the"blahblah...base" menu entry label with your own labeltext.

What I'd like would be to have a following setup:

Some of the questions you've raised are addressed in the antiX documentation.
Check the html userdocs supplied in the distro and visit the antiX wiki.
Until you read the docs, it's fairly impossible to discuss the possible nuances/options surrounding persistence (e.g. static vs dynamic)

The boot from HD option seems useless (as people wanting to do this won't set their boot sequence to USB stick/Live CD first and then HD

If user hasn't assigned"boot from USB/CD" priority in BIOS, how has he managed to boot and arrive at the live bootmenu? By disconnecting his hard drive(s) prior to to booting from the pendrive? You would rather remove that option from the bootmenu, forcing the user to repeatedly revisit his BIOS setup and tinker with the boot order? Ouch.

The Boot from HD option (in some distros the option is labeled"boot from another partition") as well as the"memtest" option, those are longstanding live boot options across various distros (not specific to antix). Personally, I feel that memtest is so seldom used/needed that it should be available via a bootline arg (vs cluttering, adding noob confusion, by displaying as a menu entry). Anyhow, we're free to customize the entries displayed to the bootmenu ~~ you'll find the relevant cfg files (and txt docs) on the pendrive at /boot/isolinux/ (cd boot) and /boot/syslinux/ (for liveUSB boot)

The login-option of immediately becoming root, but the system doesn't not having persistence in that option would be useful for people wanting

I'll suggest that you really need to rethink this. Many overlapping options and scenarios are"possible" and I expect you're further ahead to document/enumerate suggested best practices... than trying to lockdown and restrict the user to a fixed set of options. A user should NEVER"need to" immediately become root and shipping a remaster which provides such a pre-baked option would, arguably, be a disservice to the user ~~ by needlessly exposing them, their system, to potential vulnerabilities. I hear ya:"but what's the harm? there would be no persistence..." ah, but, are other drives mounted during loosygoosyroot's session? Are samba shares on his LAN exposed? Are vulnerable servers/services (apache, ssh, etc) running on this"but, but, it's not persistent" system? Puppy Linux (web browser launches as restricted user"fido", even for root-permissioned destop user) would probably be a preferable basis for such a forced/restricted (loosygoosy) use case.

Skidoo seems to understand what you (BrianPerry) are saying much better than I can. Sorry.

Dynamic root persistence stores file system changes in RAM until persist-save is run which copies all the changes to disk at once. Static root persistence stores file system changes immediately to disk. It uses no extra RAM and the only size limit is the size of the rootfs file you created. The downside is it can be painfully slow compared to dynamic persistence, depending your system.

After skidoo's wise words about security and safety, I hesitate to mention this. The"db+" boot parameter will log you in as root automatically in vt-2, vt-3, and vt-4. Use Ctrl-Alt-F2 to get to vt-2, etc. I use this all the time when I am developing and debugging.

Maybe it should be disabled for production. I just don't know. It is extremely convenient but it gives anyone with physical access to a Live device access to root without a password. OTOH, once someone has physical access, the jig is up anyway.

Interestingly, I do not have my bios set to boot straight to usb devices first. My machines all have a"F12" or some ofther key - one-time boot menu. I don't set this in bios because of a issue with a dell desktop I have (and run live on). The dell bios treats the usb key as a HD rather than a usb device. So when I did have the boot preference set to boot the (particular) usb device, selecting"boot to HD" just rebooted to the stick instead of the internal drive.

the EEEPC and HP in my signatures also have one-time boot menus. The old sony doesn't (boots usb with a plop FLOPPY!).

one thing about antiX...the defaults are generally pretty good. The underlying flexibility is mind boggling sometimes, and one reason we have a rep as an"enthusiasts" distro. Old hardware enthusiasts, of course __{{emoticon}}__

+1 to skidoos remarks about user security vis a vis logging in as root. logging in as user generally speaking keeps me from breaking things (at least accidentally). You do not want to delete a file on someone else's PC unless you mean it, and a password (I mean, its root by default on live) is easy to enter.

As far as the terms of root and home in terms of the persistence options. root refers to the root system (/ per se) not the root user account. root persistence allows changes to the filesystem like installing apps and such. while /home is included in the root filesystem, there are some advantages to having a seperate /home persistence file, not the least of which is that if you do load your persistence file into memory (the default dynamic root persistence option), the files in your /home won't be loaded into memory if you are using the seperate /home persistence. also, netflix-desktop won't run on live unless there is a /home peristence file because of some technical attributes of the file systems involved (features that aren't supported by aufs).

static persistence simply loads the persistence file as needed from the usb, which depending on changes you've made to the base live system, could be substantially slower than using the dynamic persistence. both root persistence options will also access the home persistence file if its present.

keeping track of all the options can make the head spin sometimes, but the underlying flexibility is a strength of antiX. personally I use static root persistence with a home persistence file as well. the auto-setup stuff coming in antix-14R will make you smile if you are fan of running liveUSB w/persistence.

None of our PCs have the F12 boot option D_O mentioned; F2+password would be necessary to change the eligible dievices and/or the boot order.
So that's my frame of reference in mentioning avoidance of"messing with" bios settings during each boot.

Hey, I'm suddenly wondering:
To avoid potential confusion, should the labels, the docs, be amended to 'rootfs persistence' vs the current 'root persistence'?

Along the way since antix13.1, I'm fairly certain I performed apples-to-apples comparison
(same pendrive, same distro release, with dynamic vs static as the tested variable)
and didn't find a remarkable difference. At reading again"can be painfully slow, depending on your system",
I suppose that's with attention to the possibility (still a supported scenario) that someone is booting from CD or from an ancient 4rpm hard disk.

keeping track of all the options can make the head spin

I've read through the docs and the past discussions... yet I have never (knowingly) used"home persistence".
During various test runs, I've noticed files on the pendrive named 'rootfs' and 'homefs'
(after using the stock bootmenu entry, vs editing the bootline to remove the ',home' arg)
but I've never checked:
"What happens when both are present and, during a given boot, I choose 'RootPersistence'? Are files pathed to ~home written redundantly? Are they written to both rootfs and to homefs?"

"What happens when both are present and, during a given boot, I choose 'RootPersistence'? Are files pathed to ~home written redundantly? Are they written to both rootfs and to homefs?"

I don't think so. if a homefs is present, its used instead of /home in the rootfs file. the root persistence options will automatically use the homefs if present.

I like your labeling suggestions for the boot menu (rootfs and homefs persistence)

skidoo wrote:

The boot from HD option seems useless (as people wanting to do this won't set their boot sequence to USB stick/Live CD first and then HD

If user hasn't assigned"boot from USB/CD" priority in BIOS, how has he managed to boot and arrive at the live bootmenu? By disconnecting his hard drive(s) prior to to booting from the pendrive? You would rather remove that option from the bootmenu, forcing the user to repeatedly revisit his BIOS setup and tinker with the boot order? Ouch.)

People can arrive at the bootmenu by having antix installed to the HD, and not changing the BIOS boot sequence (so it remains at the default: boot from HD first, then CD, then USB, ...) So in this case, the"boot from HD" option at the bootmenu would be useless, and if they boot from USB stick, the option too is useless as they can simply change the BIOS boot sequence instead. They can physically remove the USB stick or insert it depending on whether they wish to boot from from HD or from USB stick.

Yes, I think it's better people just use the BIOS to change the boot sequence instead. It's not much more work and less confusing, especially for people new to Linux (granted, the same problems could be had with Windows too, but in general with Windows, they just have windows installed and no 2nd OS, so these issues then don't arise).

skidoo wrote:

The login-option of immediately becoming root, but the system doesn't not having persistence in that option would be useful for people wanting

I'll suggest that you really need to rethink this. Many overlapping options and scenarios are"possible" and I expect you're further ahead to document/enumerate suggested best practices... than trying to lockdown and restrict the user to a fixed set of options. A user should NEVER"need to" immediately become root and shipping a remaster which provides such a pre-baked option would, arguably, be a disservice to the user ~~ by needlessly exposing them, their system, to potential vulnerabilities. I hear ya:"but what's the harm? there would be no persistence..." ah, but, are other drives mounted during loosygoosyroot's session? Are samba shares on his LAN exposed? Are vulnerable servers/services (apache, ssh, etc) running on this"but, but, it's not persistent" system? Puppy Linux (web browser launches as restricted user"fido", even for root-permissioned destop user) would probably be a preferable basis for such a forced/restricted (loosygoosy) use case.

I don't think it's an issue. The idea is to use AntiX mainly as a portable Linux version (a bit like Porteus, ...) in which every user has his own USB stick (with AntiX OS). See
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"antix.freeforu ms.org/viewtopic.php?f=49&t=5292"
linktext was:"antix.freeforu ms.org/viewtopic.php?f=49&t=5292"
====================================
I even think that the portable use (only) is going to be the main reason for people to want to use AntiX over other Linux distro's (especially as many are a bit more user friendly, allow easy login as root/even have write/read permissions as a mere user and can still be run on low-end systems, i.e. SliTaz, Lubuntu, ...) So, given that everyone is assumed to have an own USB stick/Antix OS, if a user messes up and exposes the system, it's still not an issue as it will effect only his particular system/OS/USB stick, not systems of other people. You could thus say that if he messes up, it's his own fault. This would thus not be an issue for even public computers, and for private computers it's definitely not an issue as even a family will use only a single user anyway, which is btw also often the only person in the family that has any knowledge of computing and is able to make an Antix USB stick at all. So if he screws up, chances are that he'll switch to using a different OS for the whole family/home PC anyway. The whole concept of Linux and the user rights system was mainly focused on public PC's, for example in universities, ... and people didn't have a personal PC themselves. Nowadays, that all has changed, and the whole user rights permissions idea is antiquated.

The whole concept of Linux and the user rights system was mainly focused on public PC's, for example in universities, ... and people didn't have a personal PC themselves. Nowadays, that all has changed, and the whole user rights permissions idea is antiquated.

There are still many reasons to keep permissions, not least of all when a newbie starts out learning. __{{emoticon}}__

"What happens when both are present and, during a given boot, I choose 'RootPersistence'? Are files pathed to ~home written redundantly? Are they written to both rootfs and to homefs?"

I don't think so. if a homefs is present, its used instead of /home in the rootfs file. the root persistence options will automatically use the homefs if present.

Posting to note that I got around to testing this, and the result is exactly as d_o described.

I had wondered:
Does the content pathed to ~home within the rootfs"shine through", so that it is available along with the layered content of homefs when both rootfs and homefs are loaded?
No. Any time homefs is loaded, its content obscures/overshadows all ~home content within rootfs.

Conversely, if a file is written to ~home while homefs and rootfs are both loaded...
...during a later session when only rootfs is loaded, that file essentially"does not exist".

That is the normal behaviour of the filesystem, if you were to mount another disk onto /home after having booted up, it would 'hide' the original /home files, same with any other mountpoint.