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
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]#
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:
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
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:
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
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