Project : a Bento Openbox antiX

[Member manyroads]

Helpful

Up

0

::

No I really can’t. Kernels are quite subject to cpu vagaries. I can tell you that my Dell Latitude is very happy with anything not labeled Liqourix. I personally like the antix 64 bit kernels (they work very well for me). Right now I’m using the latest 5.2.15 antiX Kernel without problems, but YMMV.

• This reply was modified 3 years, 7 months ago by manyroads.

Pax vobiscum,
Mark Rabideau - http://many-roads.com
"For every complex problem there is an answer that is clear, simple, and wrong." H. L. Mencken
dwm & i3wm ~Reg. Linux User #449130
20 Jan 2021 ~ "End of an Error"

[Member melodie]

Helpful

Up

0

::

Alright, and what about the landing on the login screen in the live iso? Is there a way to avoid that and have the boot from ISO go straight to the desktop?

[Member manyroads]

Helpful

Up

0

::

Not that I know of…

Pax vobiscum,
Mark Rabideau - http://many-roads.com
"For every complex problem there is an answer that is clear, simple, and wrong." H. L. Mencken
dwm & i3wm ~Reg. Linux User #449130
20 Jan 2021 ~ "End of an Error"

[Member manyroads]

Helpful

Up

0

::

Melodie, If you are interested here’s something I’m working on with OpenBox, BunsenLabs, & MX19b3…

https://forum.mxlinux.org/viewtopic.php?f=100&p=532185#p532185

Pax vobiscum,
Mark Rabideau - http://many-roads.com
"For every complex problem there is an answer that is clear, simple, and wrong." H. L. Mencken
dwm & i3wm ~Reg. Linux User #449130
20 Jan 2021 ~ "End of an Error"

[Anonymous]

Helpful

Up

0

::

a way to avoid that and have the boot from ISO go straight to the desktop?

you can set autologin via ControlCenter gui

or by running this command from terminal:

python /usr/local/bin/slim-login

or by manually editing 2 lines within /etc/slim.conf

### Automatically login the default user (without entering the password)
### Set to “yes” to enable this feature
auto_login yes

### default user (leave blank or remove this line to avoid pre-loading the username)
default_user your_chosen_username

Make this change on the running system before launching the isosnapshot tool, and it will be reflected in the snapshot result.

[Member melodie]

Helpful

Up

0

::

Thank you skidoo,

you are right! Except that I have switched slim for lightdm, I’ll just have to set autologin for the “demo” user, that should do the trick. For the rest, well, some things now work, then after installing in Virtualbox the reboot does not finish the boot.

I’ll try the next test version in a regular computer, on bare metal.

[Member melodie]

Helpful

Up

0

::

manyroads wrote:

Melodie, If you are interested here’s something I’m working on with OpenBox, BunsenLabs, & MX19b3…

https://forum.mxlinux.org/viewtopic.php?f=100&p=532185#p532185

Can you produce an ISO smaller than 700MB? If so I can give it a whirl on the D610 I have.

[Member manyroads]

Helpful

Up

0

::

No the base MX is much larger than 700MB. The latest mx19-b3 version is 1.5GB.

Pax vobiscum,
Mark Rabideau - http://many-roads.com
"For every complex problem there is an answer that is clear, simple, and wrong." H. L. Mencken
dwm & i3wm ~Reg. Linux User #449130
20 Jan 2021 ~ "End of an Error"

[Member melodie]

Helpful

Up

0

::

manyroads wrote:

No the base MX is much larger than 700MB. The latest mx19-b3 version is 1.5GB.

Sorry, that can’t do.

[Member manyroads]

Helpful

Up

0

::

No problem… MX is, pretty much, what it is. I have no real control over its size. I did create a minimum install with version 18. You are certainly welcome to see if you want to use that process against MX19b3 and come up with a size you like. Most of that work is here:
https://forum.mxlinux.org/viewtopic.php?f=39&t=47910

Pax vobiscum,
Mark Rabideau - http://many-roads.com
"For every complex problem there is an answer that is clear, simple, and wrong." H. L. Mencken
dwm & i3wm ~Reg. Linux User #449130
20 Jan 2021 ~ "End of an Error"

[Member manyroads]

Helpful

Up

0

::

@melanie. whoo- rah. BunsenLabs is now running on antiX19b3. It booted cleanly and is operational. I needed to clean off all the standard desktops, slim and replace the display manager with lightdm. Tada!

I’ll begin working on building an antiX19 version of BunsenLabs Lithium as well as the one for MXLinux19b3.

If you wish to build your Bento Box using this base, I am happy to share it with you.

Pax vobiscum,
Mark Rabideau - http://many-roads.com
"For every complex problem there is an answer that is clear, simple, and wrong." H. L. Mencken
dwm & i3wm ~Reg. Linux User #449130
20 Jan 2021 ~ "End of an Error"

[Member melodie]

Helpful

Up

0

::

manyroads wrote:

@melanie. whoo- rah. BunsenLabs is now running on antiX19b3. It booted cleanly and is operational. I needed to clean off all the standard desktops, slim and replace the display manager with lightdm. Tada!

I’ll begin working on building an antiX19 version of BunsenLabs Lithium as well as the one for MXLinux19b3.

If you wish to build your Bento Box using this base, I am happy to share it with you.

Hello manyroads,

it is very nice of you. Thank you! I am also happy to share the “Bento recipe” with you. There is a mind map of the files and dedicated configs here:
https://gitlab.com/bento-openbox ( mind map pdf : https://gitlab.com/bento-openbox/bento-filesystem/blob/master/Bento-Openbox-Filesystem.pdf which can help getting the idea on how it’s built )

for the time being it runs fine in the D610 Dell laptop, just until now I don’t get yet an ISO worth sharing.

One more issue I meet with: I can’t get zram config to work out of the box. I’d like it to run currently in the system. I tried the package from the repos, I tried also an ancient config which used to work in Debian ( https://phillw.net/isos/bento-ubuntu-remix/miscellaneous/Debian/zramconfig/ ), no way.

I someone wants to try and help find why it does not / cannot stick after reboot it would be nice (also it worked only once installed after I started it manually).

[Member melodie]

Helpful

Up

0

::

Hello, my test version number 7 starts to have more or less the right behavior, just this strange thing that happens at the first boot of the live, the distro given name is replaced with the macro commands, which is very very ugly.

Please see the screenshot, and please tell me how I can get the system to display the dedicated name instead of the macro commands?

One more, how can I get the installer to show on the desktop in the live?

Thanks for your help!

• This reply was modified 3 years, 7 months ago by melodie.

Attachments:

1. 

   gscreenshot_2019-10-10-164840.png
   

2. 

   gscreenshot_2019-10-10-164840-1.png
   

[Anonymous]

Helpful

Up

0

::

melodie, the snapshot tool contains a longstanding bug (reported across years) described as “I specify a custom namelabel for the boot menu, but the custom name is not displayed when I boot a system produced via the snapshot tool“. However, the symptoms of _that_ bug case do not include presence of % percent placeholders in the labelname. From a troubleshooting standpoint, we can’t guess whether you have encountered a separate, newly introduced, bug ~~ without hearing exact O/S version (e.g. antiX Full 17.4.1) (and, dist-upgrade was performed immediately prior to running the snapshot tool?) along with the exact installed versions of packages: “iso-snapshot-antix”, “remaster-antix”, “iso-template-antix”. During troubleshooting I would also ask: is the package “xorriso” currently installed on the machine performing the snapshot operation.

Skip the troubleshooting.
The following instructions should enable you to achieve the desired result.

1) Prior to launching isosnapshot, edit /etc/isosnapshot.conf and ensure that it contains this declaration:
edit_boot_menu=yes

2) Launch isosnapshot. During the workflow, when the “will now pause” dialogbox is displayed
and an editor window populated with “isosnapshot.cfg” opens…
ignore minimize (do not close/exit) that editor window.
(Do not close, because the snapshot operation will immediately resume upon closure of that editor window.)

3) While the isosnapshot program is paused, use a file manager (asRoot), and browse to /tmp directory.
Look for a /tmp subdirectory named “snapshot-123abc” (tailend is randomly chosen each time isosnapshot runs).
If you do not find it under /tmp, look for it under /home/snapshot/ ( e.g. /home/snapshot/snapshot-123abc/ )

To perform customizations, you will need to edit various (multiple) files.
After performing all desired edits, close that “auto-opened” editor window instance and the isosnapshot process will resume.

4) Don’t shoot the messenger. I’m attempting to coach you toward a successful outcome ~~ replies stating “should be easier” or “bugs should be fixed” will not be helpful here.

{work_dir}/iso-template/boot/syslinux/syslinux.cfg
{work_dir}/iso-template/boot/syslinux/readme.msg
    ^---- applicable to liveUSB boot menu
    
{work_dir}/iso-template/boot/isolinux/isolinux.cfg
{work_dir}/iso-template/boot/isolinux/readme.msg
    ^---- applicable to LiveCD boot menu
    
{work_dir}/iso-template/boot/grub/theme/theme.txt
{work_dir}/iso-template/boot/grub/grub.cfg

FWIW, these files wind up residing in the /boot subdirectory of the liveboot media, and they can be edited in place to customize an already-made liveUSB device. (This bit of trivia is not useful for someone intending to redistribute a customized ISO though.)

================

I believe the longstanding bug is due to the fact that only isosnapshot.cfg is presented for editing.
During liveboot, that cfg file is only referenced if isolinux (liveCD) is the bootloader.
The devs probably test in virtualbox, with the ISO set as a liveboot CD, and find “Hey, it works for me”.
However, for anyone booting liveUSB the syslinux bootloader is invoked.
Perhaps the configuration setting “make_isohybrid=yes” is expected to cause the syslinux bootloader to load isolinux.cfg (instead of syslinux.cfg)… but apparently, in practice, it is not doing so. Because the user never had easy opportunity to edit the copy of syslinux.cfg residing in the snapshot “work_dir”, the stock version of that file is perpetuated, and its content is evident during syslinux (liveUSB) boot sessions.

Because bugfixes and improvements to the upstream (MX) version of the snapshot tool have not been ported to the antiX 0.3.7 version (shipped in antiX19 beta, but absent from antiX gitlab repo), for local use I created a bespoke derivative version. Its workflow still remains a bit awkward but, yes, it does attempt to provide better inline instruction regarding customization. Many of the changes I’ve incorporated may not be regarded as desirable by the antiX/MX devs (the ui and helptext drown the user in details, are quite verbose), so I haven’t yet published the source code to gitlab.

[Anonymous]

Helpful

Up

0

::

how can I get the installer to show on the desktop in the live?

Prior to launching isosnapshot, edit /etc/isosnapshot.conf and ensure that it contains this declaration:
force_installer=true

Also, ensure that an internet connection is available when you launch the isosnapshot tool.
When run on an already-installed system, isosnapshot must (re-download and setup) the installer package.

[Author]

Posts