Doubts about antiX init script

[Member ctcx]

After my last question abut savestates, I thought I’d like to try proposing some changes in other areas within init script which I remember could work slightly better.

Since I’m no expert, it was not easy; took some weeks because even after finding the searched “areas”, everything is interconnected by functions, thus had to study a good fraction of entire script…

When finally finished, I thought I could start thinking about possible modifications; instead, I only got more doubts, which I describe next.

I’ll be using init script at Gitlab for easy checking, but I must mention this one is outdated. Current updated one can be found either by unpacking ISO’s initrd, or at /live/init when booting the live system.

Within find_files() function:
https://gitlab.com/antiX-Linux/Xlated-initrd/-/blob/master/init#L1871
When I booted with LiveUSB made with live-usb-maker, I saw it tries first /dev/sdb2 (the ESP), but of course it’s not it. So it should be unmounted afterwards. Issue is, it is not. When in toram mode, there’s no issue with sdb1 -it’s successfully unmounted-, but not the same with sdb2. I always had to unmount it manually before safely unplugging USB.
Why is this?

Within main_core() function:
Tried booting from ISO (still working with this tool
https://www.antixforum.com/forums/topic/booting-antix-with-multiboot-usb/ )
In the init log, I see this seemingly non-fatal error:
“Error: df: /live/boot-dev: can’t find mount point”
Tried tracing it, and found it must happen somewhere from this point
https://gitlab.com/antiX-Linux/Xlated-initrd/-/blob/master/init#L428
and next 8 lines
Problem is, I already tried analyzing all involved functions, and cannot understand how this freaking error is appearing. It even should not!

Within main_wrapper() function:
https://gitlab.com/antiX-Linux/Xlated-initrd/-/blob/master/init#L267
Option “toram_store” is just a particular one. What if not using any “toram” option at all? What does actually prevent unmounting? Because it does, I tested with a live DVD.

And finally, as kind of an apart additional doubt, what is toram-eject script actually for?
It’s called in the $HOME/.desktop-session/startup script, but seemingly does nothing!
I tried manually running it when booting from a live DVD. Running as normal user complains about “running as non-root user”; running as root complains about something like “LUKS device not ready”.
However in both cases script exits with status 0…

Thanks very much beforehand for your attention, and help if some is given.

[Member ctcx]

Helpful

Up

0

::

…Or perhaps this would be a question to @BitJam and should try writing him?

[Moderator Brian Masinick]

Helpful

Up

0

::

Can anyone help ctcx on his questions?
I’m not sure that I can be of much help other than to appeal for coders to examine the threads in question and respond if you are able to help.

Thanks!

--
Brian Masinick

[Member andyprough]

Helpful

Up

0

::

When I booted with LiveUSB made with live-usb-maker, I saw it tries first /dev/sdb2 (the ESP), but of course it’s not it. So it should be unmounted afterwards. Issue is, it is not. When in toram mode, there’s no issue with sdb1 -it’s successfully unmounted-, but not the same with sdb2. I always had to unmount it manually before safely unplugging USB.
Why is this?

I never knew that was mounted – I just pulled the stick out once it loaded toram. Never had a problem with it. Maybe the esp is simply not subject to corruption in that way and we shouldn’t worry about its mount status? I don’t know.

[Moderator Brian Masinick]

Helpful

Up

0

::

Regarding the general capabilities of the Live USB Maker, I use it for creating all of my recent USB drives.

I created a Slitaz disk today, which basically uses the dd read only components.

When I created MX Linux and antiX images I get the full capability. What I don’t know is what the specific code segments need; we realize what Live USB does; is anyone comfortable discussing or modifying the code cited in the links?

--
Brian Masinick

[Forum Admin dolphin_oracle]

Helpful

Up

0

::

the current live initrd is here: https://gitlab.com/antiX-Linux/live-initrd.gz

I would like to see the /var/log/live/initrd.log file for the options with questions.

for what its worth, I’m not seeing my esp mounted at all by a live antiX session, toram or not.

• This reply was modified 5 months ago by dolphin_oracle.

[Member olsztyn]

Helpful

Up

0

::

ctcx wrote:

When I booted with LiveUSB made with live-usb-maker, I saw it tries first /dev/sdb2 (the ESP), but of course it’s not it. So it should be unmounted afterwards. Issue is, it is not. When in toram mode, there’s no issue with sdb1 -it’s successfully unmounted-, but not the same with sdb2. I always had to unmount it manually before safely unplugging USB.
Why is this?

Very interesting observation. I never paid attention before but indeed, it appears that ESP partition remains mounted on Live USB…
Since it is booted on non-UEFI (Legacy MBR), if I understand @ctcx question I would think it would be interesting to know:
– Should ESP partition on Live USB be mounted at all if the machine is non-UEFI
– If mounted on boot anyway, should it be unmounted (I think it should, but perhaps there is a reason so not sure).
– Is there any data integrity issue if it remains mounted? Potentially it seems to be but on the other hand there is no write operation to ESP partition on the part of the antiX system over life of the session.
– If the USB stick is pulled (accidentally) during Live session is there possibility of corruption?

On the last bullet point: My conjecture is that:
– There should be no corruption to the ESP partition as it is not used at all during Live session.
– Corruption could occur for the main antiX partition if any type of persistence is used in Live session.
– No corruption can occur to the main antiX partition if no persistence is used during Live session except certain certain user settings may not be saved.

I could be wrong on any of the above so I would appreciate some insight if possible to better understand.

• This reply was modified 5 months ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Moderator Brian Masinick]

Helpful

Up

0

::

* usually * if nothing is written to a mounted partition there should be no issues, though if mounted read/write, an improperly closed filesystem could force a filesystem check (fsck).

The only problem that may cause would be improperly mapped inode pointers and if that happens it exposes a defect. This scenario is therefore unlikely, though in theory it’s possible.

--
Brian Masinick

[Member olsztyn]

Helpful

Up

0

::

Brian Masinick wrote:

* usually * if nothing is written to a mounted partition there should be no issues, though if mounted read/write, an improperly closed filesystem could force a filesystem check (fsck).

Thanks Brian.
I never had issues that I would attribute to such partition having been mounted but still it seems a good point brought up by @ctcx. Although I typically run antiX with no persistence (whether from USB or hard disk) so perhaps I may not just be exposed to defects as much.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member ctcx]

Helpful

Up

0

::

First of all, thanks everyone -and specially @dolphin_oracle – for reviving the thread.

Regarding the live USB’s mounted ESP, I think I finally found the issue:
I was wrong: it’s not the find_files() function at all, for it’s indeed doing all its job well; instead it’s the automount function at boot time.

As already known, if no “automount” boot option is specified, the default is to be enabled. On the other hand, when specifying “automount=off”, no USB’s partitions are mounted by default, thus completely safe to remove the drive right after booting and logging in into X are done.

Also, @masinick may have a point: under that logic unplugging the live USB should do no harm to the mounted ESP; however the thing is, zzzFM still shows a /dev/sdb2 “ghost” thing which, if it’s not unmounted *and* one tries plugging the live USB again, USB’s ESP will be mounted in */dev/sdc*, which will be reflected even in lsblk command.
Probably may not be a “fatal” issue since it’s still possible to just unmount all those, but still a kind of annoying remain…

[Member ctcx]

Helpful

Up

0

::

Now another thing apart, but still on-topic since it’s about the init script itself as well.

I retook this part as well:
https://www.antixforum.com/forums/topic/several-doubts-about-savestate/

I’m already trying to test some possible improvements for this part, but after studying the whole init script, I cannot understand at all how it is that, by just detecting the existence of /antix/xtra or /antix/xtra.tgz in the live USB, it just automatically runs the copy_xtra() function without having specified the boot option “doxtra” at all.
In the same way, no clue about how the “noxtra” boot option actually works, yet it does work if specified.
In the whole init script, aside the boot parameters reading function, there are no other references to any of the strings “doxtra”, “noxtra”, “DO_XTRA” at all!!

In the main_core() function there’s certainly ‘[ “$DO_XTRA” ] && copy_xtra’… but if doxtra boot option was not specified the test should return false!

Could someone help with this part?
Thanks beforehand.

[Member ctcx]

Helpful

Up

0

::

Finally, if someone could also please still help with the “toram_store” and “toram-eject” questions from the OP…
Thanks.

[Moderator Brian Masinick]

Helpful

Up

0

::

@ctcx: I have not looked at any of the scripts, but I can think of one possible reason why there are either no, or very limited, references to particular strings:

INCLUDE files, with either numeric or string values defined as fixed values – sometimes programs include entire modules with DEFINE or other static references to values.

That is certainly one possibility, and if so, that would also explain why there are very few, if any, visible references to certain variables or expressions.

--
Brian Masinick

[Member iznit]

Helpful

Up

1

::

how it is that, by just detecting the existence of /antix/xtra or /antix/xtra.tgz in the live USB, it just automatically runs the copy_xtra() function without having specified the boot option “doxtra” at all.
In the same way, no clue about how the “noxtra” boot option actually works, yet it does work if specified.
In the whole init script, aside the boot parameters reading function, there are no other references to any of the strings “doxtra”, “noxtra”, “DO_XTRA” at all!!

In the main_core() function there’s certainly ‘[ “$DO_XTRA” ] && copy_xtra’… but if doxtra boot option was not specified the test should return false!

Could someone help with this part?

DO_XTRA=true
Within the 0.sh script, this variable is initialized with a default value of true.
So, copy_xtra() will be called unless the “noxtra” boot parameter has been specfied.

((( quoting a comment within the init script, near the top )))

# CUSTOMIZATION:
# Customize to your distro using /etc/initrd-release. Add further
# customization if needed with scripts at /live/custom/$DISTRO/[1-9].sh.
# These scripts are run at the respective breakpoints. So 1.sh is run
# at breakpoint 1 and so on. The script 0.sh is run before we read the
# boot parameters.

[Moderator Brian Masinick]

Helpful

Up

0

::

Excellent script interpretation!

Thank you very much!

--
Brian Masinick

[Author]

Posts