I/O dev fd0

[jpeters]

with 1.2.rc2 tinycore.gz: hangs (total 60" +) with several iterations of  "end-request I/O fd0  sector 0  "  and "buffer I/O error device fd0.."  before completing boot on a Dell C610 laptop with no floppy drive. No problem with 1.0. Floppy drive is (correctly) listed as "not installed" in bios. 

[roberts]

Cannot reproduce. Most of my machines have no floppy.

But lets try a few things...

What happens when v1.1 is used ?

What happens with 1.2rc2 booting with nofstab boot option?

[Jason W]

I have noticed these messages too along with the same delay time.  But honestly it never bothered me enough to check into it.  I figured it was maybe something to do with my individual setup.   Most my machines have valid and usable floppies though.  I will look at it some more when I get home to my TC machine and see if I can't locate the issue. 

Versions prior to the latest release candidate did not produce this message or delay.

[curaga]

Hmm.. I've never seen this yet on any machine I have, either with floppy drives or without. I did get a small delay when I added a sata dvd drive, probably because all sata drivers probe it, but that's unrelated.

[jpeters]

works fine with 1.1.   On the Dell, the boot delay with 1.2.rc2 is very noticable with because it hangs over 50 seconds seconds for each for several retries.

edit: same with nofstab.  The only difference is the hang occurs before loading eth0 vs after. 

[MakodFilu]

Are you booting from pendrive?

[jpeters]

Are you booting from pendrive?

no..grub install on hd (Dell c600 doesn't support usb boot)..

[Onyarian]

This is the translation of Beroje's message about this problem in the spanish post.

This occurs during the beginning of "RC2", (last) in previous version no.
"end-request I / O fd0 sector 0"
There is no delay, only displays the message.
If there is a floppy in the drive then don't produces the message, but you will hear some access to floppy.

Hope it can help.

[curaga]

Here's the diff of rebuildfstab from 1.1 to 1.2rc2:

--- reb-1.1   2009-03-08 00:04:59.000000000 +0200
+++ reb-1.2rc2   2009-03-08 00:05:42.000000000 +0200
@@ -68,7 +68,8 @@
       ;;
   esac
 
-  [ -z "$FSTYPE" ] && FSTYPE="$(fstype $DEVROOT/$DEVNAME)"
+# [ -z "$FSTYPE" ] && FSTYPE="$(fstype $DEVROOT/$DEVNAME)"
+  FSTYPE="$(fstype $DEVROOT/$DEVNAME)"
   [ -z "$FSTYPE" ] && FSTYPE="auto"
   MOUNTPOINT="/mnt/$DEVNAME"
   OPTIONS="noauto,users,exec"

Anyone having this problem, could you try to revert this change and see if it helps?

[Jason W]

Yep, that fixed it.

[jpeters]

What do you use to gzip the edited tinycore file? I added the line, but get a kernel panic when I gzip it and cp back to /tinycore.  I tried gzip and gzip -9 with the same freakout result.

[roberts]

That is why I asked about the nofstab option. But it was reported that it failed there.

Note the original does not set the perms or identify pendrive (vfat) properly.
Setting it back to original results in auto for vfat.

But this is why we have RC testing. I will look further. But could not reproduce the fd0 error.

[Jason W]

"Fixed" was a term I used very loosely, meaning there was no more delay but without further diagnosis.  Since I have hardware that is affected by this I will also troubleshoot and see if I can help.

[jpeters]

the correct way to repack edited tinycore is....?

[Jason W]

I have booted with TC-1.1 and my fstab entries for a FAT16 usb key and a fat32 HD partition are as follows:

pendrive:
/dev/sda1       /mnt/sda1       vfat     noauto,users,exec,umask=000 0 0 # Added by TC    

HD partition:
/dev/hdb1       /mnt/hdb1       vfat     noauto,users,exec,umask=000 0 0 # Added by TC

I may be overlooking something, but that is what TC autodetected for my two fat partitions.  Are there other conditions that result in a different result?