Bug#685186: IA64 (Itanium) Wheezy, ELILO installation failed, patch proposal
I'm surprised that I could shock you with the severity level :-).
The bug prevents the script from installing ELILO on the EFI System
partition (ESP) when a user attempts to install Debian with a Debian
installation CD or DVD.
The user won't be able to workaround this on an opened console if he
isn't very familiar how to install ELILO manually including writing
the appropriate ELILO configuration.
The bug occurs *always*.
The bug occurs on *any* ia64 machine.
With this bug the Debian installer won't bring up a bootable system.
What means: it renders *any* ia64 Debian installation CD or DVD useless.
Actually you can stop building ia64 iso images unless this bug is fixed!
So what severity level is the right one for that?
Debian's "Information regarding the bug processing system for package
maintainers and bug triagers" [1] states:
"grave
makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the
accounts of users who use the package."
I think "makes the package in question unusable" is true for this bug.
The severity what you suggest is:
"important
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone."
This is not true for the bug. This wouldn't be a release critical bug either.
My conclusion is that the bug should be a release critical one because
it renders the ia64 iso images useless for everyone: Grave.
The problen is that the debian/elilo.sh script fails to mount the
(FAT) EFI System partition (ESP) because the nls_iso8859-1.ko module
is absend.
The question is what package we can blame for that:
1. kernel-image-3.2.0-3-itanium-di
It builds two kernel images (Itanium, McKinley) and some udebs which
are needed for the Debian installer. The
fat-modules-3.2.0-3-itanium-di_3.2.23-1_ia64.udeb is one of them.
2. elilo
The mentioned debian/elilo.sh belongs to this package.
In my opinion you can say that the
fat-modules-3.2.0-3-itanium-di_3.2.23-1_ia64.udeb lacks the
nls_iso8859-1 module, so debian/elilo.sh is not able to do its work.
Since fat-modules-3.2.0-3-itanium-di_3.2.23-1_ia64.udeb is build by
the kernel-image-3.2.0-3-itanium-di package, the bug should be
assigned here.
Julien Cristau wrote:
< bwh> 'iocharset=iso8859-1' is a bug; Linux standard character encoding
is UTF-8
< bwh> for filenames, at least
< bwh> So, assign to whatever contains the debian/elilo.sh script
I think mounting FAT using UTF-8 isn't wise at all. debian/elilo.sh is
perfect since it specifies the right charset.
If you would change the script to use UTF-8 (explicit or implicit by
the default), you would make things worse.
I don't want to start a discussion about the UTF-8 default for FAT
here but you can read, for example, in the "Using UTF-8 with Gentoo"
[2] of the Gentoo project:
"You should avoid setting Default iocharset for fat to UTF-8, as it is
not recommended."
The reason is that you will experience 'glyphed' characters in
filenames when you exchange FAT volumes with Windows when you mount
FAT using UTF-8 on Linux. Since the user would run into trouble, using
UTF-8 for FAT isn't wise. Older Linux kernels report a warning message
when you mount FAT with UTF-8.
So assigning the bug to the elilo package would be wrong.
The kernel-image for normal operation has iso8859-1, why the kernel
for the installer shouldn't have it either?
The only mistake I have made was:
"affects 685186 elilo-installer".
It should have been
"affects 685186 elilo".
I think the discussion about severity levels of bugs is academic. Ones
could have different opinions about that.
Much better would be fixing the bug since it is a real show stopper.
It is just a change of one code line...
Stephan
[1] http://www.debian.org/Bugs/Developer.en.html
[2] http://www.gentoo.org/doc/en/utf-8.xml#doc_chap3
Reply to: