Bug 372199

The same on my X32, but it's more like 30 seconds.

[   10.140698] intel8x0: clocking to 48000
[   19.658651] end_request: I/O error, dev fd0, sector 0
[   32.647481] end_request: I/O error, dev fd0, sector 0
[   32.647481] Buffer I/O error on device fd0, logical block 0
[   45.638170] end_request: I/O error, dev fd0, sector 0
[   45.638170] Buffer I/O error on device fd0, logical block 0

It's probably something in userspace trying to probe the non-existent floppy.

But OTOH, WHY ARE WE SHIPPING A BUILT-IN FLOPPY DRIVER? Is somebody really suggesting that one might have the root fs on a floppy and thus the floppy module must be built in? And why are all the other storage drivers not built into the kernel?

So i'd really suggest making that CONFIG_BLK_DEV_FD=m ...

I think the problem is you can not dynamically probe for floppy drives at boot time to know to load the module or not.

What is trying to access the floppy drive?  That seems like a bug somewhere in either the hardware (it's reporting that there is a disk there, but it isn't accessible).

Is this after init starts, or before?

In my case it is after loading the sound module and before activating swap.

So i'd guess it is some part of the hunk of cr^W^W^Wlovely stack of well designed software called "udev and friends".

Can i suppress the creation of /dev/fd0 with an udev rule? this would probably "fix" the issue.

BTW: per default never loading the floppy module (because it cannot be probed) would be a good idea since it would surely save a few kilobyte on every machine out there. Nobody is using floppies anymore. At least i hope so ;-)

I kind of doubt udev is here, as it only does the loading of the modules, and this is a built-in code.  Someone is trying to access fd0, which is causing the problem.

A lot of different services get started at boot between udev and swap, can you try to narrow it down to the real problem?

It might get autoloaded by "pnp:dPNP0700". What does:
  grep . /sys/bus/pnp/devices/*/id
print?

You can try to disable the floppy in the BIOS of the laptop.

Btw, on x86_64, it is a module:
  grep BLK_DEV_FD /boot/config-2.6.25-rc5-git3-6-default
  CONFIG_BLK_DEV_FD=m

so 32bit should do the same, I guess.

In reply to Comment#2; Same as Comment#3

Disabling the floppy in BIOS works around the issue.

Still:

root@susi:/# time cat /dev/fd0
cat: /dev/fd0: Input/output error

real    0m39.214s
user    0m0.000s
sys     0m0.004s

There is no hardware, why do we wait 40 seconds before we recognize that?

*** Bug 380639 has been marked as a duplicate of this bug. ***

This (at least in it's incarnation as Bug #380639) is a regression,
not an enhancement request.

Created attachment 208960 [details]
boot.msg booted with with floppy=debug

hits me on beta1. The delay during boot is not just a few seconds.

Still there in Factory :-(

interestingly enough this doesn't happen after installation from the live cd so the resulting installed system there must be doing something different.

I'll blame yast then :)

Live CD (and thus installed system) was missing several boot scripts,
e.g. device-mapper and crypto. Coolo, can you give the complete list?

I removed this chunk:

-# Deactivate services
 #--------------------------------------
-suseRemoveService boot.multipath
-suseRemoveService boot.device-mapper
-suseRemoveService mdadmd
-suseRemoveService multipathd
-suseRemoveService rpasswdd
-suseRemoveService boot.scsidev
-suseRemoveService boot.md
-suseService boot.rootfsck off

Not sure anything of that is floppy related

Please set PROMPT_FOR_CONFIRM="yes" in /etc/sysconfig/boot to see
which start script takes so long.

boot.udev

I'll blame udev then :)

Please disable the floppy in the BIOS setup menu of the box. There is no simple way to detect if the enabled floppy controller has a drive connected.

Btw, why is the floppy is compiled in for 32bit kernels? We can not even blacklist the module, which would be good.

Yes, I am disabling the floppy but it can hardly be desired to have it like this. We didn't have the issue with 10.3.
I actually see the same issue (even though "only" for ~5 seconds) on a Desktop machine with floppy drive.
Not sure why I'm set to needinfo again?

What about adding something like
/bin/openvt -s -c 11 -l /bin/bash
to the top of /etc/init.d/boot.udev?
Maybe you can find out whether and which process is accessing /dev/fd0 causing the timeouts this way.

What does:
  /sbin/udevadm test /block/fd0
print?

It takes 36 seconds and this is the result;

This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

parse_file: reading '/etc/udev/rules.d/40-alsa.rules' as rules file
parse_file: reading '/etc/udev/rules.d/40-bluetooth.rules' as rules file
parse_file: reading '/etc/udev/rules.d/40-suse.rules' as rules file
parse_file: reading '/etc/udev/rules.d/40-zaptel.rules' as rules file
parse_file: reading '/etc/udev/rules.d/41-soundfont.rules' as rules file
parse_file: reading '/etc/udev/rules.d/50-udev-default.rules' as rules file
parse_file: reading '/etc/udev/rules.d/51-lirc.rules' as rules file
parse_file: reading '/etc/udev/rules.d/55-libsane.rules' as rules file
parse_file: reading '/etc/udev/rules.d/56-idedma.rules' as rules file
parse_file: reading '/etc/udev/rules.d/56-sane-backends-autoconfig.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-cdrom_id.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-input.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-storage-tape.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-storage.rules' as rules file
parse_file: reading '/etc/udev/rules.d/61-persistent-storage-edd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/64-device-mapper.rules' as rules file
parse_file: reading '/etc/udev/rules.d/64-md-raid.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-kpartx.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-net.rules' as rules file
parse_file: reading '/etc/udev/rules.d/75-cd-aliases-generator.rules' as rules file
parse_file: reading '/etc/udev/rules.d/75-persistent-net-generator.rules' as rules file
parse_file: reading '/etc/udev/rules.d/77-network.rules' as rules file
parse_file: reading '/etc/udev/rules.d/80-drivers.rules' as rules file
parse_file: reading '/etc/udev/rules.d/90-hal.rules' as rules file
parse_file: reading '/etc/udev/rules.d/95-udev-late.rules' as rules file
parse_file: reading '/etc/udev/rules.d/99-pcsc_lite.rules' as rules file
import_uevent_var: import into environment: 'MAJOR=2'
import_uevent_var: import into environment: 'MINOR=0'
import_uevent_var: import into environment: 'DEVTYPE=disk'
udevtest: looking at device '/devices/platform/floppy.0/block/fd0' from subsystem 'block'
run_program: 'edd_id --export /dev/.tmp-2-0'
run_program: '/lib/udev/edd_id' returned with status 5
udev_rules_get_name: no node name set, will use kernel name 'fd0'
udev_db_get_device: found a symlink as db file
udev_device_event: device '/devices/platform/floppy.0/block/fd0' already in database, cleanup
udev_node_add: creating device node '/dev/fd0', major=2, minor=0, mode=0640, uid=0, gid=19
udevtest: run: 'create_floppy_devices -c -t 4 -m 2 -M 0640 -G floppy /dev/fd0'
udevtest: run: 'socket:/org/freedesktop/hal/udev_event'
udevtest: run: 'socket:@/org/kernel/udev/monitor'

Is it hanging for several seconds while running udevadm test? Maybe at the edd_id program?

Same here, except that it takes two minutes. edd_id is the one that takes so long, yes. But this does not happen during boot in this livecd based installation here.

Created attachment 216368 [details]
new edd_id rules

If you replace:
  /etc/udev/rules.d/61-persistent-storage-edd.rules
with the attached, does it fix it?

Submitted a new package which runs edd_id only for sd* and hd* disks. I hope this fixes it.

*** Bug 384081 has been marked as a duplicate of this bug. ***

Ludwig, can you please try?

The livecd based installation I am currently using does not have the problem.

Package was checked in.