It seems your changes module/space is being overwritten somehow. Maybe you are using a module that launches a routine to do it... I think you should isolate module by module and see what happens. The changes-time script can be useful for capturing changes that occur over a given period of time.
2021 Updated Nemesis Base Modules
Moderator: M. Eerie
2021 Updated Nemesis Base Modules
> Does not compute_
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
2021 Updated Nemesis Base Modules
If I recall, there is some script in initrd expecting a '000-kernel.xzm' module. Maybe the Networkmanager error comes from there.
> Does not compute_
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
-
- Contributor
- Posts: 1857
- Joined: 09 Aug 2013, 14:25
- Distribution: Porteus and Nemesis
- Location: USA
2021 Updated Nemesis Base Modules
Well I try this I remove the changes directory and I replace my mate with ncmprhnsbl LXDE and guest what the same thing happen. Everything on the boot USB wasn't mind so I know cause the problem.M. Eerie wrote: ↑21 Nov 2021, 10:09It seems your changes module/space is being overwritten somehow. Maybe you are using a module that launches a routine to do it... I think you should isolate module by module and see what happens. The changes-time script can be useful for capturing changes that occur over a given period of time.
Here is what my USB look like.
I just like Slackware because I think it teach you about Linux to build packages where Ubuntu is like Windows you just install programs you want.
- ncmprhnsbl
- DEV Team
- Posts: 3933
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
2021 Updated Nemesis Base Modules
the log where these messages are stored is /var/log/rc.log (or something like that) ..it's the log for openrc services startup
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
- Rava
- Contributor
- Posts: 5401
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
2021 Updated Nemesis Base Modules
I will boot up up again and look into /var/log/rc.log and report here.ncmprhnsbl wrote: ↑21 Nov 2021, 21:36the log where these messages are stored is /var/log/rc.log (or something like that) ..it's the log for openrc services startup
Added in 2 minutes 8 seconds:
Probably It is no longer the case (as it should be, in my book) since ncmprhnsbl not replied to that part.
-
- Contributor
- Posts: 1857
- Joined: 09 Aug 2013, 14:25
- Distribution: Porteus and Nemesis
- Location: USA
2021 Updated Nemesis Base Modules
Here is what might be wrong after black screen.
It could be all about the tty4 or tty1 I think.Porteus Linux 5.12.18-Porteus (tty4)
Porteus Login: guest
password:
Last Login: Sun Nov 21 on (tty1)
I just like Slackware because I think it teach you about Linux to build packages where Ubuntu is like Windows you just install programs you want.
- ncmprhnsbl
- DEV Team
- Posts: 3933
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
2021 Updated Nemesis Base Modules
well, it may well be the case : line 219+ of linuxrc:
Code: Select all
# Make all drivers available:
mount -o loop $PTH/base/000-kernel.xzm /opt/000-kernel 2>/dev/null
mount -o bind /opt/000-kernel/usr/lib/modules /usr/lib/modules 2>/dev/null
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
- Rava
- Contributor
- Posts: 5401
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
2021 Updated Nemesis Base Modules
and the 2>/dev/null makes all possible error messages about a renamed 000-kernel.xzm disappear.ncmprhnsbl wrote: ↑22 Nov 2021, 03:48it may well be the case : line 219+ of linuxrc:same(ish) in standard initrd too..Code: Select all
# Make all drivers available: mount -o loop $PTH/base/000-kernel.xzm /opt/000-kernel 2>/dev/null mount -o bind /opt/000-kernel/usr/lib/modules /usr/lib/modules 2>/dev/null
I wonder, with Port 5.0rc3 I use initrd.xz:20200108 and kernel 5.4.30-porteus. My base/000-kernel is called 000-kernel5.4.30.xzm and I never had issues.
Is what you wrote only true for Nemesis?
Cheers!
Yours Rava
Yours Rava
- ncmprhnsbl
- DEV Team
- Posts: 3933
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
2021 Updated Nemesis Base Modules
same for slackware porteus(paths differ) .. .though this is fairly early in the boot process, hard to say how important it is..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
-
- Full of knowledge
- Posts: 400
- Joined: 02 Jan 2011, 18:41
- Distribution: Porteus 5.0-RC1
- Location: In a hayfield
2021 Updated Nemesis Base Modules
Is the 000-kernel module for Nemesis set up for the Arch file structure, as in /usr/lib/modules....rather than /lib/modules?
I've done that before when I used Nemesis, it boots but no modules are available.
- Rava
- Contributor
- Posts: 5401
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
2021 Updated Nemesis Base Modules
A strange bug - when it is one. dir2xzm returns a non zero value (it returns a "1") even when all should be okay and it should return a zero value. Look for yourself
I found this bug when executing my make-991-usr_local_bin.sh script suite since it checks the return value of dir2xzm and it presumes when the return value is non-zero then something went wrong. Usually that is the case since a zero return value means "all is well" and any non-zero return value always means "something went wrong". For some reason Nemesis dir2xzm returns a "1" when all seems well, it reports no error and presumably should return a "0".
In that case I coded my script to abort and give a bold and red error message and return with a non zero value of its own.
Therefore I conducted the above test to see if dir2xzm always returns a non zero value even when all is okay… which it does.
____________________________
Nemesis boot bug
I renamed 000-kernel5.12.18-porteus.xzm back to 000-kernel.xzm but there are still some bugs and/or weird error messages during boot.
Maybe Nemesis got confused by my cheatcodes? I just use the same as for Porteus:
Seems Nemesis kernel cannot handle the fsck cheatcode?
See the messages as recorded during boot time:
The issue here: there is no such device as sdc2. sdc1 is the SDHC card that sits in its USB reader and that holds the kernels, the initrd and the porteus.cfg while all the rest is on the internal drive directed to be loaded via the UUID cheatcode.
The SDHC card only has one partition as fdisk reports correctly:
Still no clue about these errors:
Currently I am back in Porteus 5.0rc3 since I need a running system to type my stuff so I currently cannot research the above errors. But I can bootup Nemesis again. Just tell me if
● I need to change cheatcode(s)
● I should examine some details, like do a ls -o /usr/sbin/NetworkManager
Code: Select all
Porteus Linux 5.12.18-porteus (tty4)
porteus login: root
Password:
Last login: Tue Nov 23 05:41:27 on tty2
grep: /etc/porteus.d/login: No such file or directory
[porteus ~]# cd /tmp
[porteus tmp]# mkdir dir2xzmtest
[porteus tmp]# touch dir2xzmtest/empty.dummy
[porteus tmp]# dir2xzm dir2xzmtest/ dir2xzmtest.xzm
./
Parallel mksquashfs: Using 8 processors
Creating 4.0 filesystem on dir2xzmtest.xzm, block size 262144.
[| ] 0/0 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
compressed data, compressed metadata, compressed fragments,
compressed xattrs, compressed ids
duplicates are removed
Filesystem size 0.24 Kbytes (0.00 Mbytes)
106.06% of uncompressed filesystem size (0.23 Kbytes)
Inode table size 66 bytes (0.06 Kbytes)
100.00% of uncompressed inode table size (66 bytes)
Directory table size 33 bytes (0.03 Kbytes)
100.00% of uncompressed directory table size (33 bytes)
Number of duplicate files found 1
Number of inodes 2
Number of files 1
Number of fragments 0
Number of symbolic links 0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
4.0K dir2xzmtest.xzm
[porteus tmp]# echo $?
1
[porteus tmp]#
In that case I coded my script to abort and give a bold and red error message and return with a non zero value of its own.
Therefore I conducted the above test to see if dir2xzm always returns a non zero value even when all is okay… which it does.
____________________________
Nemesis boot bug
I renamed 000-kernel5.12.18-porteus.xzm back to 000-kernel.xzm but there are still some bugs and/or weird error messages during boot.
Maybe Nemesis got confused by my cheatcodes? I just use the same as for Porteus:
Code: Select all
APPEND initrd=initrd.xz from=UUID:RaNd0m/Porteus_Nemesis ramsize=10% zram=20% timezone=Europe/Berlin volume=75% kmap=de lang=de fsck 3
See the messages as recorded during boot time:
The issue here: there is no such device as sdc2. sdc1 is the SDHC card that sits in its USB reader and that holds the kernels, the initrd and the porteus.cfg while all the rest is on the internal drive directed to be loaded via the UUID cheatcode.
The SDHC card only has one partition as fdisk reports correctly:
Code: Select all
root@porteus:~# fdisk -l /dev/sdc
Disk /dev/sdc: 1.84 GiB, 1977614336 bytes, 3862528 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8890a2b0
Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 135 3862527 3862393 1.8G 83 Linux
Currently I am back in Porteus 5.0rc3 since I need a running system to type my stuff so I currently cannot research the above errors. But I can bootup Nemesis again. Just tell me if
● I need to change cheatcode(s)
● I should examine some details, like do a ls -o /usr/sbin/NetworkManager
Cheers!
Yours Rava
Yours Rava
2021 Updated Nemesis Base Modules
/mnt/sde1/home/beny/Scaricati/Nemesis-20210724-XFCE-x86_64/porteus/base/squashfs-root/sbin/NetworkManager
/mnt/sdg1/aport/base-nemesis22-11/squashfs-root/sbin/NetworkManager
the first line is the old version the second the rebuild with the M.Eeire script.
i think maybe better to not rename nothing at the first boot when all went ok we can do some change.
/mnt/sdg1/aport/base-nemesis22-11/squashfs-root/sbin/NetworkManager
the first line is the old version the second the rebuild with the M.Eeire script.
i think maybe better to not rename nothing at the first boot when all went ok we can do some change.
- ncmprhnsbl
- DEV Team
- Posts: 3933
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
2021 Updated Nemesis Base Modules
just to be clear: in Nemesis: /sbin and /usr/sbin are symlinks to /usr/bin
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
- Rava
- Contributor
- Posts: 5401
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
2021 Updated Nemesis Base Modules
#282 , #283
@ncmprhnsbl
@beny
According to you the error could not have happened, but it did.
The 00[123]-* modules are all named like they are originally. Still it reports the error during boot and no NetworkManager in XFCE.
___________________________________
@ncmprhnsbl
What about the "dir2xzm returns a non zero value" issue I described? I extra did a test to demonstrate the behaviour.
@ncmprhnsbl
@beny
According to you the error could not have happened, but it did.
The 00[123]-* modules are all named like they are originally. Still it reports the error during boot and no NetworkManager in XFCE.
___________________________________
@ncmprhnsbl
What about the "dir2xzm returns a non zero value" issue I described? I extra did a test to demonstrate the behaviour.
Cheers!
Yours Rava
Yours Rava
- ncmprhnsbl
- DEV Team
- Posts: 3933
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
2021 Updated Nemesis Base Modules
have you got the config directory(and it's contents) in you drive root?(ie. next to boot and porteus dirs)
besides the zstd stuff there's not much significant difference with slackware porteus' dir2xzm .. (it's in /usr/local/bin, if you want to look at it)
the final line of slackware porteus' dir2xzm:
Code: Select all
if [ $? != 0 ]; then echo "Error building compressed image"; exit 1; fi
Code: Select all
[ $? -ne 0 ] && { gettext "Error building module"; echo; exit 1; }
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44