Tiny Core Linux

Tiny Core Base => Raspberry Pi => piCore Test Releases => Topic started by: bmarkus on December 28, 2015, 06:26:39 AM

Title: piCore-7.0rc2
Post by: bmarkus on December 28, 2015, 06:26:39 AM
Team Tiny Core is pleased to announce the availability of piCore-7.0rc2, the second release candidate of the Raspberry Pi port of Tiny Core Linux (TC). Changes in this release:

piCore-7.0rc2

* udev rule (98-tc.rules) to handle USB storage devices added back


piCore-7.0rc1

* MicroPython updated to 1.5.1-162
* firmware updated to 19-dec-2015


piCore-7.0beta1

* kernel updated to 4.1.13
* GCC updated to 5.3.0
* MicroPython updated to 1.5.1-72
* SHOWAPPS boot code works now
* copy2fs.flg works now
* KERNEL substitution in onboot.lst works now
* USB device recognition is enhanced
* unified armv6/armv7 SD card image

The most important change is that the same SD card image now works with armv6 (RPi1) and armv7 (RPi2) boards. It comes with SSH server and mc (Midnight Commander) preinstalled. From now only one image is available per version.


piCore-7.0alpha8

* kernel updated to 4.1.12
* MicroPython updated
* RPi firmware updated
* BusyBox updated to 1.24.1
* cliorx synced to common TC base
* copy2fs.flg implemented


piCore-7.0alpha7

* kernel updated to 4.1.8
* MicroPython updated to 1.4.6
* fixed tce-load loop mounting bug on armv6


piCore-7.0alpha6:

* bug fixes
* BusyBox pstree added to base


piCore-7.0alpha5:

* kernel updated to 4.1.7
* new USB sound cards enabled

From now openssl-1.0.1.tcz replaced with openssl.tcz which is the latest 1.0.2d upstream with SSLv2/SSLv3 disabled. Packages using openssl are partly rebuilt remaining will be rebuilt.

python3.tcz renamed to python3.4.tcz and python3.5.tcz added to repo.


piCore-7.0alpha4:

* util-linux updated to 2.7
* BusyBox mount/umount replaced with util-linux
* new, faster startup tcz loader (copy to RAM is not yet supported)


piCore-7.0alpha3:

* kernel updated to 4.1.6
* must have kernel modules moved to kernel
* HDMI audio patched to support 192kbs audio
* ext4 file system encryption enabled
* Mediatek WiFi adapters supported
* New audio DAC added
* default CPU speed governor changed to performance
* Core scripts updated to TC 6.4 level


piCore-7.0alpha2:

* Core scripts updated to latest common script base
* significantly reduced startup time
* new motd/penguin
* MicroPython updated, heap size increased to 1M from 128k


piCore-7.0alpha1:

* kernel 4.1.4
* glibc 2.22
* BusyBox 1.23.2
* gcc 5.2.0
* e2fsprog 1.42.13
* util-linux 2.26.2

This version supports the RPi CM (Compute Module).

As a new feature Micro Python added to base. It is a small footprint version of Python 3.4 developed for embedded systems, ideal for scripting tools replacing shell.


Download links:

http://tinycorelinux.net/7.x/armv7/test_releases/ - for RPi2
http://tinycorelinux.net/7.x/armv6/test_releases/ - for all other boards

Only the SSH version is offered. If you want GUI, install TC.tcz from the repo. To get the base system with cloud mode, no persistent storage just delete the second partition, /dev/mmcblk0p2 on the SD card.


Notes:

To enable special devices and interfaces check config.txt file and read https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

The final notice, don't forget to expand /dev/mmcblk0p2 before adding extensions, as described in README.
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 28, 2015, 09:15:02 AM
On a rpi2, when doing a warm boot, about half of the time, the reboot process finishes with out mounting the tce partition.  (which is the only partition that I have on this box) 

Other observation, I upgraded from 7.0b1 to 7.0rc2   doing an inplace upgrade.  This sd card had the old openssh-1.0.1.tcz still laying around on it.    this extension was getting loaded rather than the proper openssh.tcz, so opensshd was not starting.

once I removed the old extension from the disk, the proper extension is now being loaded. 
Title: Re: piCore-7.0rc2
Post by: bmarkus on December 28, 2015, 09:43:49 AM
On a rpi2, when doing a warm boot, about half of the time, the reboot process finishes with out mounting the tce partition.  (which is the only partition that I have on this box) 

When it is not mounted, do you see something interesting in dmesg?

Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 28, 2015, 12:00:09 PM
Nope,

Both Boot processes are identical, up to the point where the disk actually gets mounted.   both good and bad boots recognize card and both partitions at about 1.45 seconds.   At the end of the bad boot cycle, /etc/fstab has all of the partitions listed, just nothing mounted.    syslog had nothing extra to say.

where in the boot process does it actually mount the tce partition?

I can break it every time by adding the boot param "nofstab"   yet when that boot code is active, the fstab is still properly populated with the partitions.

Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 29, 2015, 07:42:15 AM
I had some time to play with this.    I remade the initrd making a change to tc-config.

(Note I removed the extra commented out lines)

/sbin/udevd --daemon 2>&1 >/dev/null
/sbin/udevadm trigger --action=add 2>&1 >/dev/null &
/sbin/udevadm settle

Adding the settle command fixed the problem.....   we could probably remove the "&" from the trigger action to let it finish before going on........ not sure which way is faster.  Adding the settle did add about 0.1 sec to the boot time.
Title: Re: piCore-7.0rc2
Post by: bmarkus on December 29, 2015, 11:16:55 AM
Paul,

thanks. It looks OK, I will add settle in next release.

Béla
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 29, 2015, 12:26:53 PM
Paul,

thanks. It looks OK, I will add settle in next release.

Béla

I tested removing the "&" from the trigger line....works just the same.  but does appear to be slightly slower. 

While your in there, take a look at the nofstab command line option.....note the location of 98-tc.rules   The last update broke the intention of the nofstab command line switch.
Title: Re: piCore-7.0rc2
Post by: bmarkus on December 29, 2015, 12:36:09 PM
Thanks, fixed in rc3
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 30, 2015, 05:07:03 AM
These rpi2's execute commands so fast, I've ran into another problem.

The hostname is set in bootsync.sh,  the hostname is not getting set before udhcpc runs on the eth0 interface.  So the device is just showing up on my router as "box" instead of its proper name.

This is the end of tc-config
Code: [Select]
# After restore items
if [ -n "$NODHCP" ]; then
        echo "${GREEN}Skipping DHCP broadcast/network detection as requested on boot commandline.${NORMAL}"
else
        [ -z "$DHCP_RAN" ] && /etc/init.d/dhcp.sh &
        [ -z "$NORTC" ] || /etc/init.d/settime.sh &
fi

[ -n "$CRON" ] && /etc/init.d/services/crond start

/sbin/loadcpufreq 2>/dev/null &

/opt/bootsync.sh

Since the restore is already done, do we move bootsync to happen first.   Or do we just put a small trap in dhcp.sh to make sure it waits for bootsync to run before running udhcpc......
Title: Re: piCore-7.0rc2
Post by: jgrulich on December 30, 2015, 05:58:44 AM
It's enough to execute the hostname set before the udhcp, not need to run whole bootsync.sh. Otherwise the bootsync.sh need to be run separately from bootlocal.sh to be sure that bootlocal.sh is run after udhcp is executed when whole boot process is finished. In my case i make a lot of different operations with the network in the bootlocal.sh.
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 30, 2015, 06:14:33 AM
It's enough to execute the hostname set before the udhcp, not need to run whole bootsync.sh. Otherwise the bootsync.sh need to be run separately from bootlocal.sh to be sure that bootlocal.sh is run after udhcp is executed when whole boot process is finished. In my case i make a lot of different operations with the network in the bootlocal.sh.

Definitely a race track.   The question is where you edit and save the host name, right now we edit bootsync.sh. 
Title: Re: piCore-7.0rc2
Post by: bmarkus on December 30, 2015, 06:25:19 AM
Set host name in cmdline
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 30, 2015, 07:51:11 AM
Set host name in cmdline

I suppose, it's just much easier to use the setting in bootsync.sh

Setting the hostname in bootsync makes upgrading multiple pi's easier.    The boot partition is the same on all of my pi's, all of the data is in the backup.


Title: Re: piCore-7.0rc2
Post by: Rich on December 30, 2015, 08:22:06 AM
Hi Paul_123
This is from the X86 version under TC4 so I don't know if it's valid under PI. In tc-config:
Code: [Select]
# Here we check all the boot parameters using the fastest way known to men, case & loop
echo -n "${BLUE}Checking boot options...${NORMAL}"
for i in `cat /proc/cmdline`; do
case $i in
*=*)
case $i in
waitusb*) WAITUSB=${i#*=} ;;
lang*) LANGUAGE=${i#*=} ;;
kmap*) KEYMAP=${i#*=} ;;
tz*) TZ=${i#*=} ;;
desktop*) DESKTOP=${i#*=} ;;
icons*) ICONS=${i#*=} ;;
user*) USER=${i#*=} ;;
home*) MYHOME=${i#*=} ;;
tcvd*) TCVD=${i#*=} ;;
opt*) MYOPT=${i#*=} ;;
swapfile*) SWAPFILE=${i#*=} ;;
resume*) RESUME=${i#*=} ;;
host*) HOST=1 ;;
---------------- Snip ------------------
It appears to check if the  host  boot code exists. Then further down:
Code: [Select]
if [ -n "$HOST" ]; then
sethostname
else
/bin/hostname -F /etc/hostname
fi
It looks like if you set the hostname in  /etc/hostname  and back it up, it will be used if the  host  boot code exists.
Title: Re: piCore-7.0rc2
Post by: Greg Erskine on December 30, 2015, 12:29:46 PM
The hostname is set in bootsync.sh,  the hostname is not getting set before udhcpc runs on the eth0 interface.  So the device is just showing up on my router as "box" instead of its proper name./quote]

Hi Paul_123,

I can confirm this behaviour but it's been around for quite a while. The solution was to add hostname to cmdline.txt.

I don't like the way $HOST was also used in get_app routine.

regard
Greg



Title: Re: piCore-7.0rc2
Post by: Rich on December 30, 2015, 01:33:22 PM
Hi Greg Erskine
Quote
I don't like the way $HOST was also used in get_app routine.
I noticed that too. Though I couldn't wrap my head around a lot of the syntax, it looked like the $HOST variable was
being recycled for a different purpose.
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 30, 2015, 02:46:34 PM
This is from the X86 version under TC4 so I don't know if it's valid under PI. In tc-config:

It looks like if you set the hostname in  /etc/hostname  and back it up, it will be used if the  host  boot code exists.

Code on piCore is the same.   You also need to look at /usr/bin/sethostname that gets called during bootsync.sh  you have to specify the actual hostname on the command line.   Editing /etc/hostname and adding to your backup set does nothing.   You must specify "host=newname" on the command line to have any affect.

There is a fairly easy solution in adding a handshake between the command /usr/bin/sethostname running and /etc/init.d/dhcp.sh running.

Added at the end of /usr/bin/sethostname
Code: [Select]
touch /tmp/sethostnameran
Added to the beginning of /etc/init.d/hdcp.sh
Code: [Select]
CNT=0
until [ -e "/tmp/sethostnameran" ]
do
  [ $((CNT++)) -gt 100 ] && break || sleep 0.1
done
rm -fr /tmp/sethostmaneran

There is probably no need for a timeout trap, since sethostname always gets called.....but just incase someone changes /opt/bootsync.sh it will timeout after 10 seconds

And yes, it looks like $HOST is just being recycled.....it is referring the the remote hostname for retrieving apps.  It doesn't get used until after the local hostname is set.......so no big deal, but it's a little confusing.   (I'm a little fuzzy on variable scope in shell scripts too, but I think it is a local scope too)
Title: Re: piCore-7.0rc2
Post by: Rich on December 30, 2015, 06:05:47 PM
Hi Paul_123
Actually I misspoke, upon taking a closer look:
Code: [Select]
if [ -n "$HOST" ]; then
sethostname
else
/bin/hostname -F /etc/hostname
fi
If you do not use the  host  boot code, the else path will be taken and set the hostname from /etc/hostname. This
happens early in the tc-config script. No need to call  sethostname  from  bootsync.sh  in this case.
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 30, 2015, 07:40:19 PM
Hi Paul_123
Actually I misspoke, upon taking a closer look:
Code: [Select]
if [ -n "$HOST" ]; then
sethostname
else
/bin/hostname -F /etc/hostname
fi
If you do not use the  host  boot code, the else path will be taken and set the hostname from /etc/hostname. This
happens early in the tc-config script. No need to call  sethostname  from  bootsync.sh  in this case.

Yes, that runs early in the boot process, but the persistent data has not been restored at that point, so all you get is the name that is stored in the initrd.
Title: Re: piCore-7.0rc2
Post by: Rich on December 30, 2015, 07:46:56 PM
Hi Paul_123
In that case, disregard everything I said. :)
Title: Re: piCore-7.0rc2
Post by: Paul_123 on December 31, 2015, 07:22:34 AM
Hi Paul_123
In that case, disregard everything I said. :)

Lol...it is confusing.

Perhaps we should put a comment with the sethostname command in bootsync, that it doesn't work if you want the proper hostname broadcast to your dhcp server.
Title: Re: piCore-7.0rc2
Post by: gavinmc42 on January 04, 2016, 07:10:26 AM
Hi Bela,

Running 7.0rc1, installed a bunch of tcz including TC and vlc
ssh got broke, went looking and found openssl-1.0.1.tcz was also installed.
Deleting it and keeping the other openssl.tcz fixed the ssh issue with rc1.
Not sure if you have fixed it for rc2/3

Because I installed lots of tcz's I'm not sure which xxx.tcz.dep file required the openssl-1.0.1 version.

Title: Re: piCore-7.0rc2
Post by: bmarkus on January 05, 2016, 12:09:17 AM
Hi Bela,

Running 7.0rc1, installed a bunch of tcz including TC and vlc
ssh got broke, went looking and found openssl-1.0.1.tcz was also installed.
Deleting it and keeping the other openssl.tcz fixed the ssh issue with rc1.
Not sure if you have fixed it for rc2/3

Because I installed lots of tcz's I'm not sure which xxx.tcz.dep file required the openssl-1.0.1 version.

openssl-1.0.1.tcz is the old package from 6.x while openssl.tcz is the current openssl-1.0.2 branch for 7.x As soon as packages will be rebuilt against current opnessl.tcz openssl-1.0.1.tcz will be dropped. It is ongoing.

Anyhow, it has nothing to do with rc's and base, only the repo.
Title: Re: piCore-7.0rc2
Post by: Paul_123 on January 05, 2016, 05:51:37 AM

openssl-1.0.1.tcz is the old package from 6.x while openssl.tcz is the current openssl-1.0.2 branch for 7.x As soon as packages will be rebuilt against current opnessl.tcz openssl-1.0.1.tcz will be dropped. It is ongoing.

Anyhow, it has nothing to do with rc's and base, only the repo.

Bela,

put a copy of this extension on your system.....do not load it.    When you reboot, it will get loaded.  I think there is a problem with
tce-bootload.

Paul
Title: Re: piCore-7.0rc2
Post by: Gerrelt on January 07, 2016, 01:23:58 PM

I have installed rc2 on two raspberries, no problems encountered!

Greetings,
   Gerrelt
Title: Re: piCore-7.0rc2
Post by: beerstein on January 08, 2016, 05:55:04 AM
HI: I installed and ran piCore-7.0rc2 last night on a RASBI B with TC.tcz and installed pcmanfm, and VLC. Then I connected from my debian8 PC into
tc@hostname via mc. I copied files from the Pc to RASPI it worked Ok but at the end of the file transfer the PC did not disconnect and und a large number
appeared counting down on screen. After that the ssh connection was broken. On the RASPI in CLI (CTRL-ALT-F1) the following message showed up:

$ error openssl mismatch. Built against 1000204f, you have 1000109f
2cycles done

I remember seeing that message on piCorePlayer too?

What can I do?
Would it be enough to remove openssl and reinstall openssl or do Ii need to remove all openss..... related extensions?

Thanks for helping here.
Title: Re: piCore-7.0rc2
Post by: Paul_123 on January 08, 2016, 03:51:19 PM
HI: I installed and ran piCore-7.0rc2 last night on a RASBI B with TC.tcz and installed pcmanfm, and VLC. Then I connected from my debian8 PC into
tc@hostname via mc. I copied files from the Pc to RASPI it worked Ok but at the end of the file transfer the PC did not disconnect and und a large number
appeared counting down on screen. After that the ssh connection was broken. On the RASPI in CLI (CTRL-ALT-F1) the following message showed up:

$ error openssl mismatch. Built against 1000204f, you have 1000109f
2cycles done

I remember seeing that message on piCorePlayer too?

What can I do?
Would it be enough to remove openssl and reinstall openssl or do Ii need to remove all openss..... related extensions?

Thanks for helping here.

That is the OpenSSL issue that. I and Gavin reported.  Make sure that you delete the OpenSSL-1.0.1.tcz from your system.   You should only be loading OpenSSL.tcz