tinycore 3.2 boot process different from 2.9 ?

[P5music]

Hi,
I would like to know why tc 3.2 stops during boot after the verbose line
"starting udev daemon for hotplug support. Done"
for some seconds.
2.9 didn't so, so a further delay was introduced?
Thanks

[curaga]

At that point there's the init of ramzswap, some modprobes, and waitusb. If you have no waitusb, try an "embed" boot (nozswap from 3.3 onwards).

[P5music]

are there any other options to speed up boot process?

[curaga]

You can skip autodetection of the tce dir by specifying tce=, or skip loading extensions and backup altogether with "base norestore".

[Guy]

I will share an experience I had recently. The problem most likely has nothing to do with Tiny Core, but I will share just in case.

I use a hard drive with several partitions. Each time there is a new version of Tiny Core I install it on a different partition to the previous one. If it does not work properly, I can still use the previous one. This has come in handy in the past, as I have sometimes experimented with making modifications to Tiny Core, and in some cases my modifications have not worked. I use Tiny Core on the other partition to fix it.

I recently installed Tiny Core 3.2. It worked properly.

I then installed Tiny Core 3.3rc2 on another partition.

It booted very slowly. I decided to time it, to be sure, and to see how much slower. The first time I timed it, it was one minute slower. The next time, it was much slower again, and there were some error messages - they did not stay there long enough for me to read. I figured it was some sort of corruption on the hard drive. I booted into Tiny Core 3.2, and it was slower now. I copied all of my personal files to another hard drive.

I decided to repartition the hard drive using Parted Magic, and reinstall on the repartitioned hard drive. Parted Magic was not able to repartition the hard drive. The hard drive must be failing.

I put another hard drive in the computer, partitioned it using Parted Magic, and reinstalled Tiny Core. I am now running Tiny Core 3.3rc2, with no problems.

It seems that the problem was hard drive failure. When I have time, I want to put the faulty hard drive in another computer and try to partition it. Just in case.

I am mentioning this, just in case there is something corrupting the hard drive. It might be incompatible extensions. I am running the same extensions now, with no problems, so this is unlikely.

[gerald_clark]

I also have several versions on my hard drive but I  just use
Ex:
for 3.2 I use the following boot files plus a boot option of  tce=hda/tce-3.2
/boot/TC-3.2/bzImage
/boot/TC-3.2/tinycore.gz

for 3.3 I use the following boot files plus a boot option of  tce=hda/tce-3.3
/boot/TC-3.3/bzImage
/boot/TC-3.3/tinycore.gz

Then I have a grub entry for each version.

[Guy]

P5music

How much slower is it? Enough to be a concern?

Do you use backup, that can make it very slow? You probably already know that.

Can you reproduce this on another computer? Do you have a spare computer to try it on? If you are using a desktop computer, you can just remove the hard drive from the computer, and put it in the other one. There is no need to reinstall Tiny Core. You cannot do this with conventionally installed operating systems.


I have run Tiny Core on a number of different computers. I have noticed, some computers boot much faster than others.

[P5music]

the difference is between 2.9 and 3.2 on the same computer with no difference in backup, extensions or boot option.
the pause is after line
starting udev daemon...hotplug support.Done
it pauses for some seconds, then other verbose messages are displayed as usual, so backup or extensions are not involved, backup is small, extensions are loaded after X starts.
However I had to use 2.9 again with 2.9 extensions because of alsa problems with 3.2.

[tinypoodle]

I have run Tiny Core on a number of different computers. I have noticed, some computers boot much faster than others.

CPU and medium to read from are important factors.

[tinypoodle]

It seems that the problem was hard drive failure. When I have time, I want to put the faulty hard drive in another computer and try to partition it. Just in case.

Running diagnostics first and possibly zeroing it out might be a better choice to be done before even repartitioning.

[u54749]

I had the same pause after "starting udev daemon"

The cause is the "modprobe scsi_wait_scan 2>/dev/null" command in /etc/init.d/tc-config

The goal of this is to wait for the end of SCSi device detection.

If you comment  this out the pause goes away.  You probably will have to remaster TC for this to become persistent.

It works flawlessly here

[curaga]

The issue is, we want to have completed SCSI detection before building fstab. If we didn't, any new devices discovered later would cause a rerun of rebuildfstab, probably being a net loss for total boot time.

Good point though, I see it can be moved inside the fstab check. This would have two effects:
- no such wait on a nofstab boot
- now show a relevant boot message during the wait, ie scanning for fstab. I do see the previous left one thinking why the wait.