Bug#363331: Fwd: Re: Bug#363331: installation-reports
On Wed, Apr 19, 2006 at 12:47:36AM +0200, Frans Pop wrote:
> On Wednesday 19 April 2006 00:12, Digby Tarvin wrote:
> > Actually I should have mentioned that I had tried correcting
> > the syntax in modprobe.d. I had changed /etc/modprobe.d/libata to
> > "options libata atapi_enabled=1"
> > which no longer produces a syntax warning, but I still get
> > "ata1(0): WARNING: ATAPI is disabled, device ignored"
>
> That is weird. Guess you'll need to find expert help elsewhere on this.
> I haven't got a clue why the kernel is ignoring that option. I suggest you
> check the kernel version and google first. I saw you've also written to
> debian-laptop. Maybe ask on debian-user or even debian-kernel.
Ok. I guess the post install situation isn't really your problem
anyway.
> > dmesg also warns:
> > "Kernel command line: root=/dev/hda6 ro libata.atapi_enabled=1"
> > "Unknown boot option `libata.atapi_enabled=1': ignoring"
> > which I assume was added by the install system but the syntax is not
> > supported, so should be removed from my grub menu.lst... should't
> > be doing any harm though...
>
> Yes, should be removed. Will be fixed in a next upload. Thanks.
Done.
> > Also grep'ed through the strings output of libata.ko which seems to
> > confirm that the 'atapi_enabled' option is indeed there, so I am
> > a little puzzled.
>
> One more thing to check is the /proc/<whatever-path-to-device>/settings
> file.
The only 'settings' file in my /proc is /proc/ide0/hda, which I don't think
tells me anything about 'atapi_enabled'..
> > This is presumably related to whatever stopped the install workaround
> > for the beta 2 from working vs the daily build workaround which used
> > the newer kernel command line option..
>
> Could be though others have specifically tested that with Beta 2...
I assume the beta 2 workaround must work on some systems, as I assumed
it would have been tested before being documented.
But the modprobe.d method doesn't work on my system for installation or
post installation, and I think there is a good chance the two issues
are be related.
I'll chase up the post-install problem - which is clearly separate from
the installer, and let you know what I find in case it also pertains to
the beta 2 installer in the same configurations of hardware.
The other issues like UTP not working when installing, but working fine
after install, do seem to be installer specific problems, but I'll
leave it to you to decide if you think it worth persuing further, as
it is no longer a problem for me.
Regards,
DigbyT
P.S. The modprobe.d problem looks very similar to a problem I had with
the audio driver on a different system (Libretto 100CT) a few weeks ago.
The module parameter I needed to make it work just seemed to be being
ignored. I eventually just recompiled the driver with the defaults being
what I wanted, and then everything worked fine - but I suppose that was
a bit of a cop-out. However I can't think of any way that there could
be a problem with module parameter passing which only I have noticed...
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
Reply to: