topic title: AntiX 15 b3-V
Posts: 1,028
SamK
Joined: 21 Aug 2011
#196
Re: Clock in Taskbar IceWM
anticapitalista wrote:Maybe it is due to the (old) hardware needing a longer sleep time to start the wm and desktop apps.
I'm doubtful about the age of the hardware being the cause.

The symptoms are
  • not present when the WM is either Fluxbox or JWM
  • present when using IceWM
If the age of the hardware was the deciding factor, one would expect to see evidence of it across all WMs rather than be observed in only one of them.
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#197
TAGGED: low priority, until an updated version of the iso-snapshot package is released
The iso-snapshot package ships (installs) /usr/local/share/excludes/iso-snapshot-exclude.list
problem:
Because the"conffiles" section of the .deb packagefile does not specify it as a configuration file,
the installed copy is not preserved when the package is upgraded or reinstalled.
Ouch ~~ user's customized exclude file winds up deleted (or overwritten).
How many (few) users will actually bother to edit that file... is beside the point.

Even if iso-snapshot-exclude.list becomes recognized as a"conffile", is it reasonable to hope / expect (ASS+U+ME) that the installed copy
will survive, undisturbed, in all apt operations other than"purge"?

Above, I mentioned iso-snapshot-exclude.list as an example.
ALL of the various *-exclude.list files (snapshot, remaster) are similarly"at risk".

A workaround (if not a full"solution") could be achieved by packaging *-exclude.list_ORIG .
At runtime, if a script's expected".list" is file is absent, create it on-the-fly by renaming the"_ORIG" file.
-=-
When an expected *-exclude.list file _is_ present, AND a same-named _ORIG file is present, the script would
recognize that scenario as a"first-run, following package upgrade" situation and proceed accordingly.
Merge (append) _ORIG content into .list, then delete _ORIG ~~ not ideal, but that's the best automated way I've envisioned to handle this.
(result: The scripts already perform sort -u when parsing the lists; redundant entries won't"break" anything...
...and the content of users' existing customized/commented lists are preserved. Manually paring reduntant entries would be a quick, infrequent chore.)
(edit) Okay, I just discovered ~~ {blush} *.orig is already being used, at least for one of the lists
Last edited by skidoo on 18 Jun 2015, 21:48, edited 1 time in total.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#198
SamK wrote:Re SIS Video Driver
...
Booting with parameter xorg=sisimedia
produces a working desktop via the sismedia driver
@SamK, what happens when you use the"noxorg" boot parameter on the Live system (without persistence or a remaster)? Does X start? If so, which driver does"inxi -G" say you are using?
Posts: 1,028
SamK
Joined: 21 Aug 2011
#199
Re SIS Video Driver
BitJam wrote:...what happens when you use the"noxorg" boot parameter on the Live system (without persistence or a remaster)? Does X start? If so, which driver does"inxi -G" say you are using?
Yes X starts.

Report as requested

Code: Select all

cat /proc/cmdline
vga=788 lang=en_GB quiet splash=off disable_srv=LX noxorg

Code: Select all

inxi -c 0 -G
Graphics:  Card: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter
           Display Server: X.Org 1.16.4 drivers: fbdev (unloaded: vesa)
           Resolution: 800x600@75.00hz
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)
           GLX Version: 3.0 Mesa 10.3.2


Off Topic
Remastering consistently fails with the message Could not bind mount / /liveaufs to /live/ro-root
Posts: 1,028
SamK
Joined: 21 Aug 2011
#200
Re: Clock in Taskbar IceWM

Summary of progess towards resoloution
  • Because the matter is present in IceWM but not present in Fluxbox or JWM, it eliminates the age of the hardware as the source of the problem
  • Placing a 20 second sleep command at the head of /etc/desktop-session/startup; the symptoms still present before the subsequent default commands in the file are executed. This eliminates any extra"heavyweight" Jessie element creating a delay being the source of the problem
  • Because the freeze occurs during the above 20 second sleep period, it is a good indication the source of the problem lies before /etc/desktop-session/startup is run. It is somewhere in the boot chain scripts including the session chain scripts
  • Because the fault condition is corrected by restarting IceWM it is a good indication the source of the issue in boot/session scripts is correctable
It is probable the cause the problem is also responsible for the reported freezing of the CPU and Network monitors in the IceWM taskbar. This is also corrected by restarting IceWM.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#201
SamK wrote:Yes X starts [...] Display Server: X.Org 1.16.4 drivers: fbdev (unloaded: vesa) [...]
Thanks SamK! This means I can make a workaround and have live-init make an xorg.conf that loads the sisimedia driver when graphics using the sis and and/or the sis-agp kernel drivers are found. The initrd.log file you posted helped me figure this out. If you are running a LiveUSB, I'd like to send you an initrd.gz to test this (when it's done).
Remastering consistently fails with the message Could not bind mount / /liveaufs to /live/ro-root
Thanks! Beta3 shipped with a broken version of live-remaster. It will be fixed.
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#202
(yeah, nitpicking. I'll understand if this report is ignored.)

some .gitignore files got copied into the iso.
/usr/src/linux-headers-4.0.0-antix.1-486-smp/...
/usr/share/themes/Mediterranean...

These can be targeted in delete-files.list during build process. Python will auto-regenerate these at runtime, as needed.
/usr/share/system-config-printer/*.pyc
/usr/share/system-config-printer/troubleshoot/*.pyc
/usr/share/streamtuner2/channels/*.pyc
/usr/lib/python3.4/email/__pycache__/*.pyc
/usr/share/hplip/ui4/*.pyc
/usr/share/hplip/fax/*.pyc
/usr/share/hplip/base/*.pyc
/usr/share/bleachbit/bleachbit/*.pyc
This isn't a comprehensive list of *.pyc paths, just a selective hitlist (comprising @2.5Mb of binary files which can be omitted safely).
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#203
tested from a non-persistent session
root@antiX1:/home/demo# locate .debi
/usr/share/calendar/calendar.debian
/usr/share/doc/libcompfaceg1/README.debian
/var/lib/apt/lists/ftp.gr.debian.org_debian_dists_jessie_InRelease
/var/lib/apt/lists/ftp.gr.debian.org_debian_dists_jessie_contrib_binary-i386_Packages
/var/lib/apt/lists/ftp.gr.debian.org_debian_dists_jessie_contrib_i18n_Translation-en
/var/lib/apt/lists/ftp.gr.debian.org_debian_dists_jessie_main_binary-i386_Packages
/var/lib/apt/lists/ftp.gr.debian.org_debian_dists_jessie_main_i18n_Translation-en
/var/lib/apt/lists/ftp.gr.debian.org_debian_dists_jessie_non-free_binary-i386_Packages
/var/lib/apt/lists/ftp.gr.debian.org_debian_dists_jessie_non-free_i18n_Translation-en
/var/lib/apt/lists/security.debian.org_dists_jessie_updates_InRelease
/var/lib/apt/lists/security.debian.org_dists_jessie_updates_contrib_binary-i386_Packages
/var/lib/apt/lists/security.debian.org_dists_jessie_updates_contrib_i18n_Translation-en
/var/lib/apt/lists/security.debian.org_dists_jessie_updates_main_binary-i386_Packages
/var/lib/apt/lists/security.debian.org_dists_jessie_updates_main_i18n_Translation-en
/var/lib/apt/lists/security.debian.org_dists_jessie_updates_non-free_binary-i386_Packages
/var/lib/apt/lists/security.debian.org_dists_jessie_updates_non-free_i18n_Translation-en
^---------- Note: during default non-persistent session, most of these files do not actually exist.

In order for the iso to ship an accurate mlocate database, updatedb needs to be called LATE in the build process.
Posts: 1,139
masinick
Joined: 26 Apr 2008
#204
Running an"older" kernel n this particular instance: Note that this one was built from"Beta 1", but it's updated with the current Debian Testing packages on an antiX 15 infrastructure. This works fine.

Code: Select all

$ inxi -Fxz
System:    Host: antix Kernel: 3.19.1-antix.1-486-smp i686 (32 bit gcc: 4.9.2)
           Desktop: IceWM 1.3.8+githubmod+20150412+960629d
           Distro: antiX-15-beta1-V_386-full Killah P 16 March 2015
Machine:   System: LENOVO product: LENOVO3000 Y410
           Mobo: LENOVO model: IGT30 v: REFERENCE
           Bios: LENOVO v: 05CN57WW(V3.02) date: 01/30/2008
CPU:       Dual core Intel Core2 Duo T5450 (-MCP-) cache: 2048 KB
           flags: (lm nx pae sse sse2 sse3 ssse3) bmips: 6650
           clock speeds: max: 1667 MHz 1: 1333 MHz 2: 1333 MHz
Graphics:  Card: Intel Mobile GM965/GL960 Integrated Graphics Controller (primary)
           bus-ID: 00:02.0
           Display Server: X.Org 1.17.1 drivers: intel (unloaded: fbdev,vesa)
           Resolution: 1280x800@60.00hz
           GLX Renderer: Mesa DRI Intel 965GM x86/MMX/SSE2
           GLX Version: 2.1 Mesa 10.5.5 Direct Rendering: Yes
Audio:     Card Intel 82801H (ICH8 Family) HD Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: ALSA v: k3.19.1-antix.1-486-smp
Network:   Card-1: Intel PRO/Wireless 3945ABG [Golan] Network Connection
           driver: iwl3945 v: in-tree:s bus-ID: 04:00.0
           IF: wlan0 state: up mac: <filter>
           Card-2: Broadcom NetLink BCM5906M Fast Ethernet PCI Express
           driver: tg3 v: 3.137 bus-ID: 06:00.0
           IF: eth0 state: down mac: <filter>
Drives:    HDD Total Size: 160.0GB (5.3% used)
           ID-1: /dev/sda model: FUJITSU_MHY2160B size: 160.0GB
Partition: ID-1: / size: 9.3G used: 6.0G (69%) fs: ext4 dev: /dev/sda10
           ID-2: swap-1 size: 2.15GB used: 0.00GB (0%) fs: swap dev: /dev/sda7
Sensors:   System Temperatures: cpu: 55.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 111 Uptime: 45 min Memory: 482.5/2011.3MB
           Init: SysVinit runlevel: 5 Gcc sys: 4.9.2
           Client: Shell (bash 4.3.331) inxi: 2.2.19 
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#205
skidoo wrote:In order for the iso to ship an accurate mlocate database, updatedb needs to be called LATE in the build process.
I agree. Thanks!
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#206
bash (login shell?) stuck at 100% CPU usage
I've encountered this intermittently across weeks/boots using this 15b3 build, but had refrained from reporting it b/c I can't reproduce it on demand.
Today when it happened, I found"bash" was the 96--100% sustained CPU-hogging process; its pid is immediately after"policykitd", and before"slim".
FWIW, autologin is set (same, unchanged across boots) and at boot I didn't touch/change any boot settings, compared to other previous sessions.
-=-
Attempting to"recover", by exiting the desktop session and reentering via slim login, didn't help.
I found nothing remarkable in the logfiles and (same as in previous encounters) resorted to performing shudtown/reboot .
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#207
skidoo wrote:Today when it happened, I found"bash" was the 96--100% sustained CPU-hogging process; its pid is immediately after"policykitd", and before"slim".
If you know the pid then the output of"ps -axjf" might help track down what is happening. I suggest redirecting the output of the command to a file. Make sure to record the pid as well.
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#208
I'm reporting the following as"an observation"; someone else can decide whether it represents a"bug".

liveUSB boot screen
During a prior session, F8 was used (persist=root, timezone=whatever, desktop=fluxbox) and a custom bootline currently exists.

On a session-by-session basis, I can (via F5) opt persistence=none
(specifically: when booscreeen loads, press F5, press up-arrow twice, press enter to select, press enter to proceed with the boot)

What I cannot do, on a per-session basis, is opt for a different initial desktop... unless i ALSO set (via F5) persistence=none.
Said differently, while persist=root is displayed @F5, desktop=whatever seems to be ignored.
IIRC, I've unsuccessfully tried all these combinations:
-- select different desktop via Fkey
-- select different desktop by adding"desktop=rox-icewm" to the input displayed for custom boot line
-- do both of the above, together
-- highlight/select the first bootline entry (vs custom) along with each of, then both of, the above
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#209
skidoo wrote:What I cannot do, on a per-session basis, is opt for a different initial desktop... unless i ALSO set (via F5) persistence=none.
This is interesting. In this situation there are 3 things that compete to set the initial desktop: root persistence, the live-usb-save script which saves the desktop on LiveUSBs even without persistence, and finally, the desktop= boot parameter. The boot parameter should take precedence.

I can't replicate the problem here. While it is booting it should tell you"Setting desktop to XXXX" where XXXX is the selection from the F6-Desktop menu. You should also be able to see this in /var/log/live/live-init.log. If you want to see it while booting then use"bp=9" to set a breakpoint when the initrd is almost done. This is after the live-init script runs.

Here, when I select a desktop from the F6-Desktop menu, it tells me during the boot it is"Setting desktop to XXXX" correctly. That line shows up in the log file; the contents of /home/demo/.desktop-session/default-desktop is set correctly and it starts the desktop I selected. This is all with root persistence enabled.

Have you added other user accounts to the system? Have you edited /etc/slim.conf? Have you installed lightdm? Do you get the"Setting desktop to XXXX" message (either in the screen or in the log file)? Does the file /home/demo/.desktop-session/default-desktop reflect the choice you made in the F6-Desktop menu?

Finally, what is the output of"cat /proc/cmdline"? Does desktop=xxxx show up more than once?

We are now using the following code to try to figure out who the"default" user is.

Code: Select all

find_def_user() {
    local user=$(sed -r -n 's/^\s*default_user\s+//p' / etc/slim.conf 2>/dev/null)
    : ${user:=$(sed -r -n 's/^\s*autologin-user=//p' / etc/lightdm/lightdm.conf 2>/dev/null)}
    : ${user:=$(getent passwd 1000 | cut -d: -f1)}
    : ${user:=demo}
    echo ${user%% *}
}
We first look for the"default_user" in slim.conf. Then we look for the"autologin-user" in lightdm. conf. Then we look for the user with UID 1000, and if all else fails, we use the user named"demo". If all of this fails then we issue a warning"No default user <name> found on the system". This should also show up on the screen and in the live-init.log file.
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#210
Have you added other user accounts to the system? Have you edited /etc/slim.conf? Have you installed lightdm?
"No" in response to each of these. As for the rest, I'll need to retest and check from within an affected session.
I was reluctant to mention this so late in testing. The fact that neither I nor anyone else had noticed it earlier throughout testing suggests it's an"edge case".
OTOH, prior to posting I thought"I'm now testing initrd-3 along with yesterday's dist-upgrade antix packages, so possibly a regression has been introduced..."

I worded the post"observation or bug" because something has apparently changed ~~ something which necessitates adjusting my testing regimen/habits.
Thinking aloud:
All along, throughout testing previous builds, selecting the first boot entry produced a"bone stock" (factory fresh) nonpersistent liveUSB session, yes?
Maybe a previously-stored timezone was detected/applied during nonpersistent boots (i can't recall),
but every time I chose the first bootmenu entry, the bone-stock default (icewm) window manager was autoselected, yes?

In usage, it's no big deal if I need to explicitly select (usually fluxbox) the desktop during each"first bootmenu line" boot.
Alternatively, if the previously-stored preferred desktop is ignored during each"factory fresh bootmenu item" boot, that's understandable.

In testing though, with a goal of trying to"be on the same page", I do need to repeatedly visit the"factory fresh" scenario...

-------------------- saved a draft, rebooted --------------------------

Broader than what I described in the earlier post (desktop choice being ignored) I now realize, and am reporting:

"factory fresh" boot isn't attainable (by selecting the first bootmenu item) while previously-saved F8 prefs exist.
When I highlight/select the first bootmenu item and press enter... I wind up with"root perisistence".

If we are now expected to, required to,"perform an F8 reset" prior to attempting to use the #1 bootmenu entry, although I could adjust to that
(first perform a"reset" boot run, shutdown, boot again and choose #1 bootmenu entry)
ain't likely I would be able to convince a new user (or dodomodo reviewer) that"it's a feature, not a bug".