antiX-21-beta2 iso files available.

[Member Xecure]

Helpful

Up

0

::

anticapitalista wrote:

@Xecure – probably a good idea to have some sort of popup (though I usually hate them)
either when user clicks on Install on the Desktop(s) or clicks Install via menu(s).
Or as a popup on first live boot (with option to remove message for those running live)

I just cannot find an easy way to do this. I was trying to avoid the pop-up (as you say, not the best option), and instead add an instruction in the installer to change the default grub option to the current kernel, but then that default option would remain the same if the user installs a new kernel in their installed system.

Maybe the easiest method is warn the user in the release notes that they should remove the kernel they don’t need before installing. Having to translate another dialog that only affects if they don’t select the newest kernel is just not worth it in my opinion.

I will study a bit more how changing the grub configuration changes defaults and see if I can come p with a better suggestion.

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

[Forum Admin anticapitalista]

Helpful

Up

0

::

@Xecure – I’ve also been racking my brains about the best way to do this.
The 2 kernel option is only on 64 bit full (sysvinit and runit) so I’m inclined to agree with you that we make it clear in the Release notes.

BTW – I updated runit-antix to latest version in Debian

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

antiX with runit - leaner and meaner.

[Member tamix]

Helpful

Up

0

::

@moderators

Please remove my post #69362 above. I did some mistakes and I need to correct some mistypings.
I will resend my post it after correction.

Thanks in advance.
tamix

[Member tamix]

Helpful

Up

0

::

@moderators this one should be ok

The init breakpoint interactive session. A few suggestions about it.

A special kudo to @BitJam.

The test described below has been run several times similarly in 3 antiX releases by using the read-only LiveUSB:

. antiX-21-b2_x64-full (bullseye-sysVinit)
. antiX-19.4_x64-full (buster-sysVinit)
. antiX-19.3_x64-full (buster-sysVinit)

System:
  Kernel: 4.9.0-279-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc 
  v: 10.2.1 Desktop: IceWM 2.7.0 
  Distro: antiX-21-b2_x64-full Grup Yorum 6 September 2021 
  base: Debian GNU/Linux 11 (bullseye) 
Machine:
  Type: Laptop System: ASUSTeK product: X456UVK v: 1.0 serial: <filter> 
  Mobo: ASUSTeK model: X456UVK v: 1.0 serial: <filter> 
  UEFI: American Megatrends v: X456UVK.303 date: 10/05/2016 

Not sure the post is appropriate to this thread’s topic although it does include the 21-b2 release among the tests. Moderators might plan to redirect my post to another thread, they are most welcome.

Please note the three points discussed below affect in no way the basic components implied in the ‘initrd init’ process. They only concern a possible interaction with whoever wants to launch breakpoints – aka ‘bp’ – after boot. Finally our question sounds like: Is it possible to make the ‘init’ interactive menu only reflect what the set of breakpoints actually does? No less, no more. Necessary and sufficient “as required by law”.

The three points require adding tiny changes – but real changes though – in the ‘init’ file, which is a major component in the operating system. I ignore how changes are planned then propagated through the antiX architecture. May be the OS modular conception helps plan such changes. So whenever I mention below « Read the file /live/init », this only refers to my current live session. As for a real change done under control, we’d have to look into the original ‘init’ file stored in the ISO’s compressed file initrd.gz, then into a distro release, etc.: it is not the purpose of this post.

That’s why I suggest at first to check the new breakpoint interactive menu by using the terminal’s command line. Depending on your antiX flavour/context, the sudo command may be required to access the /live/init file. A particular init function to consider is called select_breakpoints() – lines 1166-1182 [1151-1167]. Every line number not put in square brackets is related to antiX-21-b2_x64-full. Those put in square brackets are related to antiX-19.4_x64-full.

After we set the boot option ‘bp=ask’ or ‘bp=?’ on the boot line, the next stage ‘initrd init’ currently displays an interactive menu by listing the following breakpoints then the prompt ‘:’ for reading our choice:

Remaining initrd init breakpoints:

  1) before welcome
  2) before coldplug
  3) before looking for linuxfs file
  4) after mounting boot device
  5) after mounting persistence device
  6) after mounting aufs
  7) after prepare switch_root
  8) before running live init.d scripts
  9) right before starting init
  e) On possibly fatal error

use "a" to set most breakpoints
use "A" to set all breakpoints
use "bash" to enter a Bash shell before system starts

:

As a matter of fact, the list above is incomplete because three options are missing: b8, b9 and 0. It also displays an extra option which should not exist: “bash”. What’s more, a short explanatory sentence is missing just before the prompt: ‘Enter breakpoints separated by commas’.

If everything is in order after a supposed change, we should get 15 separated options. Si we should see the complete menu:

Remaining initrd init breakpoints:

  0) before move
  1) before welcome
  2) before coldplug
  3) before looking for linuxfs file
  4) after mounting boot device
  5) after mounting persistence device
  6) after mounting aufs
  7) after prepare switch_root
  8) before running live init.d scripts
  9) right before starting init
  b8) Bash shell before running live init.d scripts
  b9) Bash shell before the system starts
  e) On possibly fatal error

use "a" to set most breakpoints
use "A" to set all breakpoints

Enter breakpoints separated by commas

:

As an example, at prompt we might select a single or combined options like:

0
0,9
1,2,3,A
4,5
A
a
b8
b8,b9
0,b8,b9,a
e

(note: line #3, ‘A’ supersedes 1, 2, and 3)
(note: line #9 is equivalent to line #5)

Let’s recall we can also write the same combinations on the boot line:

bp=0
bp=0,9
bp=1,2,3,A
bp=4,5
bp=A
bp=a
bp=b8
bp=b8,b9
bp=0,b8,b9,a
bp=e

Let’s see in detail what is going on.

1) When parameter ‘bp=ask’ is set on the kernel parameter line. All options currently displayed are valid except the ‘bash’ option which does nothing at all. It looks like the ‘bash’ option is quite not processed in the ‘init’ script. This is no critical point. The pointed breakpoint option is described as:

  use "bash" to enter a Bash shell before system starts

AFAIK the ‘bash’ option remains inactive as a breakpoint. Why not remove it? Unless it is considered a kind of “joker” reserved for later. It’s up to the antiX team to decide. In my opinion putting a comment is sufficient.

Read the init file:

$ sudo less -N /live/init

– Function: select_breakpoints()
– Line 1176 [1161]: echo “${m_co}Use \”bash\” …
– Suggestion: line 1176 [1161] to be commented.

2) No critical point. For a reason still unknown to me, a final sentence is missing just before the prompt when the boot option ‘bp=ask’ or ‘bp=?’ is set:

Enter breakpoints separated by commas

Read file: $ sudo less -N /live/init
– Function: select_breakpoints()
– Line 1178 [1163]: printf “${ok_co}%s$m_co: …
– Suggestion: line 1178 [1163]to be fixed/replaced.

A hypothesis. Let’s suppose the line is well printed on the standard output. Might it be overlapped by the following instruction? It is worth a further check: the cttyhack’s functionality is to give controlling tty to a shell then read the user’s answer. Anything more?

printf "${ok_co}%s$m_co: $nc_co"  "$_Enter_breakpoint_s_separated_by_commas_"
setsid cttyhack > /dev/null
read BREAK_POINTS;;

3) Adding only the missing options in the interactive menu.

3.1 The ‘b8’ and ‘b9’ options. They are not displayed when bp=ask or bp=? has been set on the boot line. However both options are valid if they are explicitly typed by the user at prompt. In other words, they flawlessly work! No critical point: a user could just remember that such options are valid either on the boot line – or at prompt if they had set ‘bp=ask’ previously.

Options ‘b8’ and ‘b9’ are shortly described in /live/README:

  b8) Bash shell before running live init.d scripts
  b9) Bash shell before the system starts

How to adjust 3.1?

Read file: $ sudo less -N /live/init
– Function: select_breakpoints()
– Line 1172 [1157]: sed -rn … sort
– Suggestion: line 1172 [1157] to be changed

For adjusting b8 and b9: the string {1,2} is appended to [1-9a-z]:

sed -rn 's/^\s*breakpoint ([1-9a-z]{1,2})\> */  \1) /p' $0 | sed "s/['\"]//g" | sort

3.2 The ‘0’ option. As a matter of fact, this ‘extra’ breakpoint option already exists and can be set on the boot line: ‘bp=0’. If that option is set by the user then two breakpoints occur just before the system starts. On the other hand, if ‘bp=ask’ is set then one just has to type ‘0’ at prompt with the same effect. We might evaluate the necessity of such a breakpoint in the init interactive menu. What for, precisely? So we need an answer, because I have no idea of it. No critical point: a user could just remember that such an option is valid either on the boot line or at prompt if they had set ‘bp=ask’ previously.

At execution, we get as expected two breakpoints occurring successively under their usual form:

==> limited shell @ breakpoint [0] before
    Use the exit command or press Ctrl-d to continue
    Use safe-poweroff and safe-reboot to poweroff and reboot
bp 0>

and

==> limited shell @ breakpoint [0] after
    Use the exit command or press Ctrl-d to continue
    Use safe-poweroff and safe-reboot to poweroff and reboot
bp 0>

How to adjust 3.2? (it’s assumed a first change was done in 3.1)

Let’s consider the same file, same function and same line number 1172 [1157]
Suggestion: line 1172 [1157] to be changed

For adjusting ‘0’: in string ‘[1-9a-z]’ replace the digit 1 with 0:

sed -rn 's/^\s*breakpoint ([0-9a-z]{1,2})\> */  \1) /p' $0 | sed "s/['\"]//g" | sort

At this step, there might be two instances of breakpoint 0 displayed. It is normal, considering the init specific context. We won’t complain! Two more breakpoint entries for the price of one, so we get:

  0) before move
  0) before move

However to make the interactive menu unambiguous, we are going on. We’ll just append the piped command ‘ | uniq‘ at end of line: line 1172 [1157] to be changed again:

sed -rn 's/^\s*breakpoint ([0-9a-z]{1,2})\> */  \1) /p' $0 | sed "s/['\"]//g" | sort  | uniq

You’ll note the instruction above scans the proper file it is written in. An elegant way of building a complete interactive menu (by staying at home) which involves a minimum cost in execution. Lean and mean so to speak.

Now our final check on the command line: Just copy the instruction above on the terminal’s command line and replace $0 with ‘/live/init’ (ie the init filename). The correct breakpoint list should be displayed:

$ sudo sed -rn 's/^\s*breakpoint ([0-9a-z]{1,2})\> */  \1) /p' /live/init | sed "s/['\"]//g" | sort | uniq

We are done. Now every antiX member can run the same tests on the fly.

4) The Breakpoint section in file /live/README might be updated if such changes are accepted and processed in a next antiX release.

A special kudo to @BitJam. Chapeau, l’artiste! Hopefully I’ll take time to read it through and think it over. The more we read this long complex file, the more we appreciate its architecture, the more we may consider it a masterpiece, smartly and rigorously developped according to the state of the art. In a nutshell I wish I were a co-designer of it… Such a result is also collective, a matter of nice cooperations among people sharing their know-how (why not, among people committed in fundamental forms of freedom). This gives us enthusiasm, indeed.

Additional note: To get a full idea of how the live init code is well structured, just type in the following commands which print the number and/or the list of all functions:

$ sudo grep -E -c '^\b[_[:alnum:]]*\b\(\)' /live/init

and

$ sudo grep -E -n '^\b[_[:alnum:]]*\b\(\)' /live/init > ~/init.func

Have also a look, among others, at a function named should_break_at(). Let’s consider it a tiny “jewel” for a while if you don’t mind. Getting to each breakpoint position during the init process, the function checks whether the bp has initially been selected or not by the user. Result is binary: 0/1. The algorithm is short, a bit tricky, however it *exactly* does what it was designed for. No less, no more. Hits the bull’s-eye. Hats off to the artist!

Hope all points are clear and helpful.

[Member marcelocripe]

Helpful

Up

0

::

Maybe the easiest method is warn the user in the release notes that they should remove the kernel they don’t need before installing. Having to translate another dialog that only affects if they don’t select the newest kernel is just not worth it in my opinion.

The 2 kernel option is only on 64 bit full (sysvinit and runit) so I’m inclined to agree with you that we make it clear in the Release notes.

The antiX 21 32-bit ISO could have two kernels, the 4.9 or 4.19 kernel (whichever is more compatible with 32-bit processors and motherboards) and the other 4.4 kernel.

– – – – –

A ISO de 32 bits do antiX 21 poderia ter dois kernels, o kernel 4.9 ou 4.19 (aquele que for mais compatível com os processadores e placas-mães de 32 bits) e o outro kernel 4.4.

[Member bci]

Helpful

Up

0

::

Hi cristophe,

I have just installed Antix 21 Runit on a Thinkpad X220 (see inxi output below). I found the solution to simply select “no” (refuse the update), and then simply proceed to upgrade your packages. When you attempt to apt-get update from within cli-aptiX, you’ll see the “loop” go away. I’ve pasted the session below.

Hope this helps,

Brandon

Example cli-aptiX session
$ sudo cli-aptiX
Checking source files …
It appears that at least one list file is missing
You should probably run apt-get update now

Run apt-get update now?
> yes
= no
Press <Enter> to select the highlighted entry
Use ‘h’ for help, ‘r’ to redraw, ‘q’ to quit
Checking for package upgrades …
There are 14 packages that can be upgraded
——————————————————————————-
System Upgrade Menu
——————————————————————————-

Please select an action
= Upgrade 14 packages now
> View a list of packages to be upgraded
> Ignore these upgrades for now
> Update package index (last update Fri 05 Nov 2021 09:32:46 PM EDT)
Press <Enter> to select the highlighted entry
Use ‘h’ for help, ‘r’ to redraw, ‘q’ to go back to the main menu
=> apt-get dist-upgrade
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
The following packages will be upgraded:
ffmpeg iso-template-antix libavcodec-extra libavcodec-extra58 libavdevice58
libavfilter7 libavformat58 libavresample4 libavutil56 libpostproc55
libswresample3 libswscale5 packageinstaller-pkglist-libre
packageinstaller-pkglist-nonfree
14 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.7 MB of archives.
After this operation, 55.3 kB of additional disk space will be used.
Do you want to continue? [Y/n]

<snip>

dist-upgrade took 39.72 seconds
Creating database …
^[[Adatabase generation took 3.34 seconds

===============================================================================
antiX Command Line Package Installer
===============================================================================
(no pending upgrades)

Main Menu
> Search for packages to mark or install
> View a list of 84 suggested Command Line packages
> View a list of 165 suggested GUI packages
> Search for antiX kernels
> Search for all kernels
= Update package index (last update Fri 05 Nov 2021 09:32:46 PM EDT)
> Edit the repo source files
> Quit
Press <Enter> to select the highlighted entry
Use ‘h’ for help, ‘r’ to redraw, ‘q’ to quit
Doing apt-get update
=> apt-get update
Hit:1 http://deb.debian.org/debian bullseye-backports InRelease
Hit:2 http://mirrors.rit.edu/mxlinux/mx-packages/antix/bullseye bullseye InRelease
Hit:3 http://security.debian.org bullseye-security InRelease
Hit:4 http://ftp.us.debian.org/debian bullseye-updates InRelease
Hit:5 http://ftp.us.debian.org/debian bullseye InRelease
Reading package lists… Done
update took 7.60 seconds
<and so on>

My inxi
$ inxi -b
System: Host: antix1 Kernel: 5.10.57-antix.1-amd64-smp x86_64 bits: 64 Desktop: IceWM 2.8.0
Distro: antiX-21-runit_x64-full Grup Yorum 30 October 2021
Machine: Type: Laptop System: LENOVO product: 42983SU v: ThinkPad X220 Tablet serial: <superuser required>
Mobo: LENOVO model: 42983SU serial: <superuser required> UEFI-[Legacy]: LENOVO v: 8DET58WW (1.28 ) date: 02/14/2012
Battery: ID-1: BAT0 charge: 55.9 Wh (99.5%) condition: 56.2/62.6 Wh (89.8%)
ID-2: BAT1 charge: 7.6 Wh (13.5%) condition: 56.1/64.4 Wh (87.2%) volts: 11.0 min: 11.1
CPU: Info: Dual Core Intel Core i5-2520M [MT MCP] speed: 1285 MHz min/max: 800/3200 MHz
Graphics: Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics driver: i915 v: kernel
Device-2: Chicony Lenovo Integrated Camera (0.3MP) type: USB driver: uvcvideo
Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting unloaded: fbdev,vesa resolution: 1366×768~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 3000 (SNB GT2) v: 3.3 Mesa 20.3.5
Network: Device-1: Intel 82579LM Gigabit Network driver: e1000e
Device-2: Intel Centrino Advanced-N 6205 [Taylor Peak] driver: iwlwifi
Drives: Local Storage: total: 298.09 GiB used: 4.36 GiB (1.5%)
Info: Processes: 188 Uptime: 25m Memory: 7.66 GiB used: 1.1 GiB (14.4%) Shell: Bash inxi: 3.3.06

• This reply was modified 1 year, 6 months ago by bci.
• This reply was modified 1 year, 6 months ago by bci.
• This reply was modified 1 year, 6 months ago by bci.

[Author]

Posts