Tiny Core Linux
Tiny Core Base => Corepure64 => Topic started by: nurbles on July 28, 2023, 12:39:52 PM
-
I've got just about everything working on my fresh new TinyCorePure64-14.0 system. I've noticed some unexpected messages during boot. The first messages flash up and disappear too fast to capture in between the BIOS messages and the screen that starts with the TinyCore version number, but I think they are some sort of failure -- clearly non-fatal, but that type of messages doesn't look good to customers. :)
I took a photo of the first page of the longer set of messages. They appear between 'loading modules...' and the GUI starting up. There is at least a screenful of these, perhaps more. They're only visible for a second or two, so not a real problem, except again for customer optics: Apparent(?) Warning/Error messages never look good to customers. :( Here's what I see (transcribed by hand from a photo because the POST button stopped working after the preview showed that I'd added the photo correctly):
Loading extensions...udevd[164]: IMPORT{builtin}: 'hwdb --subsystem:input '--loo
kup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libuacon.ru
les:18
udevd[164]: IMPORT{builtin): 'hwdb --subsystem:input '--lookup-prefix:libwacon:n
ame:$ATTR{name}:'' unknown /etc/udev/rules.d/65-libuacon.rules:18
udevd[164]: IMPORT{builtin): 'hwdb --subsystem:input '--lookup-prefix:libwacon:n
ame:$ATTR{name}:'' unknown /etc/udev/rules.d/65-libuacon.rules:18
udevd[164]: IMPORT{builtin): 'hwdb --subsystem:input '--lookup-prefix:libwacon:n
ame:$ATTR{name}:'' unknown /etc/udev/rules.d/65-libuacon.rules:18
udevd[164]: IMPORT{builtin): 'hwdb --subsystem:input '--lookup-prefix:libwacon:n
ame:$ATTR{name}:'' unknown /etc/udev/rules.d/65-libuacon.rules:18
Whatever all these messages mean, they don't appear to be affecting anything that we care about, if they are affecting anything at all.
-
Hi nurbles,
You may turn the system log on, adding for example "syslog loglevel=3" bootcodes to Your bootloader config. If I am not mistaken You installed TC with the help of official installer?
-
Hi nurbles
It has something to do with hwdb:
https://forum.tinycorelinux.net/index.php/topic,25577.0.html
-
The first messages are from your bootloader, just reporting it loaded the kernel and so on. How to remove those depends on your bootloader.
-
@jazzbiker: Thanks! Adding the syslog settings you provided moved the messages from the boot screen to /var/log/messages where I can now report that the ERROR occurs 18 times in a row (I included a couple lines before and after the messages for context in case someone familiar with the TC boot process looks at this):
Jul 31 07:21:08 box authpriv.notice sudo: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/chown -R root.staff /usr/local/tce.installed
Jul 31 07:21:08 box authpriv.notice sudo: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/chmod -R 775 /usr/local/tce.installed
Jul 31 07:21:08 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:08 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:08 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:08 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:10 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:10 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:10 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:10 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:10 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:19 box daemon.err udevd[164]: IMPORT{builtin}: 'hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'' unknown /etc/udev/rules.d/65-libwacom.rules:18
Jul 31 07:21:20 box authpriv.notice sudo: root : TTY=console ; PWD=/ ; USER=root ; COMMAND=/bin/tar -C / -zxf /mnt/sda1/tce/mydata.tgz
Jul 31 07:21:20 box daemon.info init: starting pid 6053, tty '/dev/tty1': '/sbin/getty -nl /sbin/autologin 38400 tty1'
All errors are referring to the uncommented line (from /etc/udev/rules.d/65-libwacom.rules) that starts with KERNELS:
# use the /sys/class/input/eventXXX/device/modalias as lookup key, prefixed
# by libwacom:<device name>:
# This lookup key is a contract between the udev rules and the hwdb entries.
# It is not considered public API and may change.
KERNELS=="input*", IMPORT{builtin}="hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'"
It makes me wonder if the comment is correct and whatever this is doing has changed, making this line no longer correct?
So, the messages are now hidden from the boot screen, but are now clearly listed as 18 ERRORS in /var/log/messages. Overall, this is a big improvement, but I would prefer messages that are informational or warnings at the worst when my embedded system boots. The developers may know for certain that these errors are "innocuous" for John Q. Customer almost certainly WILL NOT.
-
You can remove that file (65-libwacom.rules) entirely if you don't have any wacom hardware. Some customization is often expected in deployments.
-
(smiling) Well, you might be able to "just delete the file" but the only copy I can find is on a RAM drive that is restored during a boot, long before I would have any way to delete it.
I assume that you're suggesting that there is a way for me to get into the image used to construct the RAM drive and remove the file from that. At the moment, that is beyond my knowledge and ability. I also seem to have a knack for choosing the wrong keywords to search for on these forums or google (like "how to remove files from TinyCore images", I also tried with "delete" instead of "remove" and many variations.)
So, an explanation or a link to where the instructions to do this are documented would be a huge help!
-
Hi nurbles. Keyword is remaster. Here are my notes on how to do it:
# mkdir $HOME/temp
# cd $HOME/temp
# gunzip -c /path/to/core.gz | cpio -i
-> change things inside $HOME/temp and its subdirs as desired, then return to $HOME/temp
# pwd
/home/tc/temp
# find . | cpio -H newc -o | gzip -9 > ../core-mod.gz
-> Optional step for maximum compression (approx. equivalent to gzip -11):
# advdef -z4 core-mod.gz
-
@GNUser thank you very much for the clear and easy to follow instructions! But I have one concern before I proceed beyond the gunzip command:
When I unzip corepure64.gz, I see pages of errors from the gunzip|cpio command stating things like:
cpio: can't create node /dev/tty5: Operation not permitted
Is it safe to assume that none of those things will be needed in the remastered file (or that they will be magically created by the later steps in your sequence)?
Luckily, I knew about gunzip -k so my original file wasn't deleted! ;)
-
Hi nurbles
These are the commands I've typically used.
Pack/unpack core.gz:
# To unpack
mkdir $HOME/temp
cd $HOME/temp
zcat /path/to/existing/core.gz | sudo cpio -i
# Make your changes.
# To repack
cd $HOME/temp
sudo find . | sudo cpio -o -H newc | gzip > /path/to/new/core-mod.gz
-
When I unzip corepure64.gz, I see pages of errors from the gunzip|cpio command stating things like:
cpio: can't create node /dev/tty5: Operation not permitted
Hi nurbles. I haven't seen these errors before. I run the remaster (unpack/repack) commands as root to avoid problems.
Try remastering as root. If you still encounter errors, I'll defer to someone smarter and more experienced than me to help you further.
-
The wacom rule file is probably in an extension, not in the base (libwacom or xf86-input-wacom probably). Check where with "ls -l". Extensions can be edited with squashfs-tools.
rm -rf squashfs-root # just making sure
unsquashfs foo.tcz
# edit the squashfs-root tree
mksquashfs squashfs-root foo.tcz -noappend
-
You don't need to unsquash, to list files, you just do this to list the files within.
unsquashfs -lls foo.tcz
-
Hi nurbles
It has something to do with hwdb:
https://forum.tinycorelinux.net/index.php/topic,25577.0.html
Our version of udev doesn't include the hwdb builtin:
tc@E310:~$ udevadm test-builtin --help
Usage: udevadm builtin [--help] <command> <syspath>
path_id compose persistent device path
usb_id usb device properties
input_id input device properties
tc@E310:~$Found here:
https://unix.stackexchange.com/a/493797
The wacom rule file is probably in an extension, not in the base (libwacom or xf86-input-wacom probably). ...
It's part of libwacom.tcz and gets pulled in by libinput.tcz.
-
Thanks Rich! I will look for that file and try to remove the rules that should never have been included (since the hwdb builtin is not included, rules that require it shouldn't be include either, should they?)
-
Hi nurbles
... I will look for that file and try to remove the rules that should never have been included ...
I would remove the whole file. Here is why.
The first 6 rules simply exit the rules file:
# udev rules for libwacom supported devices
ACTION=="remove", GOTO="libwacom_end"
KERNEL!="event[0-9]*", GOTO="libwacom_end"
# HUION and GAOMON consumer and system control devices are not tablets.
ATTRS{name}=="* Consumer Control", GOTO="libwacom_end"
ATTRS{name}=="* System Control", GOTO="libwacom_end"
# Match all serial wacom tablets with a serial ID starting with WACf
ENV{ID_BUS}=="tty|pnp", ATTRS{id}=="WACf*", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", GOTO="libwacom_end"
ENV{ID_BUS}=="tty|pnp", ATTRS{id}=="FUJ*", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", GOTO="libwacom_end"
The next rule is the source of the errors:
# use the /sys/class/input/eventXXX/device/modalias as lookup key, prefixed
# by libwacom:<device name>:
# This lookup key is a contract between the udev rules and the hwdb entries.
# It is not considered public API and may change.
KERNELS=="input*", IMPORT{builtin}="hwdb --subsystem=input '--lookup-prefix=libwacom:name:$attr{name}:'"
This rule relies on the previous rule setting a variable, which never runs:
# We can't unset properties through the hwdb but we can set them to zero.
# So let's have a rule that converts the 0 properties to unset ones.
ENV{ID_INPUT_JOYSTICK}=="0", ENV{ID_INPUT_JOYSTICK}=""
This is where the first 6 rules jump to to exit:
LABEL="libwacom_end"
So aside from generating some error messages, the file does nothing.
To remove the file:
tce-load -wil squashfs-tools.tcz
mkdir libwacom
cd libwacom
cp /etc/sysconfig/tcedir/optional/libwacom.tcz .
unsquashfs libwacom.tcz
rm -f squashfs-root/usr/local/share/libwacom/files/65-libwacom.rules
mksquashfs squashfs-root libwacom.tcz -noappend
mv libwacom.tcz /etc/sysconfig/tcedir/optional/
rm -f /etc/sysconfig/tcedir/optional/libwacom.tcz.md5.txt
cd ..
rm -rf libwacom
The md5 file gets removed so the modified libwacom.tcz can't get
replaced if update apps is run.
-
Wow! Thanks Rich! Those instructions worked perfectly and saved hours of searching (and hand wringing while I debated whether my interpretations of what I found was correct!) :)