Recent Posts

21

TCB Q&A Forum / Re: (Tiny)Core x86 : is there a reason not to enable PAE ?

« Last post by SeventhSin on July 17, 2019, 05:58:56 AM »

@mods : please close this thread if you wish. From the creator's perspective (myself), its purpose (salient in the title) has been achieved. Other connected subjects such as the possibility of a Core64 ISO on the website are distinct topics, possibly subject(s) for future threads.

22

dCore x86_64 / Re: Linux Kernel Headers

« Last post by A Guy on July 17, 2019, 05:41:29 AM »

Awesome, this is exactly what i need.

I need to create a development and test environment so that I can create and deploy a testing environment using PXE.
These are devices we create so I need to compile the drivers in the same kernel context as the deployment (dCore) booting environment. So I need the kernel headers to compile the drivers.

I am having a lot of fun with dCore. Thanks for the project. I believe it will help with my environment.

Little bummed about the deployment of sshd not being fully documented, but hey, Linux is free , right?

23

TCB Q&A Forum / Re: (Tiny)Core x86 : is there a reason not to enable PAE ?

« Last post by SeventhSin on July 17, 2019, 05:39:22 AM »

Hi SeventhSin
I wanted to boot Tinycore from a thumb drive on an HP Proliant ML150 G6 in 32 bit mode and still take advantage of the 6 Gig of
installed RAM. I started by installing Tinycore to the thumb drive. Next I fetched modules64.gz, rootfs.gz, and vmlinuz64:
http://tinycorelinux.net/10.x/x86/release/distribution_files/
and saved them where the 32 bit kernel and initrd are stored. Then create  core64.gz  like this:

Code: [Select]

cat rootfs.gz modules64.gz > core64.gz
I have grub on my thumb drive. My  menu.lst  looks like this:

Code: [Select]

default 1
timeout 10

title TC9_32bit
root (hd0,0)
kernel /tce/boot/vmlinuz quiet  waitusb=5:UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" tce=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" home=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" opt=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" printk.time=1 syslog enable_mtrr_cleanup
initrd /tce/boot/core.gz

title TC9_Core64
root (hd0,0)
kernel /tce/boot/vmlinuz64 quiet  waitusb=5:UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" tce=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" home=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" opt=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" printk.time=1 syslog enable_mtrr_cleanup
initrd /tce/boot/core64.gzBoth  core  and  core64  share the same /home, /opt, and tce/optional directories as well as the same  onboot.lst  file:

Code: [Select]

firmware.tcz
aterm.tcz
fltk-1.3.tcz
flwm_topside.tcz
freetype.tcz
imlib2-bin.tcz
imlib2.tcz
libfontenc.tcz
libICE.tcz
libjpeg-turbo.tcz
libpng.tcz
libSM.tcz
libX11.tcz
libXau.tcz
libxcb.tcz
libXdmcp.tcz
libXext.tcz
libXfont.tcz
libXi.tcz
libXmu.tcz
libXpm.tcz
libXrandr.tcz
libXrender.tcz
libXt.tcz
libdrm.tcz
wbar.tcz
Xlibs.tcz
Xprogs.tcz
mc.tcz
pci-utils.tcz
curl.tcz
gzip.tcz
graphics-KERNEL.tcz
Xorg-7.7.tcz
alsa-config.tcz
alsa.tcz
alsamixergui.tcz
grabber.tcz
geany.tcz
wireshark.tcz
firefox-ESR.tcz
libavcodec.tcz
gnumeric.tcz
nfs-utils.tcz
pulseaudio.tcz
numlockx.tcz
gtk1.tcz
adwaita-icon-theme.tcz
util-linux.tcz
gparted.tcz
ntfsprogs.tcz
e2fsprogs.tcz
dosfstools.tcz
mtools.tcz
hfsprogs.tcz
tc-install-GUI.tcz
bind.tcz
usbutils.tcz
scsi-KERNEL.tcz
lsscsi.tcz
mdadm.tczYou'll note the 2 entries containing the word  KERNEL.  tce-load  will load the version (32 or 64 bit) that matches your running kernel.
My  tce/optional  directory contains both versions:

Code: [Select]

filesystems-4.14.10-tinycore.tcz
filesystems-4.14.10-tinycore64.tcz
graphics-4.14.10-tinycore.tcz
graphics-4.14.10-tinycore64.tcz
i2c-4.14.10-tinycore.tcz
i2c-4.14.10-tinycore64.tcz
mtd-4.14.10-tinycore.tcz
mtd-4.14.10-tinycore64.tcz
raid-dm-4.14.10-tinycore.tcz
raid-dm-4.14.10-tinycore64.tcz
scsi-4.14.10-tinycore.tcz
scsi-4.14.10-tinycore64.tcz
It's just a 32 bit install running  vmlinuz64  and 64 bit modules. That's all there is to it.

Hey Rich. Thanks for sharing your procedure. That should work very well for a custom install.

I can totally imagine the above on the Wiki. 

24

TCB Q&A Forum / Re: (Tiny)Core x86 : is there a reason not to enable PAE ?

« Last post by SeventhSin on July 17, 2019, 05:37:53 AM »

If there is something you want and it doesn't already exist it may be because you're the first to want it.

That is possible, although not certain. Maybe people wanted it but didn't dare to ask for it or didn't ask strongly enough.   

Instead of complaining

Please, no shadow boxing. Nobody's complaining, this thread is a conversation.

that someone else should have come before you and paved the way, you could make what you want and contribute so there might be some pavement for the next person.

What I want (I am restating here for brevity) is to be able to build non-trivial software on x86. Right now that is impossible for me due to "no space left on device" weirdness. Easy way around the aforementioned are:

a) PAE on x86 kernel
b) Core64 ISO

Both a) and b) would allow allocating more memory to ephemeral build machines. I can do both for myself, but that won't be paving the way for anyone else. I could even share a build script for b), but unless that results in an upload (for which I have no permissions) that would be a waste of my time.

I'll be nice

Please don't be.

and ignore for now the much more likely scenario

How much more likely? Abstract talk doesn't lead anywhere.

that no one else wanted it

Is this certain?

for some obscure reason like there was a better way. 

An unknown ("some obscure reason") plus a general abstraction ("there was a better way") add precisely zero actionable information to this conversation.

25

dCore x86_64 Imported Extensions / qtqr needs python-sip

« Last post by jls on July 17, 2019, 04:37:46 AM »

Hi Jason
please add as dep thanks

26

TCB Talk / Re: Having issues with waitusb option

« Last post by caracalla on July 17, 2019, 03:14:47 AM »

What is interesting is that when system boots up with timer expired, the not identified partition will be missing as well if I manually execute blkid tool.

27

TCE Q&A Forum / Impossible version-control !

« Last post by labeas on July 17, 2019, 02:17:48 AM »

Correct my wrong assumptions, below:-
 # version = 7.2
because so-called-updating without losing one's own jewel-applications
is very difficult.
As an example, let's analyse my attempt to fix the lost partn-1 [of 2]
from the December 23, 2015 project: [which cost many hours of labour]
  "Howto make a legacy bios/uefi dual boot usb stick with grub2"
 
Just considering 1 line/instruction of this
 (cat grubConfig  |wc -l =) 273 instruction-lines:-
    $ tce-load -i grub2-multi
   
The user should install the LATEST version. AFAIK = 10.1, today.
Q. Will the GUI-AppTool fetch the latest or the running-OS version ?!

The following instruction (entered as a single line):
   "grub-install --target=x86_64-efi --boot-directory=/mnt/sdd2/EFI/BOOT
    --efi-directory=/mnt/sdd2 --removable" ; returns:
"grub-install: error while loading shared libs: libdevmapper.so.1.02"

But GUI:Apps lists NO libdevmapper*, although it DID fetch other files
higher up the dependency tree.
The <grub2> project under consideration dates from 2015...
And <online:TC>/10.x/x86_64/tcz also has NO libdev* ?

 If GUI:Apps is syncronised to the latest version, then the users have
lost control over their existing/invested software!
 If it's set to the user's running version: how does he conveniently
install later versions of TC?

IMO "Version" should be one of the parameters of the GUI:Apps.

I've just noticed in the Comment section of GUI:Apps :-
      sudo grub-mkrescue -o myiso.iso iso
Q. Would this have a <man file>  ?

28

TCB Talk / Re: value too large for defined data type (ntfs-3g)

« Last post by curaga on July 17, 2019, 12:38:19 AM »

From man fstat:

       EOVERFLOW
              (stat())  path refers to a file whose size cannot be represented in the type
              off_t.  This can occur when an application compiled  on  a  32-bit  platform
              without  -D_FILE_OFFSET_BITS=64  calls  stat()  on a file whose size exceeds
              (1<<31)-1 bits.

That means your compilation of uftp cannot handle files over 4gb. Check configure logs for why it didn't detect or try to enable large file support.

edit: As a quick workaround, you can also split it into multiple files "split -b 3900m w10x64.vhdx splitvhd_" and then assemble them client-side with "cat splitvhd_* > w10x64.vhdx".

29

TCB Q&A Forum / Re: (Tiny)Core x86 : is there a reason not to enable PAE ?

« Last post by andyj on July 16, 2019, 07:23:17 PM »

If there is something you want and it doesn't already exist it may be because you're the first to want it. Instead of complaining that someone else should have come before you and paved the way, you could make what you want and contribute so there might be some pavement for the next person.

I'll be nice and ignore for now the much more likely scenario that no one else wanted it for some obscure reason like there was a better way. 

30

TCB Talk / value too large for defined data type (ntfs-3g)

« Last post by kern on July 16, 2019, 07:12:23 PM »

I use TinyCore 10.0 and  install uftp(http://uftp-multicast.sourceforge.net/)  to trans big file to other pc in pc classroom.

1.Tinycore start
2. mount ntfs (SSD), use ntfs-3g,  #sudo ntfs-3g /dev/sda2 /tmp/d     (in /tmp/d  has a  large file w10x64.vhdx  12GB)

3. when I try to trans file use uftp , I got a error message "value too large for defined data type"

   any suggestion
                                     Thanks!