issues with inital setup

[pixel]

rfkill gives no output and iw throws this error: "error while loeadig shared libraries: libnl-genl-3.so.200: wrong elf class: elfclass32". just to make sure i downloaded the 64bit version i redownloaded the libnl extension and the error persists. i've used wifi on windows with this laptop for 3+ years with no issue.

[gadget42]

mostly to boost your confidence and spirits, it would be instructive/interesting for you to grab the latest EasyOS from Barry Kauler and see how that performs. there is a very slight learning curve to the puppy/quirky/easyos distros that Barry has so graciously worked on for many years but definitely well worth it. here are the current links(for future visitors, double-checking the parent directory will show if a newer version exists...time does march-on after all)

latest:
https://distro.ibiblio.org/easyos/amd64/releases/scarthgap/2024/6.1.1/
readme:
https://distro.ibiblio.org/easyos/amd64/releases/scarthgap/2024/6.1.1/readme.htm
release notes:
https://distro.ibiblio.org/easyos/amd64/releases/scarthgap/2024/6.1.1/release-notes.htm

[Juanito]

I just checked the rfkill extension in the CorePure64-15.x repo:

http://tinycorelinux.net/15.x/x86_64/tcz/rfkill.tcz

and got this:

Code: [Select]

file /tmp/tcloop/rfkill/usr/local/sbin/rfkill
/tmp/tcloop/rfkill/usr/local/sbin/rfkill: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.0.21, stripped
..so it is 64-bit

..and it works:

Code: [Select]

sudo rfkill list all
0: dell-rbtn: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
To check which firmware your wifi hardware needs, reboot, load only the wireless-KERNEL and bluetooth-KERNEL extensions and issue this command:

Code: [Select]

dmesg | grep firmware
...
[   23.699520] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[   23.785437] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-7260-17.ucode failed with error -2
[   23.843757] iwlwifi 0000:02:00.0: loaded firmware version 17.459231.0 7260-17.ucode op_mode iwlmvm
[  747.236848] bluetooth hci0: Direct firmware load for intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq failed with error -2
[  747.239327] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq..you will see something analogous to "Direct firmware load for iwlwifi-7260-17.ucode failed with error -2", which will give you the name of the firmware file you need. The blueooth drivers were included in case your hardware needs both to work.

Note also, from: http://tinycorelinux.net/15.x/x86_64/tcz/wifi.tcz.tree

..openssl-1.1.1 is not needed.

[GNUser]

I checked the rfkill extension before recommending it and it works for me on TCL15 x86_64, too:

Code: [Select]

$ sudo rfkill list all
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
It seems the problem--or at least part of the problem--is that pixel accidentally downloaded libnl or some other extension from the 32-bit repo. Using a wired network connection for initial setup or using FetchExt.sh on a linux distro with working wifi is definitely the way to go. I would delete all downloaded extensions and start from scratch with one of these two methods.

Juanito, thank you for the tip on how to find exact name of the necessary firmware. This is much better than my method ("lshw -c network" to get model followed by internet search).

[pixel]

i have redownloaded every extension and can verify everything is meant for x64. i heres what dmesg had to say:

bluetooth hci0: Direct firmware load for rtl_bt/rtl8821c_fw.bin failed with error -2
Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8821c_fw not found
platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
rtw_8821ce 0000:02:00.0: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2
rtw_8821ce 0000:02:00.0: failed to request firmware
rtw_8821ce 0000:02:00.0: failed to load firmware

is there perhaps an issue in how i load extensions? all i do is mount my usb and tce-load -wi *.tcz. not sure if i need to load the firmware before wireless-kernel and bluetooth-kernel.

[Juanito]

So your bluetooth firmware is in the firmware-rtl_bt extension and your wifi firmware is in the firmware-rtlwifi extension.

For things to work properly, the firmware needs to be loaded before any other extensions.

For example:

Code: [Select]

tce-load -i firmware-rtlwifi wifi..should get your wifi working

You can double-check that the firmware gets loaded using dmesg as explained previously.

[pixel]

im happy to say my wifi is working now

so i downloaded the tce-install gui extension and ran through it and it said the installation completed with no issues. i did sudo reboot and my computer doesnt recognize my hard drive as bootable, probably because tce-install gui didnt create an efi nor a boot directory where it put lost+found along with tce. not sure if yall want me to open up another thread about this.

[curaga]

The installer does not support EFI. Please enable CSM/bios boot in your bios.

[pixel]

is there a guide for x64 uefi systems? does tc-install work for x64 uefi or am I gonna have to do everything manually? my bios is uefi only.

[Juanito]

You will need to do it manually - see the thread on uefi/legacy bios dual boot.

https://forum.tinycorelinux.net/index.php/topic,19364.0.html

..you only need the uefi part of things.

[pixel]

when i try to do sudo mkfs.vfat /dev/mmcblk0p2, it says:

Cannot initialize conversion from codepage 850 to ANSI_X3.4-1968: Invalid argument
Cannot initialize conversion from ANSI_X3.4-1968 to codepage 850: Invalid argument
Using internal CP850 conversion table
mkfs.vfat: /dev/mmcblk0p2 contains a mounted filesystem.

[pixel]

i followed the rest of the tutorial and it didnt work. i think it was because of me being unable to use mkfs.vfat. some hours later now i cant mount my drives, its saying input/output error.

[CNK]

when i try to do sudo mkfs.vfat /dev/mmcblk0p2, it says:

Cannot initialize conversion from codepage 850 to ANSI_X3.4-1968: Invalid argument
Cannot initialize conversion from ANSI_X3.4-1968 to codepage 850: Invalid argument
Using internal CP850 conversion table
mkfs.vfat: /dev/mmcblk0p2 contains a mounted filesystem.

That is a problem in recent TC versions because newer glibc isn't using files in /usr/lib/gconv/gconv-modules.d that are installed from glibc_gconv.tcz. I described this work around earlier.

[pixel]

it turns out it didnt matter as following the tutorial at https://www.parkytowers.me.uk/thin/Linux/TinycoreUEFI.shtml succeeds in loading tc now im trying to setup persistence with tce. i specify tce=mmcblk0p1 on boot, yet /etc/sysconfig/tcedir seems to always just point to /tce, requiring me to delete and recreate it pointing to the correct /mnt/mmcblk0p1/tce for any of the tce related commands to work.

[CentralWare]

@pixel: The easiest and safest way we usually handle persistence here at my office is to use a drive's ID (UUID) in the command-line.

Code: [Select]

blkid | grep mmcblkThis should give you a list of any drive/partition that is seen by the operating system (with "mmcblk" in it)
In the command line (ie: boot commands) you would enter

Code: [Select]

tce=UUID="abcdef..."..where obviously "abcdef..." would be the ID retrieved from the blkid command above it.
This can be repeated for the /home and /opt directories as well where
opt=UUID="ID String"
home=UUID="ID String"

You may also use the drive/partition's LABEL (tce=LABEL="Something") but this isn't fool-proof.
Additionally, if you simply create /mnt/mmcblk0p1/tce in most occasions TinyCore will search for and find it, even when it's not entered as a boot command, but again, this isn't fool-proof.

Your mmcblk0p1/tce directory should be chown'ed by tc:staff recursively if you're using the default user setup.

NOW, one thing I have noticed with a few machines is MMC block devices are sometimes NOT detected in the hardware layer FAST enough for the boot process to complete successfully.
In this case you want to set USB WAIT TIMEOUT to about 15 seconds (much more than necessary, but well within reason) as a boot command with the same UUID as your tce=UUID so that you know the device is "online" after a warm/cold boot.

Here's an example configuration from and x64 machine with an odd, onboard M.2 SATA/PICe hybrid slot which the kernel supports and detects...  but it's not "ready" for the kernel to communicate with for a number of seconds after BIOS completes its start-up. This configuration sets both tce and /opt as persistent locations on the drive AND allows for up to 15 seconds to pass while it scans for its given UUID (If it detects the drive at 7 seconds, for example, the remaining timeout is skipped. If it is not detected within 15 seconds, which rarely happens, /mnt/mmcblk0p1/tce will not be detected as /etc/sysconfig/tcedir and instead, points unintentionally to /tce which fails.  The default install sets waitusb to five seconds, which this specific device failed constantly at that value.)

/mnt/mmcblk0p1/tce/boot/extlinux/extlinux.conf

Code: [Select]

DEFAULT corepure64
LABEL corepure64
KERNEL /tce/boot/vmlinuz64
INITRD /tce/boot/corepure64.gz
APPEND quiet syslog vga=791 waitusb=15:UUID="00000000-1111-2222-3333-444445555566" tce=UUID="00000000-1111-2222-3333-444445555566" opt=UUID="00000000-1111-2222-3333-444445555566"

Note: If you add the tce=UUID entry in the configuration file, you normally will not have to create the tce directory yourself.  This is a good way to test the timeout and hardware interaction during boot by NOT creating the directory manually.