Nemesis update- v24.06 (2024-06-17)

[ncmprhnsbl]

So I wonder, using AUR, isn't there a risk that the software won't work because it depend on systemd?

yes (more like it will refuse to build) but at that point some investigation into why it might depend on systemd is required.
sometimes it's a just matter of editing the PKGBUILD depends field (eg. replacing libsystemd, with eudev for things that rely on the udev component of systemd)
other times it might require a build option (like --without-systemd)
mostly, a lot of stuff 'depends' on systemd because it provides service file for starting a daemon that might need to be reproduced as a openrc init file.
and then there's some stuff that uses some feature of systemd that nothing else provides.. can't really think of an example..
there's a package (which it looks like i haven't provided) called 'artix-archlinux-support' that is a sort of 'dummy' package that 'provides' systemd and libsystemd to trick pacman (and also provides some systemd-sysusers function for package hooks)
again, don't think that'll help with something requires an actual systemd function.
searching repology.org for the target can be helpful. anything packaged by void or slackware/slackbuilds or pclinuxos (others?) will definitely build/run without systemd.

[Ed_P]

However now looking at the server it's no longer from california but from phoenix

I think most large apps like SourceForge use multiple servers covering large areas of a country and try to even their use which is why a specific server link may not be the best approach.

[vinnie]

I think most large apps like SourceForge use multiple servers covering large areas of a country and try to even their use which is why a specific server link may not be the best approach.

now that I will download the new version of nemesis I will try to be more careful, I remember that before sourceforce allowed you to choose the server location, but now it just seemed to me that there was always only one choice
edit: can you see? only one server (california again): https://oshi.at/bWCW/ODeZ.mkv

searching repology.org for the target can be helpful. anything packaged by void or slackware/slackbuilds or pclinuxos (others?) will definitely build/run without systemd.

If I understand correctly, you can add alpine linux to the list, which also uses openrc but the scripts are practically identical to arch pkgbuild but without systemd

[vinnie]

I am downloading the iso again, same problem, really slow.

Code: Select all

wget https://sourceforge.net/projects/nemesis-linux/files/ISO/24.06/Nemesis-v24.06-CINNAMON-x86_64.iso/download
...
download                          8%[===>                                                  ]  38.72M  70.8KB/s    eta 2h 52m

when someone else tries to download, try to pay attention to the download speed, maybe this is only slow for me for some strange reason

[Ed_P]

I used Windows to download the Cinnamon ISO last night vinnie and it took 2-3 hrs. I saw speeds from 70kb/s to 170kb/s but no idea from which server. Maybe our speeds were low because we were downloading at the same time.

[vinnie]

I used Windows to download the Cinnamon ISO last night vinnie and it took 2-3 hrs. I saw speeds from 70kb/s to 170kb/s but no idea from which server. Maybe our speeds were low because we were downloading at the same time.

whatever, I managed to download it too, this time I only had to do it twice

I will now try to understand a little more about this distro, e.g. does the core.xzm module contain all the nemesis/porteus tools? so I can open it to see what's in it/

[Ed_P]

When booting the Cinnamon iso I see these 2 msgs:

Code: Select all

sh: xfs: unknown command
sh: ext: unknown command

6 lines below Starting init script

[M. Eerie]

I too am facing very slow download speeds from the only server that Sourceforge offers for this project (around 50 kbps).

does the core.xzm module contain all the nemesis/porteus tools?

I don't know exactly what you mean by all the nemesis/porteus tools. Nemesis uses the same concept as porteus in terms of modularity. That is, the components/modules of the distribution are like smaller and smaller layers from a bigger skeleton (the core module). This contains the basic structure of the file system and the scripts needed to add further layers:

1. GUI containing the subset of packages for the user interface
2. XTRA that adds a number of useful packages for multimedia/video functionalities
3. SHARED which includes a group of packages shared by the different types of desktops and finally
4. XFCE/CINAMMON/LXQT/LXDE which are the subset of packages that make up the desktop itself.

This means that you can boot with only the kernel and core modules (which includes a minimal Openbox desktop). As explained below, the GUI module is also required.

[vinnie]

I mean the specific tools created for porteus/nemesis, e.g. xzm2dir
It seems to me that for porteus they are in the /opt/porteus-scripts/ directory, whereas in nemesis they are in /usr/local/bin .
The question is if these are all in the core module, it seems to me that they are there, but there are also other things in core.

Edit:
for curiosity I tried to unpack the porteus xzm (core and kernel) but with find I can't find *openbox* inside them

[vinnie]

you can boot nemesis (or nearly anything else) from your existing porteus bootloader, you just need to add a menu entry for it pointing to the initrd.xz and vmlinuz and a from=path/to/folder in the APPEND line.. you can even have it on the same partition as your porteus folders.
eg. : for the same partition in a folder 'nemesis' place boot/{vmlinuz,initrd.xz} , porteus and config folders

Code: Select all

LABEL NEMESIS
MENU LABEL Nemesis Graphics mode
KERNEL /nemesis/boot/vmlinuz
INITRD /nemesis/boot/initrd.xz
APPEND from=/nemesis

or on sda4 place boot/{vmlinuz,initrd.xz} , porteus and config folders

Code: Select all

LABEL NEMESIS
MENU LABEL Nemesis Graphics mode
KERNEL /dev/sda3/boot/vmlinuz
INITRD /dev/sda3/boot/initrd.xz
APPEND from=/dev/sda3

not sure about this second one if this works for the kernel and initrd paths .. they can be on sda2 with config & porteus on sda3.
and from= can use a UUID
actually the from= might even be optional because initrd will search for the nemesis.sgn file in the porteus folder.

.


I am trying to start nemesis without overwriting syslinux but with little result.
First of all I unpacked the nemesis iso in /mnt/sda3, then I edit/mnt/sda2/boot/syslinux/porteus.cfg with different tests:
.

Code: Select all

LABEL NEMESIS
MENU LABEL Nemesis Graphics mode
KERNEL /dev/sda3/boot/syslinux/vmlinuz
INITRD /dev/sda3/boot/syslinux/initrd.xz
APPEND from:UUID=5a740eb2-c45d-4dab-8131-6130cb661966 resume=UUID=c4cd076d-4693-4c7a-8e90-26779517b781
TEXT HELP
    Nemesis nella partizione 3
ENDTEXT

this way it says it cannot find anything and I am forced to start another label of porteus
I'm actually happy that it doesn't work this way because I don't like having to specify the partition name (which changes if I have mass storage devices plugged into the usb during boot).
.

Code: Select all

...
KERNEL /dev/sda3/boot/syslinux/vmlinuz
INITRD /dev/sda3/boot/syslinux/initrd.xz
APPEND from=/dev/sda3
...

this does not work either
.

Code: Select all

...
KERNEL /boot/syslinux/vmlinuz
INITRD /boot/syslinux/initrd.xz
APPEND from:UUID=5a740eb2-c45d-4dab-8131-6130cb661966
...

Making these changes starts but loads the porteus modules instead of nemesis, so maybe a hybrid is started with the nemesis kernel and porteus modules!
.

Code: Select all

...
KERNEL /boot/syslinux/vmlinuz
INITRD /boot/syslinux/initrd.xz
APPEND root=UUID=5a740eb2-c45d-4dab-8131-6130cb661966:ext4
...

I also tried it this way, changing from from to root (I don't know what the difference is), but it works exactly the same as the previous attempt.
It also ask me during start-up that it could not find a porteus-v5.0-x86_64.cfg file (which is in the porteus iso but not in the nemesis iso, so maybe root instead of from doesn't work) and that would search in the disk for it.
.

it's not a big deal because eventually I will only start nemesis, but I wanted to try it out to see if it worked

[vinnie]

Ok, no way, I'm not able to do it.
I also tried adding this append "extramod=UUID=5a740eb2-c45d-4dab-8131-6130cb661966/porteus/base" and it works fine (I know it seems wrong, but it works indifferently if I put : or =)... I mean, "fine", it adds the list of modules as if they were other optional modules that can be loaded but does not consider them as booting module.
For this reason I've tried a little bit the combinations of from with the = and the : and it seems to me that this is the right one "from=UUID=5a740eb2-c45d-4dab-8131-6130cb661966" (just =) but still it doesn't work.

so, this was the complete last attempt:

Code: Select all

LABEL NEMESIS
MENU LABEL Nemesis Graphics mode
KERNEL /boot/syslinux/vmlinuz
INITRD /boot/syslinux/initrd.xz
APPEND from=UUID=5a740eb2-c45d-4dab-8131-6130cb661966 extramod=UUID=5a740eb2-c45d-4dab-8131-6130cb661966/porteus/base resume=UUID=c4cd076d-4693-4c7a-8e90-26779517b781
TEXT HELP
    Nemesis nella partizione 3
ENDTEXT

Now since I don't feel like waiting to use nemesis, I'll overwrite syslinux with its installer, though I can always do the reverse attempt (i.e., create a menu item for porteus on nemesis) when I know how it works.

[vinnie]

ok, nemesis started though there was a strange behavior.
The partition had never been used after being partitioned with gparted and I guess it had root as the owner.
Then I opened the iso with Engrampa archive manager started as root user and unpacked it to /mnt/sda3.
Then I started the installer.
At boot it booted but just before starting the windows manager it told me that /home/guest was not accessible.
So I booted another distro and changed the permissions of the contents of /mnt/sda3 (except for an ldlinux.sys file that was forbidden) and at boot nemesis started.
So the partition must have special permissions? (remember that I use ext4 and not fat32)

solved! in the best way, without knowing how
no seriously, i redid the procedure by mounting the iso this time and copying it with cp -a and there is no problem. I don't know how porteus can be so fast with copy2ram... but it works, it's undeniable, I was able to unmount the disk and format it while using the live distro.
Now I want to experiment a little bit with the change save file.
Ah I noticed that the interface to mount the modules is missing, is that intentional?

[M. Eerie]

It seems to me that for porteus they are in the /opt/porteus-scripts/ directory, whereas in nemesis they are in /usr/local/bin

Yes. Arch derivatives use a file structure slightly different from the Slackware ones.

I can't find *openbox* inside them

You're right. It is located in /usr/bin @ 002-gui-YYYYMMDD.xzm module.

[M. Eerie]

Ah I noticed that the interface to mount the modules is missing, is that intentional?

Note that Nemesis is not an exact copy of Porteus. It does not have the same tools.

In my version of MATE, you have two interfaces to activate/deactivate modules. One based on rofi (for the graphical mode) and one based on fzf for the terminal. You'll need both mate & matezcustoms modules for this to work.

[roadie]

Is anyone else getting a grey logout box.....commands work, but no colorful icons, just grey. I'm getting it in Xfce and Always Fresh. I've had no luck tracking down a file that shows any mention of the icon names for the logout box. I'm sure that no non-stock files are getting into the system at boot.

It happens only with guest user, root is fine.