Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: jpeters on March 07, 2009, 02:17:06 AM
-
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.
-
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?
-
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.
-
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.
-
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.
-
Are you booting from pendrive?
-
Are you booting from pendrive?
no..grub install on hd (Dell c600 doesn't support usb boot)..
-
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.
-
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?
-
Yep, that fixed it.
-
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.
-
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.
-
"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.
-
the correct way to repack edited tinycore is....?
-
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?
-
The remastering section of the wiki has the instructions for unpacking and packing tinycore.gz as well as making the iso image.
Those instructions work without modifications for me.
-
Geez...no wonder. I was editing a gunzipped tinycore! ..completely forgot about the cpio thingy!
edit: applying curaga's changes (if I understood it correctly...+ meaning add the line) didn't change anything....still hung up the same way.
-
I believe it was the sd card. A user was having issues with Aspire One with an sd card.
I tested on Dell Mini 9 and eeePC 900A and saw the issue and tried to respond.
-
I believe it was the sd card. A user was having issues with Aspire One with an sd card.
I tested on Dell Mini 9 and eeePC 900A and saw the issue and tried to respond.
Sounds like what the FED has been doing, and look at the mess THAT has created.....
-
JP - I know that was meant as a good natured joke, but let's not discount Robert's time spent on TC. :)
As for the fd0 issue, sd cards are a way of the future and floppies are a thing of the past. It would not hurt my feelings if we went with supporting sd cards and eventually fixed the floppy issue in time. I only wish I had an sd card to test with. Looking around they seem to be cheap enough, and available with a usb interface. I will try to get one this afternoon and see if I see the same sd card issue and help find a solution if I can since I would then have both floppy and sd card.
-
JP - I know that was meant as a good natured joke, but let's not discount Robert's time spent on TC. :)
It's beyond me how you read any implication of discounting Robert's time into that comment.
Note: It's very easy to react to immediate problems that create other problems. Fortunately Robert knows what he's doing. In the case of the FED, I'm not so sure.
-
I do not disagree with the political view mentioned. But that is a different discussion.
What I saw was a comparison of Robert's involvement in the sd/fd0 situation to meddling.
You reacted, I reacted, so let's call it even and leave it there.
-
Glad that the fd issue is resolved.
As for sd cards (mmcblk devices). they like usb are slow to fully register.
Once modprobed sdhci, the fstab entry is created with auto instead of vfat
auto is the default when the fstype cannot be determined.
But a simple sed -i '/mmcblk/d' /etc/tstab && rebuildfstab corrects to vfat which would indicate a timing issue.
-
congrats.....
Robert for pres!
What I saw was a comparison of Robert's involvement in the sd/fd0 situation to meddling.
Interesting...I hadn't thought about that... :D
-
JP - I hope no hard feelings, I was defensive since I misread you. I am usually happy in this hundred acre wood (or ten megabyte wood) but I can get a little bearish at times.
I did get a sd card that connects via usb but it shows up as sda1 since it is a usb interface, so it gets put in fstab ok. Was hoping to help test both the floppy and sd support but oh well.
-
JP - I hope no hard feelings, I was defensive since I misread you. I am usually happy in this hundred acre wood (or ten megabyte wood) but I can get a little bearish at times.
..none...The comment was kindof OT anyway, which probably comes from reading too much. Fortunately, wind surfing season has just begun, which should help....
BTW, I'd be happy to test out any revisions on my Dell, since nobody else seems to be experiencing the long delays.
-
I'd be happy to test out any revisions on my Dell, since nobody else seems to be experiencing the long delays.
nice to see milne quoted here :) this box has a floppy, i know roberts is in a hurry to get to 1.2 final, but if i have 24 hours from now i promise to try rc2 on here. if i understand the problem is a very inconvenient 50 second delay (when tc has us used to a fast boot.) from reading i believe there's a fix i can try to see if that works? the promise is about trying rc2, not the fix, but i may try it also.
-
BTW...Curaga's revision did work on my DELL....I didn't understand the "revert + - " lingo, so did it wrong until I compared the two files myself and got what he was talking about.
-
If the diff (patch) file is confusing or you just don't have patch installed then,
I had only commented out the original line (line 71) therefore the simple fix is just to uncomment line 71 and comment or delete line 72.
-
got it working, but didn't see a patch ...
-
got it working, but didn't see a patch ...
other page: http://forum.tinycorelinux.net/index.php?topic=706.msg4326#msg4326
-
That's what I used. I thought Robert had another fix, given:
Note the original does not set the perms or identify pendrive (vfat) properly.
-
oh, i took that to mean that the line 71 version didn't have that feature, but the line 72 version does.
the patch, if i followed the post, has the same effect as commenting line 72 and uncommenting line 71, but it also disables the new vfat handling. (how perms are set in vfat is beyond me.)
-
the patch, if i followed the post, has the same effect as commenting line 72 and uncommenting line 71, but it also disables the new vfat handling. (how perms are set in vfat is beyond me.)
Robert just clarified what Curaga posted. I guess whatever else needs to be done (vfat handling, etc) is in the works.
[^thehatsrule^: fixed whitespace]
-
i tried 1.2 rc2 on a machine with floppy. it displayed the error but no delay.
-
You unpacked tinycore.gz and fixed /usr/sbin/rebuildstab, right? AFAIK the error doesn't happen with ver 1.1.
-
You unpacked tinycore.gz and fixed /usr/sbin/rebuildstab, right? AFAIK the error doesn't happen with ver 1.1.
no, i ran 1.2rc2 (unmodifed, a7991bf39f879842b50d97052488c8b7) on a machine with a floppy.