Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: SamK on February 08, 2010, 03:15:22 PM
-
After installing Openbox/LXDE on TC, wbar is displayed each time startx has run. A right-click on wbar removes it without any problem. Is there a fix posted anywhere for this?
-
The bootcode "noicons"
-
Simple when you know how. Thanks
-
When using Openbox and LXDE, is there a command that can be added to /opt/bootlocal.sh which performs the same function as the bootcode "noicons"?
-
If using the "noicons" bootcode is not desired, you can edit ~/.xsession and either comment out or remove the line
[ "$ICONS" == "wbar" ] && /usr/bin/wbar.sh
-
If using the "noicons" bootcode is not desired, you can edit ~/.xsession and either comment out or remove the line [ "$ICONS" == "wbar" ] && /usr/bin/wbar.sh
Thanks for the useful pointer.
If I understand correctly, the use of the bootcode "noicons" prevents the creation of a variable "ICONS" which is then used in ~/.xsession. Is it possible to boot without using the bootcode "noicons" and unset the variable "ICONS" with a command issued from /opt/bootlocal.sh?
I am not against commenting out the appropriate line in ~/.xsession but I try to keep the number of manually edited files to a minimum. I have created other entries in /opt/bootlocal.sh and would also like to use it for this purpose if possible.
If this is a workable idea, how would the command be constructed to unset "ICONS"?
-
You can also kill WBAR process in the script, either in bootlocal.sh or ad to LXDE startup. However it is better not to start WBAR than start and kill. But works.
-
You can also kill WBAR process in the script, either in bootlocal.sh or ad to LXDE startup. However it is better not to start WBAR than start and kill. But works.
I am uncertain how to do this. In a root console "kill wbar" generates 'bad pid wbar'.
I would still also like to learn how to unset $ICONS.
Edit:
I have tried adding
unset ICONSto bootlocal.sh without success.
-
Is it possible to boot without using the bootcode "noicons" and unset the variable "ICONS" with a command issued from /opt/bootlocal.sh?
No, because bootlocal.sh is a child script. Any changes to environment variables within it do not affect the init process.
If you do not want wbar to start, there is a hack (I verified it works on 2.8.1):
1) Open a root terminal.
2) rm -f /usr/share/wbar/dot.wbar
3) ln -s foo /usr/share/wbar/dot.wbar
4) Add usr/share/wbar/dot.wbar to /opt/.filetool.lst and make a backup
The key to this is that dot.wbar is now a symbolic link to a file which does not exist. This link in the backup will be restored on bootup before the following code is executed:
if [ -n "$NOICONS" ] || [ ! -f /usr/share/wbar/dot.wbar ]; then
unset ICONS
fi
This will unset ICONS in the appropriate place and prevent wbar from starting.
Alternatively, you can create a "no-wbar" extension to remove the dot.wbar file:
1) Load squashfs-tools extension using Appbrowser.
2) Open a root terminal.
3) mkdir -p /tmp/no-wbar/usr/local/tce.installed/
4) echo rm -f /usr/share/wbar/dot.wbar > /tmp/no-wbar/usr/local/tce.installed/no-wbar
5) chmod +x /tmp/no-wbar/usr/local/tce.installed/no-wbar
5) mksquashfs /tmp/no-wbar /tmp/no-wbar.tcz -b 4096
Then, for TC 2.7 and earlier:
6) Copy no-wbar.tcz to your tce directory
Or for 2.8 and later:
6) Copy no-wbar.tcz to your tce/optional directory
7) Add "no-wbar.tcz" to tce/onboot.lst
There may be users like you which for one reason or another cannot use the noicons boot parameter, so I will submit this extension to Jason for consideration. It's a bit of a hack, though, so no guarantees on acceptance. :)
However it is better not to start WBAR than start and kill.
True, but if you wish to try this, here is what you can add to bootlocal.sh:
while ! pidof wbar &>/dev/null; do sleep 1; done; killall wbar
-
I have to wonder why there are so many ways to get rid of wbar, when the simplest ones are the bootcode, or using MC where wbar is not included at all.
-
I have to wonder why there are so many ways to get rid of wbar, when the simplest ones are the bootcode, or using MC where wbar is not included at all.
Maybe the cleanest way is to build on MC. You are right.
-
That is the beauty of Tinycore. There are so many ways (each with pros and cons) to do even a simple thing:
1) Use "noicons" boot parameter.
2) Build on microcore base instead of tinycore.
3) Create backup file to remove dot.wbar
4) Create extension to remove dot.wbar
5) Kill wbar in bootlocal.sh
6) Remove wbar startup in ~/.xsession
:)
-
Is it possible to boot without using the bootcode "noicons" and unset the variable "ICONS" with a command issued from /opt/bootlocal.sh?
No, because bootlocal.sh is a child script. Any changes to environment variables within it do not affect the init process.
This has helped greatly; it is easy to understand .
In my view the rest of your reply is a model answer. To provide a range of possible actions in a clear and concise manner is an example for us all. Many thanks.
Although probably the least elegant solution I will probably adopt the killing of wbar from bootlocal.sh as it represents the closest answer to my requirements. I have tested it and it fulfills what I requested. Hopefully your extension will be accepted and I will adopt it at that time.
-
I have to wonder why there are so many ways to get rid of wbar, when the simplest ones are the bootcode, or using MC where wbar is not included at all.
I am reasonably new to TC and still exploring it. I have not yet looked at MC. Is there a guide to building an Openbox/LXDE environment using MC?
-
I have to wonder why there are so many ways to get rid of wbar, when the simplest ones are the bootcode, or using MC where wbar is not included at all.
I am reasonably new to TC and still exploring it. I have not yet looked at MC. Is there a guide to building an Openbox/LXDE environment using MC?
http://wiki.tinycorelinux.com/tiki-index.php (http://wiki.tinycorelinux.com/tiki-index.php)
-
The wiki is slightly out of date; however, the only difference to a 2.8.1 TC is that you have the X parts (Xlibs.core.gz, Xprogs.core.gz, Xvesa.core.gz) in your tce directory (not optional like normal extensions). You'll also need to have a WM extension in your optional directory, as flwm is not included in the core extensions.
The end result is the same as with a TC boot, but without wbar.
-
A couple of questions...
...you have the X parts (Xlibs.core.gz, Xprogs.core.gz, Xvesa.core.gz) in your tce directory (not optional like normal extensions).
When updates are issued for these X parts will they be updated and applied in the same way as extensions in the optional directory are updated?
The end result is the same as with a TC boot, but without wbar.
Apart from no wbar what are the principal advantages of building a GUI environment on MC?
-
They are not extension, they are additional initramfs images just as microcore.gz and tinycore.gz.
Therefore you would download them just as you would microcore.gz.
The advantage is you get to choose your window manager or full desktop environment as well as any icon choice.
By the far the easiest solution is to use the boot code of noicons!
-
The end result is the same as with a TC boot, but without wbar.
Apart from no wbar what are the principal advantages of building a GUI environment on MC?
It's the choice. You don't have unwanted things running, not even taking any space. If you wanted to use Xfbdev or Xorg instead of Xvesa, no Xvesa taking space then.
-
By the far the easiest solution is to use the boot code of noicons!
If the resulting 'bundle' of TC+extensions were to be used primarily by me, using "noicons" may well be the solution adopted. However, the primary user has limited computer skills and is a long-time user of MS-Windows.
One of the design objectives is to produce a bundle which eases the transition from MS to TC. Openbox+LXDE was selected as it presents a Windows-like GUI. Wine is also used to allow the use of Windows portable applications and provide familiarity during the transitional phase.
Providing menu entries for the portable applications is achieved via an entry in bootlocal.sh to a script in /home/tc. This mechanism also provides menu entries for TC extensions and scripts which do not provide their own menu entries.
The use of bootcodes is unfamiliar to the intended user and therefore deemed to be undesirable. A UK keyboard layout is required and is setup from bootlocal.sh. Initial cleaning of the cache is also conducted from bootlocal.sh. From a maintenance point of view, in the absence of an official means (other than "noicons") it is desirable to control the display of wbar from bootlocal.sh also.
-
Is it possible to boot without using the bootcode "noicons" and unset the variable "ICONS" with a command issued from /opt/bootlocal.sh?
No, because bootlocal.sh is a child script. Any changes to environment variables within it do not affect the init process.
If I recall correctly back in the days of MS-DOS 5 & 6 there were utilities that allowed changes to be made in the master environment from a local environment. Do similar utilities exist that can be used in TC?
-
Boot options does not necessarily imply manually entering them.
Typically they are added to the stanza of the boot loader.
By your suggesting to use bootlocal does imply that a backup be pre-made or a remaster, either way, implies pre-setup boot media. Therefore on such media the boot loader could be deployed.
-
If you don't want to edit .xsession, unset ICONS in .profile.
-
If you don't want to edit .xsession, unset ICONS in .profile.
Unfortunately, that doesn't work. For Sam's benefit, the startup sequence is init --> /root/.profile --> /home/tc/.profile --> /usr/bin/startx --> /home/tc/.xsession. If you examine /usr/bin/startx, you will see:
export ICONS=`cat /etc/sysconfig/icons`
If you are going to add anything to /home/tc/.profile, I'd suggest:
rm -f /etc/sysconfig/icons
or
sed '/wbar/d' -i /home/tc/.xsession
-
If you are going to add anything to /home/tc/.profile, I'd suggest:
rm -f /etc/sysconfig/icons
In that case this could also be added to /opt/bootlocal.sh
Aren't Linux's endless possibilities wonderful?
The "right way" and hundreds of other ways.
-
In that case this could also be added to /opt/bootlocal.sh
I considered that, but I didn't mention it because bootlocal.sh is executed asynchronously. There is no way to guarantee it will execute before .xsession, although it is very likely due to the delays involved in starting X.
-
That suggests a useful boot option.
'sync' that would not detach bootlocal.sh.
Though on second thought that might cause percieved unexplained hangs during boot.
-
That suggests a useful boot option. 'sync' that would not detach bootlocal.sh.
That would undesirable because proper behavior of the script would be dependent on the boot option. Were the boot option not present, the behavior of the system would be undefined.
-
Certainly it would be defined.
If sync was not set, bootlocal.sh would be run with the '&'
If set, the '&' would be omitted, and race conditions would be avoided.