Porteus 5.0 RC2 bug reports

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#301 by nanZor » 16 Mar 2021, 22:06

5.0 RC2 / LXDE Savefile Manager:

Is it just me, or is the ability to choose a location in the SaveFile Manager for the changes.dat (whatever name and size you want) disabled?

These days I run with changes saved to other filesystems like extX, but noticed that the savefile manager won't allow for choosing the location of a *dat file if you decide to use say a fat32 filesystem for changes.

I noticed that you can specify a name and size, but when it comes to location, that ability to either type it in yourself, or use the gui option is non-functional.

I'm thinking its an RC thing, but just wanted to check.
Last edited by nanZor on 18 Mar 2021, 10:43, edited 1 time in total.
That's a UNIX book - cool. -Garth

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2953
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

Porteus 5.0 RC2 bug reports

Post#302 by ncmprhnsbl » 16 Mar 2021, 23:18

nanZor wrote:
16 Mar 2021, 22:06
I noticed that you can specify a name and size, but when it comes to location, that ability to either type it in yourself, or use the gui option is non-functional.
yeah, i think this was still non-functional at the time of rc2 release ... have you tried this?
ncmprhnsbl wrote:
09 Aug 2020, 13:33
HERES some updated porteus settings guis: 09-pscripts-RC2-20201116.xzm
i think i got it working there..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#303 by nanZor » 17 Mar 2021, 01:56

Thanks! I'll check it out.
Honestly, it was kind of a good thing as it forced me to use the far simpler changes bootcode to a non-ms filesystem for changes.

I had been using the Savefile Manager as a crutch since it was so convenient to put changes into an available fat32, even when I had far better filesystems around for saving changes!

I took the hint so to speak and am a happy camper saving to ext's, reiserfs etc...
That's a UNIX book - cool. -Garth

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#304 by nanZor » 17 Mar 2021, 02:25

@ncmprhnsbl:

Very nice! That seemed to have fixed the problem, albeit the option doesn't seem to get written to the porteus.cfg file at the very end, and the util doesn't bring up an editor to check it, like leafpad or whatever.

I also checked the porteus-5.0-x86_64cfg file too just in case it was placed there, but no.
(My thought here is if the changes location does not work in this 64-bit specific config file, remove that option example from this file. Confused me back in the past. :)

So as of now, the savefile can be created, one just has to edit their config manually to make it look there.

But COOL! Thanks for tweaking on the savefile manager script!
That's a UNIX book - cool. -Garth

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#305 by nanZor » 18 Mar 2021, 10:43

Porteus Settings Centre - graphic anomoly

From 5.0 RC2 LXDE

When one activates a child window of options from the parent window of the Settings Center, moving those child windows around (centering, enlarging to read better etc) leaves a trail of stair-step outline drags within the parent window of the Settings Center.

These stair-step outline-drag trails are not seen *outside* the geometry of the Settings Center parent window.

Not a big deal, just cosmetic - but thought I'd report what I'm seeing. It could be machine / graphic card specific to my Intel graphics, so I'll try again with my AMD boxes when I get to them. Unless someone else can duplicate what I'm seeing.

Again, small-beans. :)
That's a UNIX book - cool. -Garth

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2953
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

Porteus 5.0 RC2 bug reports

Post#306 by ncmprhnsbl » 19 Mar 2021, 02:06

nanZor wrote:
17 Mar 2021, 02:25
Very nice! That seemed to have fixed the problem, albeit the option doesn't seem to get written to the porteus.cfg file at the very end, and the util doesn't bring up an editor to check it, like leafpad or whatever.

I also checked the porteus-5.0-x86_64cfg file too just in case it was placed there, but no.
(My thought here is if the changes location does not work in this 64-bit specific config file, remove that option example from this file. Confused me back in the past. :)

So as of now, the savefile can be created, one just has to edit their config manually to make it look there.
yep, still needs some work .. added in the missing 'open porteus.cfg in editor' part and tweaked the message..
looking at the original bash/gtkdialog script, seems not quite right there either.. and i think the changes= cheatcode needs to be in the /boot/syslinux/porteus.cfg and not the porteus-5.0-x86_64.cfg ...
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#307 by nanZor » 19 Mar 2021, 08:15

No problem - thanks for looking into it.

I haven't tested it, but I think I went through this a few years ago. I mean I understand the need for the X86_64.cfg file serving as convenient ways to incorporate cheatcodes - one per line which overrides what you have in the porteus.cfg file.

That makes it convenient and less likely for a user to botch the edit of the formal boot-stanzas of graphical, always fresh etc.

But last time I looked at it, I *think* that some things added to the x86_64.cfg file weren't recognized, whereas others were. I think putting changes= into the x86_64.cfg wasn't recognized, which mandated manually editing the APPEND line of your desired boot stanza in porteus.cfg.

I'll have to test that when I'm near the gear tomorrow and see. No biggie, its what RC's are for...
That's a UNIX book - cool. -Garth

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#308 by nanZor » 24 Mar 2021, 00:47

COPY2RAM UNKNOWN OPERAND

I'm getting a warning during the boot stanza after copy2ram about my use of an mmc block device when using the copy2ram option:

Code: Select all

copy2ram
sh: mmc unknown operand
and it continues on like normal and boot seemingly properly.

I use an internal emmc device in some of my little boxes for storing my changes with no problems. Porteus even tests it for posix compatability with no problem. I am able to save and recall data from it with no messages during normal boots in the Graphics mode.

However, when using the Copy2ram option, that message shows up during the boot stanza. My changes *are* detected and used, so it appears to possibly be a benign message?

This is what my changes line looks like when using the copy 2 ram option, either typed in manually at bootsplash, or when I edit my porteus.cfg file:

Code: Select all

copy2ram changes=/mnt/mmcblk0p2
So everything seems to be working, and maybe the message about mmc being an "unknown operand" when using the copy 2 ram boot option is cosmetic?

UPDATE:
Ah, looks like according to Stackoverflow, busybox ash treats [[ ]] simplistically, and one recommends using single [ ] and quoting the command substitution.

https://stackoverflow.com/questions/342 ... d-in-yocto

Huh, maybe a more recent busybox fixes that....
That's a UNIX book - cool. -Garth

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#309 by nanZor » 24 Mar 2021, 23:06

nanZor wrote:
16 Mar 2021, 09:15
E2FSCK out of date warning:

Running 5.0rc2 with LXDE. I use the internal mmcblk device formatted with ext to store my changes. Works great, however the system did come up with a hint to use the FSCK bootcode next time to make sure all the filesystems are consistent. But I got this warning:

Code: Select all

MMCBLK0P2 has unsupported feature:   METADATA_CSUM
Get a new version of e2fsck !
Update: WEIRD - I can run fsck after the boot on mmc devices, but get no warning about needing a newer version of e2fsck!

Maybe it's how I'm calling it after unmounting - a very simple

Code: Select all

sudo fsck -f -y -v /dev/mmcblk0p2
produces no warning about "metadata_csum"

Still, a flag has been set, and Porteus recommends I run fsck via a cheatcode, which still produces this warning about metadata_csum early in the boot process.

Interesting - will do some searching...
That's a UNIX book - cool. -Garth

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2953
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

Porteus 5.0 RC2 bug reports

Post#310 by ncmprhnsbl » 24 Mar 2021, 23:56

nanZor wrote:
24 Mar 2021, 23:06
Update: WEIRD - I can run fsck after the boot on mmc devices, but get no warning about needing a newer version of e2fsck!
yeah, when run at boot time, e2fsck in initrd is used (/mnt/live/usr/bin/e2fsck) , after boot, it's /sbin/e2fsck or fsck ...
there was an update of the bins in initrd (all 32bit for cross compatibility(and uclibc toolchain)), but i'm not sure, 1. if those updated bin made it into the initrd used in rc2 or 2. that e2fsck initrd needs updating again..
can you do md5sum /mnt/live/usr/bin/e2fsck, for me? i get 872af26012a49ac145030c0d6de2e35d ..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#311 by nanZor » 25 Mar 2021, 07:17

Uh oh, there isn't anything past /mnt/live/usr ! Completely empty, no bin, nothing. Kind of freaks me out..

I also took a look inside /mnt/live/bin and saw a lot of busybox links, but no e2fsck or fsck among them just in case....

So I looked to do md5sum on what was found on the sytem searching for e2fsck globally:

Code: Select all

guest@porteus:~$ md5sum /mnt/live/memory/images/001-core.xzm/sbin/e2fsck
4218c4f8c3c8d1e80518d2f1c31a5e13  /mnt/live/memory/images/001-core.xzm/sbin/e2fsck
And..

Code: Select all

guest@porteus:~$ md5sum /sbin/e2fsck
4218c4f8c3c8d1e80518d2f1c31a5e13  /sbin/e2fsck
If it makes any difference, this stick was just copying over the files from a mounted iso onto a fat32 stick and booting that way for uefi only.
That's a UNIX book - cool. -Garth

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2953
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

Porteus 5.0 RC2 bug reports

Post#312 by ncmprhnsbl » 25 Mar 2021, 13:20

nanZor wrote:
25 Mar 2021, 07:17
Uh oh, there isn't anything past /mnt/live/usr ! Completely empty, no bin, nothing. Kind of freaks me out..
uh yeah, sorry about that, i forgot that those bits don't make to the live system past the initial initfs part
do me a:

Code: Select all

cat /etc/porteus/*
to remind what initrd.xz went into RC2 .. thanks
20200108 i guess..?
EDIT.. assuming that's the case, looks like the newer versions didn't make it into that initrd.xz
20200108 : a35e0a295b89c2ff0a66fe812653de07
mine(updated): 872af26012a49ac145030c0d6de2e35d
i'll do some tests and upload a replacement
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2953
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

Porteus 5.0 RC2 bug reports

Post#313 by ncmprhnsbl » 26 Mar 2021, 03:37

this initrd.xz: Click-me-i'm-a-link 1.2 mb md5sum: c7c643c53746e64d2f8e08db5aee9f00
has updated binaries and libs. (replace the one in <device>/boot/syslinux with it)
and fsck cheatcode appears to work..
@nanZor, please check if it works with your mmc device
also, have updated the 09-pscripts-RC2-20210326.xzm module linked in the first post, the create save.dat should work properly now..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

nanZor
Shogun
Shogun
Posts: 226
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC2 LXDE
Location: Los Angeles

Porteus 5.0 RC2 bug reports

Post#314 by nanZor » 26 Mar 2021, 08:53

New initrd.xz works! It has no problem any more with my mmc device I use for the changes storage. It reports all as clean and boots fine! My md5sum for it matches yours.

However, I am still prompted to use the fsck cheatcode upon shutdown or reboot for the next time ... I tested with and without my usual EXIT: cheatcode, but am still prompted to fsck anyway. Some flag getting stuck I suppose.

Save.dat - also works just fine with the new 09-pscripts-RC2-20210326.xzm.

Thanks for both fixes! RC2 just keeps on getting better..
That's a UNIX book - cool. -Garth

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2953
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

Porteus 5.0 RC2 bug reports

Post#315 by ncmprhnsbl » 27 Apr 2021, 05:33

added fixed rpm2xzm to 09-pscripts-RC2-20210427.xzm, linked in the first post of this topic
..minor fix to correct missing path to message dialog -- thanks roadie
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

Post Reply