Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: Misalf on October 15, 2013, 12:38:23 PM
-
I'm noticing a big delay of ~24 seconds at boot.
It's about TC 5.0 .
This did not happen with TC 4.7.7 where I had an even bigger onboot list.
The message "Loading extensions..." is shown but extensions seem to not get loaded at that point.
After said amount of time, each extension from my onboot.lst + deps are shown and boot continues as usual.
I thought my nearly filled 10GB ext3 partition could be the cause so I created a seperate .gz with all extensions I had OnBoot and added that to my boot loader so those extensions can be found quicker during TC's boot process.
Indeed, when the message "Loading extensions..." is shown if I boot that way (extensions in /tmp/), all those extensions get listed immediatly but that delay of ~24 seconds still happens then just after the last extension from my custom .gz is shown; even though the onboot.lst in my tce-dir is totally empty.
I switched back to not loading .tcz via custom .gz OnBoot.
onboot.lst:
Xorg-7.7-lib.tcz
Xorg-7.7-bin.tcz
numlockx.tcz
aterm.tcz
nano.tcz
kmaps.tcz
fltk-1.1.10.tcz
fox.tcz
alsa.tcz
retrovol.tcz
dejavu-fonts-ttf.tcz
hicolor-icon-theme.tcz
openbox.tcz
tint2.tcz
wbar.tcz
conky-1.9.tcz
ipager.tcz
geany.tcz
xfe.tcz
viewnior.tcz
Thanks for any input.
Cheers.
-
Hi Misalf
You could add:
printk.time=1 syslogboot codes. Then reboot and check the timestamps in /var/log/messages to see where the delay is.
-
Thanks
Before sda4 gets mounted, 651 entries are listed all at the same second (14:34:41).
I guess the fact that it's changing from 14 o'clock to 16 o'clock is timezone related(?).
Oct 16 14:34:41 box user.info kernel: [ 2.833942] hid-generic 0003:046D:C01D.0002: input,hidraw1: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.0-2/input0
Oct 16 14:34:42 box user.info kernel: [ 3.526407] Adding 1048572k swap on /dev/sda2. Priority:-1 extents:1 across:1048572k
Oct 16 14:34:42 box user.info kernel: [ 3.561339] EXT4-fs (sda4): mounting ext3 file system using the ext4 subsystem
Oct 16 14:34:42 box user.info kernel: [ 3.577341] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
Oct 16 16:35:07 box auth.notice su: + /dev/console root:tc
Oct 16 16:35:07 box authpriv.notice sudo: tc : TTY=console ; PWD=/mnt/sda4/boot/tce-5.0/optional ; USER=root ; COMMAND=/bin/mkdir -p /tmp/tcloop/libXdmcp
Oct 16 16:35:07 box authpriv.notice sudo: tc : TTY=console ; PWD=/mnt/sda4/boot/tce-5.0/optional ; USER=root ; COMMAND=/bin/busybox mount libXdmcp.tcz /tmp/tcloop/libXdmcp -t squashfs -o loop,ro,bs=4096
I don't see another huge delay so it seems to me that my partition has to be dificultly convinced to get mounted at each boot.
Gparted and Xfe are telling me its an ext3 partition.
Should I care about the message
"... using the ext4 subsystem"
and/or
"... with ordered data mode. Opts: (null)"
?
The partition has been created using Mint 13 or 14 installer and that's still there.
Does it matter for the time needed to mount how big the drive/partition is and how much data is stored / free space is available?
-
What kind of drive is sda?
-
80 GiB SATA HDD
-
If I add base boot code (boots super fast) and issue mount /mnt/sda4 after boot, mounting happens without delay.
I'm currently trying to decipher process_normal_tcedir() from /usr/bin/tc-setup.
-
Show us the output of showbootcodes.
-
I made a custom gz. containgin only /usr/bin/tce-setup with some added echoing.
At line ~40 the delay happens (sync):
chown -R "$USER".staff "$TCEINSTALLED"
echo -n "DEBUG: ${RED}sync${NORMAL}..."
sync
echo " ${RED}synced${NORMAL}."
[ "$MOUNTPOINT" == "/tmp" ] && return
It shows:
"DEBUG: sync..."
here is the delay - until it shows:
"DEBUG: sync... synced."
--
showbootcodes:
BOOT_IMAGE=(hd0,msdos4)/boot/tce-5.0/boot/vmlinuz tce=UUID=8c2df35e-1348-4638-93f9-01756f723f9d/boot/tce-5.0 logo.nologo loglevel=3 showapps nozswap nodhcp desktop=openbox kmap=qwertz/de-latin1 noutc tz=CET-1CEST,M3.5.0,M10.5.0/3 video=vesa pause
-
I have been experiencing long sync delays also on some machines.
This makes using RAID 1 and LVM almost impossible.
-
):
Could I replace busybox' sync with another one or might the delay more likely be caused by my drive/machine?
-
I don't know what is causing the long sync. The same machines with 4.7 are fine.
-
replacing sync from busybox with the one from coreutils had no different effect.
-
Try to increase loglevel to 7.
-
Found it:
https://code.google.com/p/chromium/issues/detail?id=240411
http://lkml.org/lkml/2013/7/12/257
Would've been nice to catch this during the RCs, but cest la vie. We'll need to schedule a kernel update.
edit: gerald_clark and Misalf, could you test whether that patch on top of our current kernel fixes your issue?
-
I'm trying to compile the kernel based on instructions from here:
http://wiki.tinycorelinux.net/wiki:custom_kernel
I hope I have pasted the correct content into the file I used to patch the kernel source.
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index a85ac4e..d0d70a8 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1055,10 +1055,8 @@ void wakeup_flusher_threads(long nr_pages, enum wb_reason reason)
{
struct backing_dev_info *bdi;
- if (!nr_pages) {
- nr_pages = global_page_state(NR_FILE_DIRTY) +
- global_page_state(NR_UNSTABLE_NFS);
- }
+ if (!nr_pages)
+ nr_pages = get_nr_dirty_pages();
rcu_read_lock();
list_for_each_entry_rcu(bdi, &bdi_list, bdi_list) {
I was able to proceed up to
9. Do “make modules” to build the loadable modules
A few warnings but no errors.
Now I'm not sure what path to insert for /path.
10. Do “make INSTALL_MOD_PATH=/path modules_install firmware_install” where /path is a path to a directory where you expect to find the modules.
[...]
Further you will find all loadable modules and firmware files under ”/path/lib/modules/kernel_version” and ”/path/lib/firmware”
The foler
/usr/src/linux-3.8.10/lib/modules/'kernel_version'does not exist.
There is a folder called
/usr/src/linux-3.8.10/.tmp_versionwhich contains about 2038 .mod files.
Is that the folder in question? I have no idea if it has just been created by 'make'.
Would it be correct to replace /path like this?
make INSTALL_MOD_PATH=/usr/src/linux-3.8.10/.tmp_version modules_install firmware_install
-
Since you're only changing core code, the instructions are much simpler than for a full custom kernel.
1. Unpack source, copy config file into it (.config), apply the new patch
2. make bzImage
3. Copy arch/x86/boot/bzImage into your boot folder
4. Point your bootloader to this new bzImage instead of the shipped vmlinuz
-
Wohoo - Success!
The patch does work. No delay at all.
Total amount of time needed to boot into a desktop is now 29 seconds (according to conky) which is about the half of the time that was needed before.
Thanks.
--
PS:
Do I need to apply the patch on the sources if I want to compile something else which depends on linux headers etc.?
-
The patch also works for me.
I have 4 mdadm RAID 1 drives and boot time was reduced from 23 minutes to less than 2 minutes.
I was debugging my pretce raid scripts when this topic caught my attention.
I am happy to report that the TC4 mdadm.tcz works fine with TC5.
-
mdadm coped over
-
Thanks for testing. We'll be including this patch in 5.1.
Do I need to apply the patch on the sources if I want to compile something else which depends on linux headers etc.?
No, it does not change the module interface, so external modules can use the unmodified source/headers extension (if there is any).