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

Re: 2.6.14 status summary, and upcoming 2.6.15 ...



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 28 Nov 2005 11:21:45 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> On Mon, Nov 28, 2005 at 04:12:34AM +0100, Jonas Smedegaard wrote:

> > Ah, so it is same thing as your earlier request for filing
> > bugreports against linux-2.6 for each unknown hardware combinations
> > and have the ramdisk tools close those as the hardware gets tested.
> > I cannot do that task: It is a too big job for me!
> 
> Nope, i am asking you for a few lines of situation report of yaird,
> is that so difficult ?

No, that's tedious - difficult part was to understand your request :-)

The following problems are known for yaird currently in sid:

 * Does not work on alpha and ia64.
 * Needs test on arm, hppa, m68k, mips, mipsel and sh.
 * Possibly works after manual editing config files on s390.

 * Does not work with EVMS, loopaes, IEEE1394, dmraid and swsusp.
 * Works after manual editing config files with rootfs on NFS and
   (badly!) with swsusp2.
 * fstab labels works only on ext2 and reiser.
 * crypsetup-luks not tested recently.
 * Needs test with usb-stick.
 * Works only with drivers supporting sysfs.

This is all from the wiki page[1], which has more details for some of
of the items.


> > So if workarounds like "the driver for your hardware is currently
> > too limited for automated recognition using yaird, so you need to
> > manually edit the config file for your hardware to work, or try
> > initramfs-tools" is considered "left out in the cold" then
> > bug#328534 is a showstopper. And it would require a big chart of
> > bug#all kernel modules for harddisk
> > controller (for each arch?) to make sure that no user would be left
> > in such situation.
> 
> Well, do we have a workaround ? I mean, people will apt-get upgrade
> and automatically get yaird and the 2.6.14 kernel pulled in,

We do not have _automated_ workarounds, which it seems you imply and I
clearly didn't above.


> not only will the next reboot not work, but possibly there will be no
> way to bring the box alive again.

Well, for yaird I believe most errors causes the kernel installation to
fail.

Only yaird problem I know of leading to problems booting (and brick'ing
if using bootloaders with no alternative) is with drivers that does not
support sysfs. We do not have an overview of the size of that problem.

Can someone dig out such info from the kernel source itself? Or perhaps
on the net somewhere is a status page of driver sysfs support?


> If there is a workaround, we could put out a errata list of the
> problems and possible workarounds and stuff.

...that's what Erik wants to do as well for the non-sysfs supported
hardware. I am not ahead of him, and I don't think such list exist yet.


> we really need a way to automatically set yaird to initrd on
> ia64, maybe by a postinst editing Templates.cfg or something ? 

I believe we really need ia64 to support initramfs, no?


 - Jonas


[1] http://wiki.debian.org/InitrdReplacementOptions

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDiu3mn7DbMsAkQLgRAkfmAJ4q0rqqpMLwK7xO4UOx8qncOzMhywCeNgyA
8KphewWHk8IiUIJ5V45qWm0=
=+CXQ
-----END PGP SIGNATURE-----



Reply to: