Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: uggla on June 16, 2011, 02:05:52 PM
-
Hi!
With the latest microcore (3.7) the loading of extensions during boot takes significantly longer time and the hd led is lit steadily during the whole process (with earlier versions it was blinking). Any idea why?
Regards
Uggla
-
I've now upgraded my second computer and that one is even slower (much slower than before).
Here's my onboot.lst:
wbar.tcz
flwm_topside.tcz
laptop-mode-tools.tcz
cpufreq-2.6.33.3-tinycore.tcz
alsa.tcz
flit.tcz
Xorg-7.5-3d.tcz
Xlibs.tcz
Xprogs.tcz
fluff.tcz
/Uggla
-
Note! During the update I updated wbar, Xlibs, Xprogs and fluff as well (the problem could lie there).
/Uggla
-
Possibly caused by the chown, used to detect a read-only fs (but fails on fat32, there's a thread open).
-
I have no fat32 partitions.
-
I really doubt it. As everyone would have noticed a much slower boot and not as claimed only microcore.
That test occurs only once and not upon each extension load. I am however in the process of narrowing the test.
-
Hi uggla
You could take a look at the output of dmesg and see if maybe your hard drive is being put
into PIO instead of DMA mode.
-
To test this properly, set up your computer to boot more than one version.
http://wiki.tinycorelinux.net/wiki:update
Boot it using different versions, with the same apps.
Time the boot with a clock, to see how long it really takes.
I have noticed that loading apps on my computer takes longer than it did before.
This may have started around the time I started using version 3.7.
Around the same time, I also installed additional apps, and I had been thinking those apps were taking longer than the others.
You can test to find out.
-
Hi uggla
You could take a look at the output of dmesg and see if maybe your hard drive is being put
into PIO instead of DMA mode.
I doubt it has anything to do with that since one of my computers has no hard drive at all, it runs from an usb stick.
/Uggla
-
Hi uggla
My answer was based on the information you originally supplied.
-
Hi uggla
My answer was based on the information you originally supplied.
Yes, that was my first computer (with hard drive) ;)
-
This issue remains with 3.7.1 :(
-
What are your comparative test results with 3.6 and 3.7?
-
Where can I get the previous version of wbar, Xlibs and Xprogs?
-
Under 3.x/archive/version/distribution_files.
Any change wrt copy2fs? Enabling it would have this effect.
-
Under 3.x/archive/version/distribution_files.
Any change wrt copy2fs? Enabling it would have this effect.
Not sure what you mean, how can I check this?
-
List the files in your tce dir. If there exists either copy2fs.flg or copy2fs.lst, some or all extensions are copied to ram instead of mounting.
-
Where can I get the previous version of wbar, Xlibs and Xprogs?
go to there http://wiki.tinycorelinux.net/wiki:mirrors
and take a mirror, a lot of mirrors have not update! you can take the old version.
what's about they? just update to 06-07?
2011-06-07 nvidia-texture-tools.tcz nvidia-texture-tools.tcz.info 2011/06/07 - Original
2011-06-06 pinfo-doc.tcz pinfo-doc.tcz.info 2011/05/27
2011-06-06 pinfo.tcz pinfo.tcz.info 2011/05/27
-
I've finally had some progress!
I had neither copy2fs.flg or copy2fs.lst in my tce dir.
When I once again tried mc3.6 I still had the same slow boot as introduced with 3.7. That made me think I've perhaps gone mad or that there's been strange stuff going on with the space time. Then I decided I would test for persistent system settings by renaming my home folder and rebooting with a totally clean home. That did wonders! Boot time is now back to normal (very fast).
Any ideas where to find the cause of this?
-
What is about the size of your backup file? Restoring a large backup may take some time.
-
mydata.tgz = 1,96 KB
-
Hi uggla
You could take a look at the output of dmesg and see if maybe your hard drive is being put
into PIO instead of DMA mode.
Rich,
Am using code you suggested on the forum. Good thinking :)
Along the lines of this thread, Have been making timed bootups, listed below.
HP motherboard, 2.8 GHz speed, 1 GB RAM.
Booting from a USB pendrive, partitioned EXT2 and VFAT32.
Have TCL installed in USB sdb1, with /tce on sdb1 and sdb2.
sdb1 is EXT1, sdb2 is vFAT (of course /tce is internally formated to EXT2).
Found that it is necessary to use the UUID,
otherwise TCL will scan for Hard-Drive installation of /tce (and if there WILL find and LOAD it).
On USB bootup,
Select bootcode (1) in order to load sdb1/tce
Select bootcode (2) in order to load sdb2/tce
Then, start the clock !
(1)
title =1={ TINY-CORE : Rich-TCL ( loads sda1/tce/optional/apps.tcz \n (find(MARK)-kernal(uuid)-initd)
find --set-root --ignore-floppies --ignore-cd /LG-MARK
kernel /tc-sys/bzImage psubdir=/tc-sys quiet waitusb=10:UUID="074e2d15-9ac0-4466-8d4c-9650d908c101" tce=UUID="074e2d15-9ac0-4466-8d4c-9650d908c101"
initrd /tc-sys/tinycore.gz
(2)
title =2={ TINY-CORE : Rich-TCL ( loads sda2/tce/optional/apps.tcz \n (find(MARK)-kernal(uuid)-initd)
find --set-root --ignore-floppies --ignore-cd /LG-MARK
kernel /tc-sys/bzImage psubdir=/tc-sys quiet waitusb=10:UUID="074e2d15-9ac0-4466-8d4c-9650d908c101" tce=UUID="07DB-A20C" TYPE="vfat"
initrd /tc-sys/tinycore.gz
Table of results:
------------------------------------------------------------------------------------
SDB. . . ColorBg. . .Read-USB. . .Load-RAM. . .Load-Ext. . .Exit-Save. . .
.1 Yellow 30s 4s 1 80s
.2 Purple 30s 4s 1 1s
-----------------------------------------------------------------------------------
No complaints, just noting times, along the lines of this thread.
Your bootcode was researched as best as I can.
TCL Docs are terse.
grub4dos docs are not complete.
jackson.lee
-
On reboot after 3.7 install I too experienced this anomaly. The progress bar (if you call it that) never stopped spinning during loading of extensions in fact never completed the boot. This was on a FAT32 drive. Had to wipe the drive, reinstall using ext2. Was able to boot again however have not since been able to install any apps.
But am going to drop in version 3.7.1 to see if this provides a relief to the issue.
-
You can expect filesystem corruption when using fat16 or fat32, and malfunctions as a result.
Use ext2 on usb drives and ext4 on hard drives.
-
Really? oh my! must have been a misread article somewhere, because I would have bet money on reading somewhere that FAT32 was an acceptable format for USB. If not, for sure there is a core wiki which describes installing tinycore to a USB using ext2 with a FAT32 partition for sharing files, this I'm having great trouble with. Whenever the USB drive is plugged into a windows machine the FAT32 partition is unreadable.
Back to the drawing board I guess
-
If you cannot access your fat32 partition from windows, it is probably not really fat32.
The partition flag is just a hint for the OS and does not guarantee filesystem type.
Run a mount command from TC and see what it is mounted as.
-
http://wiki.tinycorelinux.net/wiki:install_with_partition_for_sharing
fat32 is ok for the usb.
It is not ok for the tinycore tce, home, or opt directories.
Some people use fat32, but they are much more likely to experience filesystem corruption.
-
Whenever the USB drive is plugged into a windows machine the FAT32 partition is unreadable.
I seem to remember that windows can only read the first partition on a usb stick, is the fat partition the first one?
-
This is getting stranger.
It seems the more I put into my home/tce directory, the slower extension loading at boot I get. After I realized this I timed my boot, created a new, empty home/tc, and timed once more. The time difference was 13 seconds! What is going on? Do I have to save all my files somewhere else to keep the boot time down? ???
-
That is very weird. What are your bootcodes?
Do you have any custom scripts, or things autostarting?
-
The backup file "mydata.tgz" contains the contents of /home, filtered by /opt/.xfiletool.lst.
If you are storing large amounts of data in /home/tc, your booting will be slowed down.
If you use the home= boot option without modifying /opt/.filetool.lst, Your backup size will
be excessive causing longer boot times.
-
I've now slimmed down my system but the problem remains.
Here are my system settings:
My menu.lst (Grub) entry:
-----------------------------------
title MicroCore
kernel (hd0,6)/boot/bzImage quiet lst=onboot32.lst noutc tz=CET0CEST,M3.5.0/2,M10.5.0/3 tce=sda6 home=sda6 psmouse.proto=imps nodhcp
initrd (hd0,6)/boot/microcore.gz
My onboot32.lst:
-----------------------
Xlibs.tcz
Xprogs.tcz
Xvesa-7.1.tcz
flwm_topside.tcz
My .filetool.lst:
--------------------
opt/bootlocal.sh
opt/bootsync.sh
opt/shutdown.sh
opt/tcemirror
opt/.filetool.lst
opt/.xfiletool.lst
etc/X11/xorg.conf
usr/local/etc/acpi/events/power
etc/profile.d/sun-jre.sh
My bootlocal.sh:
-----------------
#!/bin/sh
# put other system startup commands here
The size of mydata.tgz = 1.81 KB
-
It is not ok for the tinycore tce, home, or opt directories.
I'd like to suggest to correct this: AFAIK VFAT is fine for 'tce' (i.e. storage of the extension files and the backup file) as well as the "boot files" (i.e. the kernel and the initrd), BUT as we all know it should never be used for persistent 'home' or 'opt'.
-
Can you please open a new thread for your little FAT-discussion instead of hijacking this one.
/Uggla
-
Uggla, You should really re-title this topic, as by your own admission, this has nothing to do with v3.7.
Also, you have not posted anything that can be reproduced by anyone. By your own posts this just recently has started. This would likely indicate a hardware failing. Suggest to perform an fsck on your sda6.
-
Uggla, You should really re-title this topic, as by your own admission, this has nothing to do with v3.7.
Ok, done.
Also, you have not posted anything that can be reproduced by anyone. By your own posts this just recently has started. This would likely indicate a hardware failing. Suggest to perform an fsck on your sda6.
I doubt it's caused by hardware failure since it happens on two very different computers. I'll do a fsck none the less and report back. If that doesn't give anything then I'll try to reproduce this issue in Virtualbox.
Regards
Uggla
-
I did a fsck on my sda6:
tc@box:~$ fsck -V /dev/sda6
fsck (busybox 1.18.3, 2011-02-11 12:08:19 PST)
[fsck.ext4 (1) -- /mnt/sda6] fsck.ext4 /dev/sda6
e2fsck 1.41.11 (14-Mar-2010)
/dev/sda6: clean, 59042/3842048 files, 14527049/15340059 blocks
I've tried to replicate this strange behavior in Virtualbox but so far no luck.
I think I'll give it a rest for now.
Regards
Uggla
-
I run microcore + X stuff exclusively and have no such problems.
You might want to check fdisk -l /dev/sda and see if no boundary warnings are displayed.
You should also boot with the showapps boot option to watch as each app is displayed to see which app is taking the most time to load.
And, of course, you can move less frequently used apps to ondemand to really speed up booting.
-
fdisk -l /dev/sda showed no errors/warnings.
I've now removed every extension from my onboot.lst and the problem remains so it can't be caused by loading extensions.
I've removed quiet and added showapps boot options. The beginning of the boot process is executed fast. The delay appears after the "Loading Extensions..." but before "Done." is shown. The end of the boot process is also executed fast. Nothing is printed to the screen during the delay.
Boot message excerpt:
Setting Language to C Done.
Setting Timezone to CET0CEST,M3.5.0/2,M10.5.0/3 Done.
squashfs: version 4.0 (2009/01/31) Phillip Lougher
EXT4-fs (sda6): mounted filesystem with ordered data mode
Adding 4088500k swap on /dev/sda5. Priority:-2 extents:1 across:4
Possible swap partition(s) enabled.
Loading Extensions...
Done.
Setting keymap to us Done.
Restoring backup files from /mnt/sda6/tce/mydata.tgz Done.
I've also tried the noswap boot option but that didn't affect the delay either.
Regards
Uggla
-
Sounds like big backup file as I stated in reply #30.
-
Sounds like big backup file as I stated in reply #30.
But as I stated in reply #31:
The size of mydata.tgz = 1.81 KB
-
Could this be related? (read down, there are several related issues, causing boot up pause, mentioned).
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/595448
-
Hi uggla
If you want to see if the delay is being caused by a piece of hardware add the boot code printk.time=1
Then check the output of dmesg, it will contain timing information. If you want someone else to take a
look then type dmesg > dmesg.txt and attach the file to your next post. You should also mention
which machine it's from, the one booting from a hard drive or USB drive.
I would also like to point out that your USB machine will most likely boot slower than the one booting
from a hard drive due to USB's lower throughput.
There is one other piece of information you should provide, what is your definition of slow. Could you
please state how long the delay is? I may have missed it but I did not see it mentioned.
-
I've now added the bootoptions loglevel=7 and printk.time=1. No dmesg messages are printed during or after the delay. The last lines written are (still):
[ 7.466509] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 8.005379] EXT4-fs (sda6): mounted filesystem with ordered data mode
Se my full dmesg.txt attached. Testing is done on my computer with hard drive. The delay on a totally clean microcore install, with 31 GB in /home/tc, is about 10 seconds compared to when the /home/tc is wiped clean.
Regards
Uggla
-
Hi uggla
While not the answer to the problem, there is a 3 second delay searching for a non-existent floppy.
Adding the boot code floppy=0,irq will eliminate that and may ease the pain a little.
Just a shot in the dark. Does etc/profile.d/sun-jre.sh run on startup? If it does, what happens if you
disable it?
-
Thanks for your suggestions.
I didn't notice any difference after adding the boot code floppy=0,irq though. etc/profile.d/sun-jre.sh doesn't run at startup but I have it in my .filetool.lst. Removing it from the .filetolls.lst didn't affect the boot speed either.
-
I'm starting a new project where I will boot a generic pc from a usb stick which will be its only storage device. I'm setting up the new USB stick on a different pc, one which I regularly boot from my primary boot USB stick (and in fact the new USB stick is, at this point, (functionally) a copy of my primary boot USB stick).
The primary USB stick, which works just fine, is an HP v125w 4GB, partitioned as one partition which is formatted FAT32 and using grub4dos to boot tiny core or micro core 3.7.1. Only /boot and /tce are accessed from the stick during boot (no persistent /usr, /home or /opt).
The new USB stick is a brand new PNY Attache` "mini" set up the same way. When booting from this new stick, TC hangs when trying to load the onboot extensions. I didn't wait around for more than a couple of minutes to see if it would continue. If I boot with the base and norestore boot codes, it boots up (but is not particularly useful as the target machine will be running headless with only ssh access).
I'm checking the install to make sure I didn't do something stupid. If not, then the next steps will be
1) redo the install from scratch - maybe even follow the instructions
2) redo the install from scratch using ext2
3) additional troubleshooting as required
Edit - 06/28/2011:
I skipped step 1 above and went straight to step 2 (using ext2) and it boots nicely and loads extensions. I'll still need to get to the root of the issue, as I simply don't want to be locked out of using a standard FAT USB stick, even though it doesn't matter for the current project.
-
I've now made opt persistent (and edited .filetool.lst), but the issue remains.
How can I log udevd?