Some minor bugs in antiX 19.3

  • This topic has 8 replies, 2 voices, and was last updated Apr 7-1:57 am by Robin.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #57161
    Member
    AvatarRobin

    Now after having succeeded in installing proprietary nvidia 304 drivers for go6600 GPU which was dismissed by this fu*%$(!7*ing manufacturer from their recent driver packages, threatening to brick my fully functioning well-tended notebook due to lack of functioning graphics drivers (nouveau driver wouldn’t work), I was able to have a look into the recent antiX version 19.3 (full) for the first time, using a live “persistent all” setup, completely apt-upgraded.

    Some minor bugs raised my attention, maybe the listing can keep antiX 21 from inheriting these potential bugs:

    1.) When running antiX-cli-cc from within terminal window in ROXTerm, the upper window frame stays completely blank after the program has finnished execution, also the minimized tab and the info in the taskbar at bottom line of icewm. Only closing ROXTerm and restarting will bring the missing strings back.

    2.) In live-usb-maker-gui-antix the “Weiter” button (probably “Proceed” in original) is without any function. Can’t believe anybody else has noticed this behaviour, while trying to clone from running LIVE USB system to a fresh USB stick? Checked all possible choices, none of them would obviously allow to start the process. Butten “View log” presents an error message when pressed after a couple of minutes still: “Cant find log file at: /var/log/live-usb-maker.log” No further information present when running from command line instead from menu. All the other radiobuttons, dropdown-menues and buttons work as expected, only the “Proceed” button wouldn’t do anything. Button “Close” closes window, and that was all. No USB was created. Only calling the other script “live-usb-maker” from terminal window did the job flawlessly. I did never see this happen in antiX 17.4.1

    3.) “live-usb-maker” from terminal window wouldn’t copy the persistent home from the running instance to the new stick, presenting a fat “WARNING” instead. This makes it necessary to boot a second instance afterwards from a third stick, mounting the two sticks (original and clone) side by side and copying the missing file from original to the freshly cloned stick.

    4.) live-unmount: on shutdown from menu the “persist-save” (save persistent root) mechanism is performed twice. Once when still GUI is running, making the system wait for about a minute and a half or two, and then again during shutdown sequence not long before unmounting all drives finally, delaying the process again for a minute and a half or two. This was not present in antiX 17.4.1

    5.) Obviously the live USB stick gets never unmounted properly on shutdown: On every single boot system complains about a not properly unmounted stick and performs a filesystem check on the live stick, setting the mount counter to 1 again, keeping the system for at least a full minute or two from proceeding. I’ve checked this using different USB-sticks and fresh installs of antiX 19.3, allways with this same result. This definitively does never happen in antiX 17.4.1, even when using one and the same stick for testing.

    6.) The recent antiX USB unmounter from left side of the bottom bar is a hidden object game rather than a serious tool for everyday work (see screenshots). The borderless windows hide somewhere camouflaged and moreover can pop up in any corner of the screen, mostly invisible, always in a place you never would expect. What kind of April fool is this? Moreover, when you do have more than two USB devices pluged, the third one is not displayed since the window does only have two lines. The handle at right side is without function (doesn’t move at all), so you can’t reach the devices for choosing them to be unmounted when working with a classical 3 button mouse. What the heck? And finally this tool doesn’t function reliable. Sometimes a device is mounted twice to different mountpoints for some reason when plugged in. antiX USB unplug tool tells you happily you are safe to unplug your device, even if is still mounted somewhere. There is no check in the end whether it has completed its job actually, or would have better to perform a lap of honour and unmount the remaining mountpoints of the device silently as long as everything is done. This way it raises danger of data corruption if user trusts in the final message.

    7.) In antix 19.3 claws mail the function to view an image (not thumbnail) is broken:
    In 17.4.1 this works still as expected: when either clicking on the thumbnail image inside a message itself or right click and chose “view image” the image is expected to get opened full size within an external viewer.
    This does not happen in 19.3 anymore, instead claws mail freezes for some seconds, before the context menu vanishes without any further notice. Starting the program in console window with –debug option, following lines show up when trying to access the image:

    	$ claws-mail --debug
    	[...]
    	file-utils.c:58:TIMING safe_fclose : 26s986ms
    	utils.c:2575:execute_command_line(): executing: /usr/bin/display-im6 /home/demo/.claws-mail/mimetmp/025b.jpg
    	
    	** (claws-mail:4103): WARNING **: 01:17:04.025: couldn't execute command: /usr/bin/display-im6

    So I conclude the expected viewer not to be present in antiX 19.3

    	$ ls /usr/bin/display-im6
    	ls: Zugriff auf '/usr/bin/display-im6' nicht möglich: Datei oder Verzeichnis nicht gefunden

    There is no setting available within claws-mail menue to chose another image viewer instead.
    “display-im6” directs to something connected to “imagemagick”, which was present in antiX 17.4.1 still.
    The problem can get fixed by installing imagemagick simply, but this doesn’t help the fact that either
    the dependencies for the program “claws mail” are not met, or the default settings for this program as delivered in antiX 19.3 full (32bit) ISO are wrong in this concern. By the way, do we have “gedit” installed by default? Then user should not find a reference to this program somewhere.

    8.) When pressing the button combination for turning off the splash screen during boot (after antiX boot menue) in order to observe startup process, this choice is not respected for the full duration of sequence. You have to press this button combination again and again at least 3 or 4 times, missing some lines each time, since splash screen reappears again and again after some time.

    9.) The antiX boot menu is presented for about half an hour before all the pretty circles are filled. The time constant for this delay is set way to long. You can’t simply leave the notebook power up itself unattened on a live-persistent system, since it will wait all the time doing nothing but filling happily some circles. Nobody, really nobody could ever need that much time to decide whether he wants to intervene in the boot process by pressing any button in front of this screen (well, I like this screen, but…) This was the same in antiX 17.4.1 already, I was able to fix it by editing some configuration file. I will have to look up the what and where in my notes, but I remember it was quite difficult to locate. You’d better set this to a reasonable value by default. By all means, this happens on a 1.7 GHz CPU.

    10.) Btw, what is that a crude battery value displayed in default 19.3 Conky? Well, I’m used to customise this display to my likes and dislikes anyway, but that default way it doesn’t look to much trustworthy to new antiX users…

    Please check all this behaviour in 64 bit version of 19.3 and alpha preview of antiX bullsey as well, to prevent future releases of antiX from inheriting these bugs.

    kind regards
    Robin

    • This topic was modified 1 week ago by Robin. Reason: added screenshots
    • This topic was modified 1 week ago by Robin.
    • This topic was modified 1 week ago by Robin.
    #57169
    Member
    Avatarskidoo

    1.) When running antiX-cli-cc from within terminal window in ROXTerm
    [..]
    Only closing ROXTerm and restarting will bring the missing strings back.

    missing strings ~= “window titlebar text”

    observations:

    — not specific to roxterm ~~ lxterminal is similarly affected

    — The detail “Only closing will bring back” is incorrect misleading. If multiple roxterm tabs are involved, the titlebar text is “blank” only while the tab from which antiX-cli-cc was launched currently has focus. Switching to another roxterm tab (or subsequently opening additional roxterm tabs) we can note the titlebar text is correctly displayed.

    — not specific to antiX-cli-cc ~~ identical result occurs upon exit from the “cli-aptiX” program.

    — “blank titletext” is not the sole symptom. After antiX-cli-cc has successfully exited (per the green-colored message it emits), drag-selecting any text within the terminal window will resultin a funky mustard-colored background being applied to the selected text.

    — an identical result (green exited message and) “mustard-colored background being applied to selected text” can be noticed after use of the “console-font-select” program and the “console-width-select” program.

    _____________________________

    By inspecting the affected programs, all of which are bash scripts, we can notice:

    — each of them sources (imports) /usr/lib/shell/lib-screen.sh

    — “antiX-cli-cc” does not source any scripts other than /usr/lib/shell/lib-screen.sh

    _____________________________

    Inspecting /usr/lib/shell/lib-screen.sh, we can notice the logfile problem (mentioned in the OP) is a “known issue”

    >>> #FIXME:
    >>> log_file=$ME.log

    …and that the string “exited” occurs only once (within the on_exit() routine.

    The on_exit() here is using printf,
    unlike some of the other antiX scripts, which use the “say()” routine to generate screen output
    or “psay”, vsay, qsay…
    ref:
    grep -inr ‘say[\(]’ /usr/local

    _____________________________

    Now that I have described how to look, and where to look…
    who will step up and “solve” this?
    (send the fix, in a merge request, to the appropriate antiX gitlab project repository)

    Anyone?

    Aynone?

    Bueller ?

    #57170
    Member
    Avatarskidoo

    2.) In live-usb-maker-gui-antix the “Weiter” button (probably “Proceed” in original) is without any function. Can’t believe anybody else has noticed this behaviour, while trying to clone from running LIVE USB system to a fresh USB stick? Checked all possible choices, none of them would obviously allow to start the process. Butten “View log” presents an error message when pressed after a couple of minutes still: “Cant find log file at: /var/log/live-usb-maker.log”

    Letting you know that I could not reproduce this.
    Probably “nobody else has noticed” because the reputed bug is only triggered under a specific set of conditions (choices, codepaths). So that others can reproduce the problem, you will probably need to provide a verbose, step-by-step, “what I clicked, what I typed” walkthrough.

    FWIW, during my quick testing “View Log” was immediately successful (tested immediately after launching the program). A logfile did exist, and its content was displayed within a popup window when I clicked “View Log”.

    >>> Checked all possible choices, none of them would obviously allow to start the process.

    Yeah, the button may remain “disabled” (if, when, while) certain conditions exist… but I can’t guess which specific conditions. When I clicked “Next”, a popup (correctly) reported “Please select a USB device to write to” ~~ and I didn’t proceed further.

    #57171
    Member
    Avatarskidoo

    3.) “live-usb-maker” from terminal window wouldn’t copy the persistent home from the running instance to the new stick, presenting a fat “WARNING” instead.

    I didn’t check what are the default (implicit) options
    and from reading your post, can’t guess whether you are aware of the various optional commandline options nor whether you supplied any during the run in which the undesirable result occurred.

    Options:
              {snip}
    
      --clone-persist       Clone persistence files
      --clone-persist=<p>   or pass a parameter: h,home:  clone home
                                                 r,root:  clone root

    Due to the many (variable) runtime permutations, from a secondhand distance it is difficult to gauge why the requested operation failed (or was refused? or, “Warn” expeceted a followup confirmation?)

    If the target is an existing FAT32 or exfat, we should expect fail//refuse to occur if a clone of “home” persist is requested, right? (Questionmark here because I do not know ~~ have not personally used//recommended//tested “homey” persistence.)

    #57176
    Member
    Avatarskidoo

    antiX boot menu is presented for about half an hour
    [..]
    The time constant for this delay is set way to long.
    [..]
    can’t simply leave the notebook power up itself unattened on a live-persistent system
    [..]
    in antiX 17.4.1 already, I was able to fix it by editing some configuration file.
    [..]
    You’d better set this to a reasonable value by default.

    on antiX 17, I checked:
    /live/boot-dev/boot/syslinux/syslinux.cfg
    ^—> timeout 3000
    (syslinux docs explain that the time unit is deciseconds)
    300 seconds = 5 minutes

    For antiX 19 (at least for the “net” edition), the value has already been reduced, from 3000 to 600
    https://gitlab.com/antiX-Linux/Build-iso/-/blob/master/Template/net/isolinux.cfg

    Just now, I booted a21 alpha in virtualbox and awaited “one circle”.
    my observation: one circle ~= 1 minute

    >>> can’t simply leave the notebook power up itself unattened

    Due to a different bug — or call it an inherent “tight loop” or race-like behavior, within the “gfxboot” component which paints the bootmenu screen — it would be a poor idea to allow a battery-powered machine to “sit idle” with the legacy boot menu displayed. Vrroooooom 100% singlecore CPU usage.

    #57177
    Member
    Avatarskidoo

    8.) When pressing the button combination for turning off the splash screen during boot (after antiX boot menue) in order to observe startup process, this choice is not respected for the full duration of sequence.

    pushing buttons?
    No.
    remove the bootline parameters “quiet” and “splasht”
    and retest
    (if F8 “Save” is present on your bootmenu, you can choose to lock in the changed bootline)

    I too want to see the gritty details, but the lines scroll past too fast to read anyhow. Hey, can at least watch for any REDwarning notices, eh. I wind up reviewing the content of the /var/log/live/* files

    #57179
    Member
    Avatarskidoo

    ClawsMail
    [..]
    This does not happen in 19.3 anymore

    Are any of the previously pre-installed ClawsMail plugins now absent?
    For reference, Here’s antiX 17 Full:

    grep _NAME /etc/initrd-release
    PRETTY_NAME="antiX 17 (Heather Heyer)"
    
    $ grep laws /usr/share/antiX/installed-packages.txt | cut -d ' ' -f 1
    claws-mail
    claws-mail-i18n
    claws-mail-pdf-viewer
    claws-mail-pgpinline
    claws-mail-pgpmime
    claws-mail-tools

    All things considered, I’m surprised the debian gnomeheads didn’t invent an excuse to outright kick (gtk2-based) ClawsMail from the Bulleye suite.

    FWIW, I found no bugs similar to to what you’ve reported:
    https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=claws-mail;dist=unstable

    “gedit”
    [..]
    user should not find a reference to this program somewhere.

    Yes, I agree that some degree of ( /etc/skel/ ) ClawsMail curation is needed, and has been absent, in antiX. If you or someone reading this cares to champion the cause, a merge request containing a custom conf (“desktop-session-full-antix”) could result in this being pushed to antiX 19 repo, benefitting new users even before the bullseye-based release.

    #57182
    Member
    Avatarskidoo

    4.) live-unmount: on shutdown from menu the “persist-save” (save persistent root) mechanism is performed twice. Once when still GUI is running, making the system wait for about a minute and a half or two, and then again during shutdown sequence not long before unmounting all drives finally, delaying the process again for a minute and a half or two. This was not present in antiX 17.4.1

    Let’s wait for others to confirm. I have never witnessed any “performed twice” nor delay at shutdown, not even when I tested persistence in the antiX 21 alpha.

    5.) Obviously the live USB stick gets never unmounted properly on shutdown: On every single boot system complains about a not properly unmounted stick and performs a filesystem check on the live stick, setting the mount counter to 1 again, keeping the system for at least a full minute or two from proceeding. I’ve checked this using different USB-sticks and fresh installs of antiX 19.3, allways with this same result. This definitively does never happen in antiX 17.4.1, even when using one and the same stick for testing.

    Because my usage is strictly “dynamic root persist, semi-automatic savemode”, investigating these might be beyond my purvue.

    #57190
    Member
    AvatarRobin

    Many thanks, skidoo for counterchecking the findings. I’ll give feedback to your comments as soon as possible.

    Let me state for clarification:
    All findings described above on this system are “as delivered” by antiX 19.3 full ISO, updated and upgraded using apt update and upgrade for all upgradable packages, with one exception: xserver-xorg-core, which is pinned to version xorg version 19 from (instead of 20 which was standard in antiX 19.3.) So some findings may not be representative for other users (who are not in need to use prorietary nvidia stuff) at all. Then this is a “live persistent all” system tentatively used until replacing hdd installl of 17.4.1 by 19.3 once it has proven to function as rock stable and doesn’t slow down system, which can always happen when switching to a next generation of an operating system.
    It’s not a problem for me to fix most of the findings individually on this very notebook, but this list was meant to give an impression what a new user faces when using the standard tools antix features for all the tasks.

    2)…

    you will probably need to provide a verbose, step-by-step, “what I clicked, what I typed” walkthrough.

    I’ll do that as soon as possible (need to free an USB stick before, you simply won’t never have enough of them at hand 🙂 and make some additional screenshots.

    3)…
    I didn’t use the command line options at all, since script complained about something missing in the arguments, couldn’d figure out what, even if ‘man’ claims you can mix the two methods. Will have to look deeper into the options of this script some day. For now I just wanted to use it to get a fresh fallback copy of the stick in case the recent kernel upgrade would fail. Could have done this using dd as well. But I decided to follow the path a new antiX user would probably take also.
    from man:
    or you can let a series of menus guide you
    which I did. I’ll provide a step by step description what exactly I did and when and where for this also.

    5)…
    have to append that this happens only on actually “power down”. While on “reboot” the file system on Live USB stick seems to get unmounted properly (at least for some times now, I’ll observe this and report again). So maybe a short delay, added just before actually last power down command in this tool would fix this already? Seems the stick encounters an energy shortfall before it has a chance to get everything settled?

    6)…
    since I’m quite familiar with mounting and unmounting any kind of whatever using simply the standard mount command in terminal, this is not the point. This tool is meant to make this everyday routine task handy and efficient. For this it has to function correctly, then it is a nice shortcut. When working on a pc (other than programming) you usually won’t want to rummaging in the engine room just for plugging off an USB stick. So this tool has its clear right to exist. But it has to safely function under any conceivable circumstances. And you probably wouldn’t expect you’d need to chase for each popup window of a tool in another place on your screen. For sure, I absolutely agree people need to learn to do things manually, but given that somebody does know this already, he can use a tool for everyday usage. Most people prefer to use a pocket calculator instead of dividing four or five digit numbers with a pencil on a sheet of paper, even if they need to know how this works manually, before they start using this handy tool.

    Since “unplugdrive” tool is a bash script I’ve looked into before already, I’ll take care of this myself and present the resulting modifications here on board before trying to upload them to git repo. Maybe they will meet the needs to get merged into antiX in order to fix all this.

    The mentioned double mount happens right after first boot of a fresh Live-USB install from “full” ISO, without having touched any settings. So the default settings in antiX are probably the culprit. I immediately stopped this spook, but I still state: If the tool does claim it was safe to plug off your stick, this has to be true, irrespective how or who has mounted some additional partitions of it elsewhere before. No long palaver here, I can fix this bug easily in the script, making it safe.

    7)…

    Are any of the previously pre-installed ClawsMail plugins now absent?

    Nope.
    For comparison:

    $ grep laws /usr/share/antiX/installed-packages.txt | cut -d ' ' -f 1
    claws-mail
    claws-mail-i18n
    claws-mail-pdf-viewer:i386
    claws-mail-pgpinline:i386
    claws-mail-pgpmime:i386
    claws-mail-tools
    

    Only difference to antiX 17 was the imagemagick tool was removed from the preinstalled programs in the full antiX 19.3 ISO, but clawsmail does obviously expect it to be present.

    8)…

    remove the bootline parameters “quiet” and “splasht”

    well, this was exactly how I fixed this indeed. (I’ve set it to “quiet” and “splash=v”, moreover added “mount=all” before saving all this with f8 option.) Wanted just to make aware of the strange behaviour of this affectionate clingy splash screen new users will face here when expecting simply to see the boot process instead after once having decided this question by pressing the offered key.

    • This reply was modified 1 week ago by Robin.
    • This reply was modified 1 week ago by Robin.
    • This reply was modified 1 week ago by Robin.
Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.