Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: Rich on June 07, 2020, 07:28:41 AM
-
The attached script is intended to gather some baseline information about a Tinycore Linux installation. The design goals of the script
were as follows:
1. No dependencies. Use only commands that are part of the base system.
2. Keep the results file generated small so that it can be an attachment in a users post.
3. Format the results file to make it easier to review.
4. Try to stay focused on generic and Tinycore specific data.
5. Optimize for speed where possible.
On my old 800 Mhz, 512 Meg RAM, PATA drives, TC4 system it takes about 50 seconds to complete.
On my Dell E310 2.4Ghz, 3 Gig RAM, SATA drives, TC10 system it takes about 11 seconds to complete.
About 80% of the time is spent on MD5 checks.
The results are saved in a file called TCscanYYMMDDHHMMSS.txt where YYMMDDHHMMSS is a date code.
The format of the file is as follows:
It starts with a time stamp and a Table of Contents listing which sections were created and what they contain
Sun Jun 7 09:58:50 UTC 2020
Table of Contents
Sect 1 TC version, uname, tcedir, mydata.tgz status, /etc/sysconfig/
Sect 2 tcemirror, repo URL, repo URL reachable, showbootcodes, Some CPU flags
Sect 3 free, /proc/swaps, mounts, disk free
Sect 4 ifconfig, route -n, /etc/resolv.conf
Sect 5 lsmod
Sect 6 .xsession, .profile
Sect 7 bootsync.sh, bootlocal.sh, .filetool.lst, .xfiletool.lst
Sect 8 onboot.lst, ondemand
Sect 9 Missing md5 files, Failed md5 checks, Local/Repo md5 files differ
Sect 10 Orphaned md5 and dep files
Sect 11 find bootloader config file
Sect 12 Some dmesg lines
Sect 13 Some Xorg.0.log lines
Sect 14 /proc/bus/input/devices
Then each section is listed with the contents in a sort of question/answer format. Text that starts in the first column is the question.
Text that is indented is the answer. The intent behind this is to make it easier to visually scan the file contents. Here's what a section
looks like
#----------------------------------------------------------------------------------
Sect 1 TC version, uname, tcedir, mydata.tgz status, /etc/sysconfig/
TC version=
10.1
uname=
Linux E310 4.19.10-tinycore #1999 SMP Tue Dec 18 13:36:47 UTC 2018 i686 GNU/Linux
tcedir=
/mnt/sda1/tce
mydata.tgz status=
-rw-rw-r-- 1 tc staff 574K May 16 23:50 /mnt/sda1/tce/mydata.tgz
/etc/sysconfig/=
Xserver Xorg
backup 1
backup_device sda1/tce
cdroms /dev/sr1 /dev/sr0
desktop flwm_topside
icons wbar
keymap KEYMAP=us
language LANG=C
mydata mydata
newmodules
ntpserver pool.ntp.org
tcuser tc
The attached TCscan200607095849.txt file is what a complete scan looks like.
To try the script just download it and:
chmod 775 TCscan.sh
./TCscan.sh
The script echoes its progress to the screen as it runs.
[EDIT]: Updated attached script to version 0.2, Jun 16, 2020. Rich
[EDIT]: Updated attached script to version 0.3, Jun 17, 2020. Rich
[EDIT]: Updated attached script to version 0.4, Jan 10, 2021. Rich
-
Hi, Rich!
Thank You, very interesting and covenient tool, good for learning.
Of course I started it immediately. One remark, it didn't succeed finding my grub2 bootloader.
#-------------------------------------------------------------------------------
Sect 11 find bootloader config file
No bootloader config files found.
-
Hi jazzbiker
... it didn't succeed finding my grub2 bootloader. ...
That's quite possible. The script only looks at what is visible. If the partition grub is installed on is not mounted, it is not visible
and will not be found. I have a couple of machines that have grub installed on partition number 1 but boot to Tinycore on a
different partition. The script will not find grub on those machines because the partition doesn't get mounted.
I also limit the search to a maximum of 6 subdirectories deep.
-
Hi Rich,
I always enjoy learning from your scripts. As I am studying TCscan I saw a couple things to share back:
Sect 8 my onboot.lst file was not found because it is uniquely named, I don't know if this is a common occurrence
lst=onboot_xorg_jwm_DEBUG64.lst
Sect 10 "Orphaned md5 files" label is showing for the .dep files
That's all, otherwise a few ideas for future:
a listing of the system aliases could be useful
a listing of the env or set command
my bootable USB flash drive bootloaders are
legacy BIOS using syslinux.cfg
UEFI BIOS using rEFId
thanks again for all your great support!
Billy
-
Hi Rudock1
... I always enjoy learning from your scripts. ...
Thank you. It's nice to hear they have some educational value. Hopefully the comments include in the script were helpful too.
... As I am studying TCscan I saw a couple things to share back:
Sect 8 my onboot.lst file was not found because it is uniquely named, I don't know if this is a common occurrence
lst=onboot_xorg_jwm_DEBUG64.lst ...
The script was primarily aimed at installation issues of newbies. As a result, I tried to focus on default install values. I suppose I
could check for the presence of lst= in /proc/cmdline to see if an alternate name was specified.
... Sect 10 "Orphaned md5 files" label is showing for the .dep files ...
Seems I forgot to edit a line after copying and pasting. Thanks for bringing it to my attention.
-
Hi Rudock1
I've uploaded an updated version of the script. I added a test for for the lst= boot code and corrected the "Orphaned md5 files"
message to "Orphaned dep files" for the .dep file test.
If you'd like to confirm I got it right it would be appreciated.
-
I realize your question is directed to Rudock1 but leaping ahead suggest minor changes
Table of Contents
Sect 8 onboot.lst, ondemand
suggest change to
Sect 8 boot lists including onboot.lst and ondemand
my section 8 output if interested is
Sect 8 onboot.lst, ondemand
/mnt/sda3/tce/openbox.lst=
haveged.tcz
firmware-amdgpu.tcz
xf86-video-amdgpu.tcz
Xorg-7.7.tcz
openbox-config.tcz
dbus.tcz
leafpad.tcz
sakura.tcz
mc.tcz
nano.tcz
mononoki-ttf-fonts.tcz
fox-dep.tcz
ondemand=
total 0
I know how to use boot lists....because you taught me ;D
but without that modest change to heading ....maybe it confuses?
Your script discovers a number of private TCEs and I have no other suggestions
-
Hi aus9
... suggest change to
Sect 8 boot lists including onboot.lst and ondemand ...
Someone not familiar with those files still won't know what that means.
The Table of Contents is sparse by design. It lists only the commands or files included in each section so the data of interest can
quickly be found. The results are intended for someone familiar with Linux commands and Tinycore specific configuration files.
An individual may only be interested in a handful of results, not all of them. A quick glance at the Table of Contents should tell
you if I tested for those results.
... Your script discovers a number of private TCEs ...
That's to be expected. Any extension missing an MD5 file will be flagged. So will any extension not listed in the repo or any
extension whose MD5 does not match the repos MD5. These tests merely report discrepancies. It is then up to the person
reviewing the results to determine whether any of those discrepancies indicate a problem.
-
Hi Rich,
I am happy to say that your Section 8 changes to find customized onboot lst files works perfectly on my system, too.
I use syslinux as one of my bootloaders. I added these lines below to your script and the .cfg file now shows up in Section 11.
added syslinux to the current list:
BootLoaders="*/extlinux */isolinux */grub */syslinux"
added syslinux under case "$loader" in
syslinux)
if [ -f "$config/syslinux.cfg" ]
then
echo "$config/syslinux.cfg=" >> $Dest.tmp
SaveIndentedResults "$config/syslinux.cfg"
NotFound=0
else
echo -e "$config/= ???\n\tNo config file found." >> $Dest.tmp
fi
;;
Thanks again for all you do for Tiny Core.
thx
Billy
-
Hi Rudock1
... I use syslinux as one of my bootloaders. I added these lines below to your script ...
Thank you. I will incorporate those changes later tonight.
-
Hi Rudock1
Hi Rudock1
... I use syslinux as one of my bootloaders. I added these lines below to your script ...
Thank you. I will incorporate those changes later tonight.
Updated script uploaded.
-
Tried script. Very useful collection of info. One issue. Section 9 showed "43 md5 file differences". When i used the APPS application, ....Maintenance...MD5 checking...it showed up as OK. Am I missing something?
-
Further...tried script on another installation. No issues with MD5 differences. The first try was on a tc 10.1 system...the second try was on a tc 11.1 system. Could the first comparision issue be because the script was comparing my local MD5's from a 10.1 systen with the 11.0 repo?
-
Hi gwalther
... One issue. Section 9 showed "43 md5 file differences". When i used the APPS application, ....Maintenance...MD5 checking...it showed up as OK. Am I missing something?
The first thing the MD5 test does is compute the MD5s of all of your extensions and saves that data in a file. It then processes each
entry in that file. If there isn't a .md5.txt file that matches the entries tce name, We flag a missing MD5 file:
Missing md5 files= 1
flash11.tcz.md5.txt
If there is a .md5.txt file we compare that MD5 against the value we saved. If they don't agree, you'll see something like this:
Failed md5 checks= 1
libmnl.tcz.md5.txt
Finally, we compare our computed MD5 against the current MD5 in the repository. Any entries not found in the repo get listed first.
Then any entries not matching the repo get listed. That part looks something like this:
Local/Repo md5 file differences= 2
foxit_reader.tcz Not in repo
FreeRDP.tcz Mismatch
Local 61026ec2671addad0d8818d90b72abc0
Repo b6f5bc43d01943b07283ebe5ac5fbfd4
boost-1.50-dev.tcz Mismatch
Local 96de970aab063d92baccce5aea3f434f
Repo 6b6520c4ee140755e8fc6ea43e98fae1
A Not in repo result may be due to a custom extension.
A Mismatch result is likely due to newer versions (updates) of the extension being available in the repository.
-
Hi gwalther
Further...tried script on another installation. No issues with MD5 differences. The first try was on a tc 10.1 system...the second try was on a tc 11.1 system. Could the first comparision issue be because the script was comparing my local MD5's from a 10.1 systen with the 11.0 repo?
That depends. If the installs were on different machines, then no.
If they were on the same machine and you are using the same tce directory for both installs, then yes. Of course you should
never be doing something like that.
-
@Rich
I think it can get the TCL Version from uname command and also the architecture.
Then, it could be used for all TCL Versions (If done Repo URL Formatting for all architectures).
We can add a "Found some custom TCEs :" and list all md5 not found tczs under it.
If user has a custom tce folder, we can find whether he has one by using "showbootcodes | grep tce" command and use that folder as tce directory. Else we can use the stock tcedir.
Can we include color in it ? (just like submitqc)
-
Hi Sashank999
I think it can get the TCL Version from uname command and also the architecture. ...
You can get the kernel version from uname , not the TC version. The version command returns the TC version.
... Then, it could be used for all TCL Versions (If done Repo URL Formatting for all architectures). ...
It should already work for all TC versions. The repo URL is retrieved using the getMirror command provided by tc-functions.
... If user has a custom tce folder, we can find whether he has one by using "showbootcodes | grep tce" command and use that folder as tce directory. Else we can use the stock tcedir. ...
Already done. See reply #5:
http://forum.tinycorelinux.net/index.php/topic,23936.msg150854.html#msg150854
... Can we include color in it ? (just like submitqc)
submitqc sends its results to the screen. TCscan.sh sends its results to a text file.
-
Oh.
But we can also make it display on the screen with color so that the user can simply find the problem himself and can try possible solutions.
Finding in a text file is difficult (I think so ::) ).
-
Hi Sashank999
The script does not identify problems. It gathers basic information about a Tinycore installation. It does not attempt to interpret the
results.
... But we can also make it display on the screen with color so that the user can simply find the problem himself and can try possible solutions. ...
The information saved is intentionally unbiased so the end user determines whether something is really a problem or not.