WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: small proposals for next TC17 x86_64  (Read 633 times)

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 917
small proposals for next TC17 x86_64
« on: August 22, 2025, 02:10:55 PM »
I played a little with TC16 64 bits, by extracting the corepure64.cpio (from latest virgin core.gz) in a temporary folder. I try to "reproduce" one file at a time the logic of TC run flow, starting from an empty chroot. FYI, I have /bin and /sbin simlinks to /usr/bin, and /lib simlink to /usr/lib, (for faster searching, but it should not matter).
My observations:
1. the sh (or ash) in the latest busybox has buit-in commands echo and history. So there is no need for sim-links or file history.sh. Yes, I know, not big deal, not even speed or space gain, but if we want to be pedantic / minimalist, then we can remove redundancy. Same logic like why not to have already a /home/tc/ per-populated in core.gz and eventually rename user tc in whatever other user, by using "sed" if a parameter in command line is provided, instead of copy the /etc/skeleton. (Yeah, because we count few 4KB in RAM for x86_64).

2. in /etc/init.d/rc.shutdown , improvment for tcz and "scm" extensions, by first to check for [ -d /apps ] and for [ -d /tmp/tcloop ] before we ask the artillery for functions like ash (for),mount, awk, unmont.
Code: [Select]
# Unmount all tcz extensions that were mounted into /tmp/tcloop via loopback
for loop in $(mount | awk '/\/tmp\/tcloop/{print substr($1,10,3)}'|sort -nr); do umount -d /dev/loop"$loop" 2>/dev/null; done

# Unmount all scm extensions that were mounted into /apps via loopback
for loop in $(mount | awk '/\/apps/{print substr($1,10,3)}'|sort -nr); do umount -d /dev/loop"$loop" 2>/dev/null; done

3. Maybe add and extra condition for searching for swap to unmount (like blkid type swap?), not only if was initially in TC command line,
Code: [Select]
if ! grep -q "noswap" /proc/cmdline; then
   echo "${BLUE}Disabling swap space.${NORMAL}"
   swapoff -a 2>/dev/null
fi
because maybe the user wanted later to add a file / partition swap, not when booted TC. YMMV.

FYI; I can live without any improvements, but I wanted to contribute back a little.

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 917
Re: small proposals for next TC17 x86_64
« Reply #1 on: August 23, 2025, 03:14:12 AM »
If I am not wrong then in script  "etc/init.d/settime.sh" line 22 should replace 2015 with 2026, or 2030 :P
Code: [Select]
        if [ "$XXX" -ge "2015" ];
        then
            break
        fi

        if [ $CNT -gt 10 ];
        then
            /usr/bin/getTime.sh
            if [ $NRT -gt 5 ];
            then
                break
            fi
or else the getTime.sh will not have a chance to be executed.

PS: because the script is just 667 BITS, but it still takes 4KB (=4096 BITS) in RAM as a kernel page, it will be nice to have comments inside; especially because using the same variable CNT for different proposes /loops.
« Last Edit: August 23, 2025, 03:26:05 AM by nick65go »

Offline gadget42

  • Hero Member
  • *****
  • Posts: 921
Re: small proposals for next TC17 x86_64
« Reply #2 on: August 23, 2025, 09:56:37 AM »
** WARNING: connection is not using a post-quantum kex exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 917
Re: small proposals for next TC17 x86_64
« Reply #3 on: August 23, 2025, 12:46:47 PM »
seems related to a previous thread
https://forum.tinycorelinux.net/index.php/topic,27626.0.html
Thanks, it IS related (just THIS topic about getTime.sh, not my previously remarks about ash or rs.shutdown.sh)
But, from my point of view, it is NOT solved yet. My (humble) expectations were that it should work in almost cases, without too many user interventions (grub/tc parameters).

Ex: I have an old laptop with dead battery (default date 2001?) which auto started in BIOS settings. I just guess a date 23/08/2025 and a fake/guess time from my phone. It boots but time is NOT properly synchronized because I did NOT add tc boot parameters (maybe I forgot which one I need, so no rtc etc). If user friendly logic, TC should check the network connection (eth0) and if was up then synchronize the clock from internet,  or else Firefox not working properly.
What about if dead battery + NO wire connection available, because I have just WiFi (network started later, after booting)? Even in this case TC should be user friendly. FYI: maybe the new router has no sockets for cable, just WiFi antenna, or maybe the old NIC card is malfunction so I use a WiFI from external USB dongle for this old laptop.

My point was about "arbitrary" chosen year 2015 is NOT suitable for many cases.I just ask if a correction should be in that file (settime.sh) called later after boot. Was not about bypassing using other scripts from mydata.gz etc.
« Last Edit: August 23, 2025, 12:56:02 PM by nick65go »

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 12235
Re: small proposals for next TC17 x86_64
« Reply #4 on: August 23, 2025, 03:21:30 PM »
Hi nick65go
This thread also deals with settime.sh:
https://forum.tinycorelinux.net/index.php/topic,22062

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 917
Re: small proposals for next TC17 x86_64
« Reply #5 on: August 23, 2025, 05:23:28 PM »
Thanks @Rich and @gadget42 for the "head up" of the similar topic. So I assume no change approved (if it is not broken then not fixing) because has been working for the last 10 years.

I think I understand that the "problem" initiated because a rasberiPi (ARM) CPU having (or not) a RTC slow / missing etc. And because TC developers wish to have "common" scripts (for easy maintenance) for ALL architecture. So more checks / complications for all x86 / x86-64 which have a RTC chip by default. Yeah, compatibly hindering the progress.Usually should not punish a critical mass population for few out-liars. So maybe are more ARM than x86* for your targets.

My logic in "inspecting" the sh scripts assumed that all scripts are independently functional and (potentially) can inherit some ASH (global scope) shell variable. Which was NOT the case for setTime.sh. (like the case: dead battery + good RTC chip + bad NIC + good WiFi). Hm, hard to change something when dealing between dinosaurs (BTW: I am a surviving T-Rex)  Q.E.D.
« Last Edit: August 23, 2025, 05:34:34 PM by nick65go »