[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Pkg-sysvinit-devel] Bug#510367: initscripts: checkfs.sh runs before /etc/modules processed



On Sat, 2018-12-29 at 18:34 +0000, Dmitry Bogatov wrote:
> control: tags -1 +moreinfo
> 
> [2009-01-05 13:34] Arthur Marsh <arthur.marsh@internode.on.net>
> > Petter Reinholdtsen wrote, on 2009-01-01 21:14:
> > > [Arthur Marsh]
> > > > After manually observing a reboot, it appears that although module
> > > > eata is successfully loaded before filesystems are checked, the
> > > > device files for the SCSI disk are created asynchronously, in my
> > > > case after the filesystem check script has attempted to check the
> > > > filesystems on the SCSI disk.
> > > 
> > > Right.  So you have been hit by the introduction of asynchronous
> > > behaviour of the Linux kernel.  I have no good idea how to solve it.
> > > We need to make the early boot system asynchronous too to avoid such
> > > problems.  It also affect USB disks and other busses with slow
> > > discovery process. :(
> > > 
> > > Happy hacking,
> > 
> > Would this behaviour be changed by changing from
> > 
> > CONFIG_SCSI_SCAN_ASYNC=y
> > 
> > to:
> > 
> > CONFIG_SCSI_SCAN_ASYNC=n
> > 
> > in the kernel configuration?
> 
> Dear maintainers of linux, could you please take a look at this issue?
> Is there any smart way to wait for this asyncronous behaviour?

It's not generally possible to wait for asynchronous scanning to
complete, because for USB there is no time limit for devices to appear.

You should either poll for the required devices to appear at regular
intervals, or use a udev hook to react to their appearance.  In either
case there should be a configurable timeout or some way to break out
and attempt a manual recovery from the missing device.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                          - John Lennon

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: