2021 Updated Nemesis Base Modules

[M. Eerie]

How can I store my wireless connections?

I've saved /etc/NetworkManager/system-connections/*.nmconnection

in my rootcopy folder, but NetWorkManager doesn't seem to recognize them after reboot.

[ncmprhnsbl]

The one included in the skel.zip at first post, seems to be different.

the initrd.xz should be the same as it always was... the skel.zip itself was reuploaded with vmlinuz removed (shouldn,t have been there)

How can I store my wireless connections?

not sure off the top of my head. but if you now have porteus.conf working properly, take a look at <install_media>/config/network file.. uncomment/fill out what you need..
that's what i use

[M. Eerie]

but if you now have porteus.conf working properly

Sadly not. Boot was fine with the old kernel from the 3.5 ISO. I was wrongly blamming the initrd.xz , but this has come with newer kernel versions...

This is what /var/log/rc.log says:

Code: Select all

...

 * Bringing up interface lo
 *   Caching network module dependencies
need dbus
 *   127.0.0.1/8 ...
 [ ok ]
 *   Adding routes
 *     127.0.0.0/8 via 127.0.0.1 ...
 [ ok ]
 [ ok ]
 * Setting up sysusers.d entries ...
 [ ok ]
 * Setting up tmpfiles.d entries ...
 [ ok ]
/etc/init.d/prelogin: line 19: /etc/porteus.d/cheatcodes: No such file or directory
 * ERROR: prelogin failed to start
 * Saving key mapping ...
 [ ok ]
 * Saving terminal encoding ...
 [ ok ]

rc boot logging stopped at Fri Jul 12 06:17:24 2019


rc default logging started at Fri Jul 12 06:17:24 2019

 * Starting NetworkManager ...
 [ ok ]
Connecting.............      1sConnecting..............     1sConnecting...............    1sConnecting...............    0s [offline]
 * Marking NetworkManager as inactive. It will automatically be marked
 * as started after a network connection has been established.
 * WARNING: NetworkManager has started, but is inactive
 * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ...
Error parsing source statement, source plugin unix-dgram not found in source generator system:6:14-6:24:
1       
2       #Start Block source generator system
3       channel {
4           source {
5       channel {
6----->     source { unix-dgram("/dev/log" so_rcvbuf(8192) flags(syslog-protocol));
6----->              ^^^^^^^^^^
7        };
8           rewrite { set("${.unix.pid}" value("PID") condition("${.unix.pid}" ne "")); };
9       };
10      file("/dev/kmsg" program-override("kernel") flags(kernel) format(linux-kmsg) keep-timestamp(no));
11      

Included from /etc/syslog-ng/syslog-ng.conf:22:3-22:11:
17        perm(0640);
18        group("log");
19      };
20      
21      source src {
22---->   system();
22---->   ^^^^^^^^
23        internal();
24      };
25      
26      destination d_authlog { file("/var/log/auth.log"); };
27      destination d_syslog { file("/var/log/syslog.log"); };


syslog-ng documentation: https://www.balabit.com/support/documentation?product=syslog-ng-ose
contact: https://lists.balabit.hu/mailman/listinfo/syslog-ng
 * Configuration error. Please fix your configfile (/etc/syslog-ng/syslog-ng.conf)
 [ !! ]
 * ERROR: syslog-ng failed to start
 * Starting acpid ...
 [ ok ]
 * Starting user network from config file ...
boot-network-setup Line 267: Fri Jul 12 06:17:27 UTC 2019

ERROR in boot-network-setup on line 271:
Could not find /etc/porteus.d/network

 [ ok ]
 * WARNING: netmount will start when NetworkManager has started
/etc/init.d/prelogin: line 19: /etc/porteus.d/cheatcodes: No such file or directory
 * ERROR: prelogin failed to start
 * Starting local ...
 [ ok ]

rc default logging stopped at Fri Jul 12 06:18:46 2019

Are you using other kernel than the (5.0.7) one posted here at #1? If so, could you please share?

Thanks!

[ncmprhnsbl]

re you using other kernel than the (5.0.7) one posted here at #1?

no..
kernel shouldn't really affect this..
here's the md5sum for the initrd.xz : 5935f21724832bb699c779b63d132179 to make sure it's the right one..

[M. Eerie]

I've just imported skel.zip and vmlinuz and kernel into my MEGA account just to try.

I'm pretty sure if you mix the initrd.xz from skel.zip and any other kernel update results in porteus.d gone to /dev/null

I'm trying right now and will report back.

Cheers!

[M. Eerie]

take a look at <install_media>/config/network file..

I have Ignore=yes in that file.

Should I set my network there or can I configure the network options under <install_media>porteus/porteus-v4.0-x86_64.cfg file?

Which one is to be parsed at boot / overwritten?

How can it be automatically set?

Thanks

[ncmprhnsbl]

or can I configure the network options under <install_media>porteus/porteus-v4.0-x86_64.cfg file?

nemesis has no such file..
all configs go in the relevent <install_media>/config/ file .. (cheatcodes go in /boot/syslinux/porteus.cfg > APPEND line)
if Ignore=yes is commented(#) it will not be ignored
other settings should be uncommented and the appropriate info supplied..

How can it be automatically set?

not automatic but: one way might be to setup via network manager gui and then run:

Code: Select all

# changes-time 

this captures the recent changes(the default is three minutes) and saves to /root
you should be able to see what folders/files you need to save as a module for your network settings..

[ncmprhnsbl]

from another thread:

Kernel 5.1.17 this is my /var/log/rc.log

Code: Select all

* Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ...
Error parsing source statement, source plugin unix-dgram not found in source generator system:6:14-6:24:
1
2 #Start Block source generator system
3 channel {
4 source {
5 channel {
6-----> source { unix-dgram("/dev/log" so_rcvbuf(8192) flags(syslog-protocol));
6-----> ^^^^^^^^^^
7 };
8 rewrite { set("${.unix.pid}" value("PID") condition("${.unix.pid}" ne "")); };
9 };
10 file("/dev/kmsg" program-override("kernel") flags(kernel) format(linux-kmsg) keep-timestamp(no));
11

Included from /etc/syslog-ng/syslog-ng.conf:22:3-22:11:
17 perm(0640);
18 group("log");
19 };
20
21 source src {
22----> system();
22----> ^^^^^^^^
23 internal();
24 };
25
26 destination d_authlog { file("/var/log/auth.log"); };
27 destination d_syslog { file("/var/log/syslog.log"); };


syslog-ng documentation: https://www.balabit.com/support/documen ... log-ng-ose
contact: https://lists.balabit.hu/mailman/listinfo/syslog-ng
* Configuration error. Please fix your configfile (/etc/syslog-ng/syslog-ng.conf)
[ !! ]
* ERROR: syslog-ng failed to start
* Starting acpid ...

At least /etc/porteus.d is back again

Thanks

this a bug(my fault) : missing package : libnet
will include with next update

[M. Eerie]

not automatic but: one way might be to setup via network manager gui and then run:

Code: Select all

# changes-time


this captures the recent changes(the default is three minutes) and saves to /root
you should be able to see what folders/files you need to save as a module for your network settings..

I'm glad to say I'm finally got a clean and (almost) fully functional Nemesis from boot to logout.

Only thing I've found to fail is you can't install Nemesis in other USB stick with newer kernels. It results in a segment violation message.

Thanks for all your support.

[ncmprhnsbl]

update 2019-07-28
core:

Code: Select all

bzip2
ca-certificates-mozilla
curl
dnssec-anchors
fuse-common
glib2
glibc
gnutls
iana-etc
iproute2
js60
libinput
libmm-glib
libnm
libnm-glib
libtasn1
libteam
libtool
nettle
networkmanager
nss
openresolv
tzdata
sqlite
wget
zstd

added libnet : fixes syslog-ng

gui:

Code: Select all

freetype2freetype2
giflib
glu
gtk-update-icon-cache
gtk-update-icon-cache
libdrmlibdrm
libice
libpciaccess
llvm-libs
mesa
xf86-video-intel
xorg-server
xorg-server-commonxorg-server
xorg-server-common
xorg-setxkbmap
xorg-xauthxorg-xauth
xorg-xbacklight
xorg-xinput
xterm

xtra:

Code: Select all

aom
desktop-file-utils
ffmpeg
lcms2
libev
libssh
libvalibssh
libva
libvpx
libwbclient
libwebp
mpg123
sdl2
x265

xfce4:

Code: Select all

argon2
btrfs-progs
exo
garcon
gtk3
gvfs
iso-codes
libxfce4ui
libxfce4util
ristretto
thunar
thunar-volman
tumbler
xfce4-power-manager
xfce4-terminal
xfdesktop

[neko]

Nemesis 2019-07-28 with kernel 5.2.4

nemesis-xfce-19.07.28-k5.2.4-x86_64.iso (415 M)
http://www.mediafire.com/file/fu9cvbaoj ... x86_64.iso
md5sum: b1c065c76eb09076b389cbdd12fdab03 nemesis-xfce-19.07.28-k5.2.4-x86_64.iso

1. ISO Base was built with the skeleton & modules
were gotten from 2019 Updated Nemesis Base Modules (Post by ncmprhnsbl #61949)

2. boot/syslinux/vmlinuz and porteus/base/000-kernel.xzm
were replaced with "kernel 5.2.4".

Please refer to Porteus Kernel Builder

3. Additional modules
[ISO@porteus/modules/004-google-chrome-75.0.3770.142-1-x86_64-1DUOWif.xzm]
was created by "mkgoogle-chrome" command.

[ISO@porteus/modules/004-libxss-1.2.3-x86_64-1.xzm]
004-libxss-1.2.3-x86_64-1.xzm includes the google-chrome dependency libraries (libXss.so libXss.so.1 libXss.so.1.0.0).

Note:
libxss-1.2.3-x86_64-1 was obtained by APorteus tool, not pacman.
Therefor this libxss-1.2.3-x86_64-1 is out of the control of pacman.
If pacman will be used, delete (deactivate) this libxss-1.2.3-x86_64-1 and obtain one by packman.

[ISO@porteus/optional/06-crippled_sources-5.2.4-64bit.xzm]
Kernel header (crippled_sources) for ISO installation into virtual environment is included in ISO.


Thanks.

[jssouza]

First time nemesis user

First of all, good job ncm

Couldn't we make initrd same as Porteus 5? With latest fixes and newer busybox? To start with, I see it still uses the old .sgn mechanism and an old method of reading config files from boot medium which could be easily incorporated into .cfg file of Porteus 5.

Kernel: Porteus kernel does not work with nemesis kernel. Why not integrate both? Maybe this is a question to @neko

[ncmprhnsbl]

Couldn't we make initrd same as Porteus 5? With latest fixes and newer busybox? To start with, I see it still uses the old .sgn mechanism and an old method of reading config files from boot medium which could be easily incorporated into .cfg file of Porteus 5.

maybe and yes.. it could certainly do with some love..
i was under the impression that the "old method of reading config files from boot medium" was something brokenman introduced around the birth of nemesis and potentially contains more info than cheatcodes..
havn't really looked at it.. have really only been updating the packages..

Kernel: Porteus kernel does not work with nemesis kernel. Why not integrate both?

well, not ootb, but it does work with modification.. the issue, as i see it, is the difference between slackware and arch filesystems:
in arch /lib, /lib64 are symlinks to /usr/lib (and /bin, /sbin to /usr/bin) and in slackware they're not..
maybe the /lib symlinks could be removed in the higher(001.002 003) modules, so they don't overwrite the kernel modules.. without breaking anything else...

[neko]

@jssouza
@ncmprhnsbl already has answered.

it, is the difference between slackware and arch filesystems

@ncmprhnsbl, thanks.

Usually I update the kernel of ISO with "Kernel Builder" tool.

Example:
Tool
mkKernel-19.07.31-noarch-1.xzm (5.5 M)
http://simosnet.com/livecd/isobuilder/k ... arch-1.xzm
md5sum: 3c7c3b2154e950cdea9de11515f0472f mkKernel-19.07.31-noarch-1.xzm

kernel 5.3-rc5
64bit-ALL-kernel5.3-rc5.tar (95 M)
http://www.mediafire.com/file/nsrnwblmw ... .3-rc5.tar
md5sum: 076ac0f2f1f6fe4460fb54d9d0719203 64bit-ALL-kernel5.3-rc5.tar

ISO
nemesis-xfce-19.07.28-k5.2.4-x86_64.iso (415 M)
http://www.mediafire.com/file/fu9cvbaoj ... x86_64.iso
md5sum: b1c065c76eb09076b389cbdd12fdab03 nemesis-xfce-19.07.28-k5.2.4-x86_64.iso

Porteus-OPENBOX-v5.0rc1-x86_64.iso

APorteus-MULT-v19.08.10-x86_64.iso (685 M)
http://www.mediafire.com/file/3g42m9cf3 ... x86_64.iso
md5sum: 1c0f46698daefc441ec71de5bfcaf9e5 APorteus-MULT-v19.08.10-x86_64.iso

Code: Select all

% su
# ls -1 */
iso:
APorteus-MULT-v19.08.10-x86_64.iso
Porteus-OPENBOX-v5.0rc1-x86_64.iso
nemesis-xfce-19.07.28-k5.2.4-x86_64.iso

work:
64bit-ALL-kernel5.3-rc5.tar
mkKernel-19.07.31-noarch-1.xzm
#
# cd work
# activate mkKernel-19.07.31-noarch-1.xzm
# mkdir -p v5.3-rc5/64
# cd v5.3-rc5/64
# tar -xf ../../64bit-ALL-kernel5.3-rc5.tar
# mloop 000-kernel.xzm
# cp -a /mnt/loop/lib .
# uloop

==GUI==
(1)nemesis-xfce-19.07.28-k5.2.4-x86_64.iso
"Porteus Kernel Builde" ----> setting window
<setting window>
set working direcory (work)
select kernel version (5.3-rc5)
check on "keep org" item
select ISO whose kernel will be updated. (iso/nemesis-xfce-19.07.28-k5.2.4-x86_64.iso)
push "OK" button
<confirm window>
push "OK" button

(2)Porteus-OPENBOX-v5.0rc1-x86_64.iso
"Porteus Kernel Builde" ----> setting window
<setting window>
set working direcory (work)
select kernel version (5.3-rc5)
check on "keep org" item
select ISO whose kernel will be updated. (iso/Porteus-OPENBOX-v5.0rc1-x86_64.iso)
push "OK" button
<confirm window>
push "OK" button

(3)APorteus-MULT-v19.08.10-x86_64.iso
"Porteus Kernel Builde" ----> setting window
<setting window>
set working direcory (work)
select kernel version (5.3-rc5)
check off "keep org" item
select ISO whose kernel will be updated. (iso/APorteus-MULT-v19.08.10-x86_64.iso)
push "OK" button
<confirm window>
push "OK" button

Note:
If you need the "crippled_sources",
copy from work/v5.3-rc5/64/06-crippled_sources-5.3-rc5-64bit.xzm.


Thanks.

[jssouza]

the issue, as i see it, is the difference between slackware and arch filesystems:
in arch /lib, /lib64 are symlinks to /usr/lib (and /bin, /sbin to /usr/bin) and in slackware they're not..
maybe the /lib symlinks could be removed in the higher(001.002 003) modules, so they don't overwrite the kernel modules.. without breaking anything else...

Here's a thought: Instead of changing in the higher modules, why not change in the 000-kernel this way:
Let /usr/lib/modules be an actual directory in 000-kernel. When make modules install is done let MOD_INC_DIR be /usr/lib/modules/`uname -r`. Once modules are installed in /usr/lib/modules, create a symlink to /usr/lib/modules in /lib/modules, that is /lib/modules -> /usr/lib/modules/ in 000-kernel.
In nemesis, when the higher modules overwrite /lib as symlink to /usr/lib, /lib/modules would still be present.
In porteus, /lib/modules would also be present, as it is a symlink to /usr/lib/modules.

Have to see the bind mounts that linuxrc creates during early boot to /lib/modules - if they work with symlinks.

Other option would be to bind mount /lib/modules in the actual root from linuxrc, from a temporary space of the initrd (say, /mnt/live/opt). It is currently done in the initrd, but then unmounted, once live system is ready to boot. But this requires a change in the initrd.