Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: labeas on October 02, 2019, 06:19:22 PM
-
To free-up its USBsocket.
AFAICS the pid-tree must not have a node common to the BootStik's
DirTree, if I want to remove the stik after booting.
BTW this quirky laptop, where I can't find what firmware the Wifi uses,
doesn't show the <native disk>. The plugged USBbootstik is shown as sda.
Does that mean that the Win10 runs from RAM?
If so, TC must also be able to run with the Bootstik removed.
What's the underlying theory?
-
hi labeas
To free-up its USBsocket.
AFAICS the pid-tree must not have a node common to the BootStik's
DirTree, if I want to remove the stik after booting.
....
TC must also be able to run with the Bootstik removed.
What's the underlying theory?
After kernel and core.gz are loaded
you can remove usb or sd ect
if you want to load any extensions
after removing the usb storage
then some other location is needed
many options exist : cdrom , ram , internal hdd ( modules for FS need to be included in core; eg ntfs) , network
What's the underlying theory?
perhaps see http://tinycorelinux.net/concepts.html
mount-mode
and
copy-mode
wrt loading extensions
or remastering core.iso in the wiki
-
Does that mean that the Win10 runs from RAM?
this is probably a question better directed to
one of : msfn.org , reboot.pro , 911cd.net
::)
-
Hi labeas
If you want to be able to remove the boot device you need everything loaded in RAM. Create a file called copy2fs.flg in
your tce directory:
touch /etc/sysconfig/tcedir/copy2fs.flg
This also means you can not have a persistent /home or /opt directory. Then, after you reboot, if you can unmount your boot
device, it is safe to remove.
-
Is this THEORETICAL [vs. blind-monkey DoA, DoB...] view wrong?
BootStik can't be removed if any <proc> in the <PIDtree> is in
BootStik.
[I'm moving away from TC64 - booting to GUI, for SIMPLICITY].
Also with the <UEFI grub booter>, 32bit core boots to:-
$ df == .../mnt/sda1 [There's an abnormality, in that the
<native WinDisk> is invisible & USBstik is sda1 - nomally sdb].
$ sudo umount /mnt/sda1 == OK, since the WHOLE PIDtree is in
RAM, and no <lsof> is in /mnt/sda1.
To extend the system, I must copy the various *.tcz and extra
scripts from sda1 to eg. RAM:/tmp, to use in RAM.
Then I can:
$ sudo umount /mnt/sda1
-----------
Let's see how TC64 behaves?
== boots to:
tc@box:~$ random: crng init done <- `quiet` NOT used
$ df == .../mnt/sda1
$ sudo umount /mnt/sda1 == OK; same as TC64.
So the *.tcz and scripts can be stored in bootStik, but must be
copied-to and run in RAM. to allow: umount <bootStik> ?
-----------
I vaguely remember: my TC64:V7.2 [now/here] boots to GUI.
So then can the AppsTool: save the required files & install
them automatically, at next boot? What about: AFAIR `dvtm`
and possibly others, is not installed from a *.tcz.
-
You can set the copy2fs flag with the apps gui to copy extensions to ram at the next boot.
-
>You can set the copy2fs flag with the apps gui
> to copy extensions to ram at the next boot.
-- This relates to my pending-post "TC-book unsatifactory".
Does this mean the <copy2fs> flag is set in the *USBstik*,
so that at the next boot: the allocated dir's *.tcz are
loaded/installed to /tmp/tcloop/.
But after that "loaded/installed" is completed, is the USBstik
auto umounted, and if not, can the user:`sudo umount /mnt/sdb1`
in my case. AFAIR I can't. So I did: lsof | grep sdb1
to see what's holding it. And ....
--- BTW the referal to sda1 in the rest of this thread, refers
to the newer problematic laptop. Its the THEORY that matters.
-
Hi, labeas!
When it was TC9.0, i do worked without USB stick (in some instances).
1. I have loaded all needed extensions, into tce/optional, of course, i think you understand what we are about
2. After batch of extensions do satisfy my needs, i touched "tce/copy2fs.flg" file on boot flash.
3. Then after the next boot, all extensions appeared to be located in memory (inside rrot filesystem, if i am not mistaken, inside "/tmp/tce").
4. Check, does everything goes right.
5. add "umount /dev/sdb2" string to your "/opt/bootlocal.sh", and don't forget to "filetool.sh -b".
6. During the next boot you got all extensions in memory inside root filesystem, your flash drive unmounted, you can remove it and work with all the staff inside memory.
7. Voila!
I believe TC10 will work the same way, good luck!
-
2020 Oct 9 Core32 can't remove bootStik ?
This modern problematic UEFI laptop has only 2 USB sockets, so I want
to unplug the bootingUSBstik.
Booting via our 2015-published Grub, which I remember had abnormal:
Part1=linux; Partn2=FAT now shows ?!?!: # fdisk -l == ...
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/sda1 0,32,33 467,219,8 2048 7516159 7514112 3669M 83 Linux
/dev/sda2 598,0,1 541,23,32 7516160 26274559 18758400 9159M 83 Linux
....
/dev/mmcblk0p1 0,130,3 1023,254,63 8192 62333951 62325760 29.7G c Win95 FAT32 (LBA)
is the SDcard which I want to use for storing my own Core32 files.
,,# fdisk -l" does NOT show the Win10 disks partitions.
Imediately after boot: ,,df" shows /mnt/sda1.
So far [untill I get a working Wifi] I've only installed mc & gpm via:-
$ cat ./InstallThese ==
for FILE in `ls *tcz*` ; do
tce-load -i $FILE ; done
echo "setup gpm! & Install own Scripts"
sudo gpm -m /dev/psaux -t ps2
-----
I'm able to umount & remove the sda1, sda2 stik, before trying to
install gpm & mc via the "InstallThese" script in the "gpm.mc" dir
which also has the *.tcz files for gpm & mc.
But if I copy & run: /mnt/sda2/Core32/gpm.mc to RAM:/tmp or SDcard:
$ tce-load -i mc.tcz [or other *.tcz] returns no ,,install'' reply.
I don't want to analyse tce-load. Theoretically it could be programmed
to only work from the ,,booted partition'' ??
I don't want to now reboot and check:
,,less /proc/1/mounts"
Why can't ,,tce-load'' be called from a script in RAM or SD card,
whereas eg. ,,echo" can ?!
PS. I'm now in Win10, to have wifi ability; and <above fdisk-ed sda2>
IS mountable ie. NOT linux, as indicated by Core32:fdisk ?!
Something is seriously wrong ?
PSS. another error/quirk: since grub.cfg uses the same <tce> for both
Core32 & TC64 ....= a MESS !! Need separate lists of tcz to load ??
menuentry "TC64Fix" {
linux /boot64/vmlinuz64Fixd waitusb=10:UUID="bfe6116c-473a-4ee9-bbac-3638039dc9ad"
initrd /boot64/rootfs64.gz /boot64/modules64.gz
}
menuentry "CoreFont" {
linux /boot/vmlinuz waitusb=10:UUID="bfe6116c-473a-4ee9-bbac-3638039dc9ad"
initrd /boot/rootfs.gz /boot/modules.gz
}
-------------------------------- END --------------------------
-
PSS. another error/quirk: since grub.cfg uses the same <tce> for both
Core32 & TC64 ....= a MESS !! Need separate lists of tcz to load ??
Use the "tce=" boot code to set, for example, tce=tce for 32-bit and tce=tce64 for 64-bit.