Bug#685186: IA64 (Itanium) Wheezy, ELILO installation failed, patch proposal
 

tags 685186 + moreinfo
# letting version tracking do its work
tags 685186 - wheezy
# if I understand correctly, it is still possible to use the kernel on
# itanium, so the package is not unusable
severity 685186 important
quit

Hi,

Julien Cristau wrote:
> On Sun, Aug 19, 2012 at 17:07:00 +0200, Stephan Schreiber wrote:

>> The failed command is in debian/elilo.sh:
>>
>> fstype=vfat
>> ....
>> mount -t "$fstype" -o
>> codepage=437,iocharset=iso8859-1,rw,noexec,umask=077$loop "$boot"
>> "$TMP/bootstrap.$$"
>> what is perfect to mount an EFI system partition - much better than UTF-8.
[...]
> < 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

On Wednesday, Stephan Schreiber wrote:

> tags 685186 + patch
> reassign 685186 kernel-image-3.2.0-3-itanium-di
> affects 685186 + elilo-installer
> severity 685186 grave
> tags 685186 + wheezy

Could you say a little more? Where did Ben and Julien go wrong in the
previous analysis?

Thanks,
Jonathan


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20121008231237.GA2452@elie.Belkin

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121009210946.Horde.lzYUJUlCcOxQdHZ6spc3GJA@webma il.df.eu">http://lists.debian.org/20121009210946.Horde.lzYUJUlCcOxQdHZ6spc3GJA@webma il.df.eu

Bug#685186: IA64 (Itanium) Wheezy, ELILO installation failed, patch proposal
 

Stephan Schreiber wrote:

> 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.

So the next step is either to convince Debian's kernel maintainers
that it is worth including that module in the installer, or the elilo
maintainers that debian/elilo.sh should not use iocharset=iso8859-1,
or both.

[...]
> I think mounting FAT using UTF-8 isn't wise at all.

In general, for what it's worth I disagree about that, but I wouldn't
be surprised if there are other considerations in this particular case
(if so, what are they?).

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20121009195508.GB3993@elie.Belkin

Bug#685186: IA64 (Itanium) Wheezy, ELILO installation failed, patch proposal
 

On Tue, Oct 09, 2012 at 09:09:46PM +0200, Stephan Schreiber wrote:
[...]
> 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.
[...]

The encoding used *on disk* is always UCS-2 for VFAT long names and
is controlled by the 'codepage' option (default = cp437) for short
names.

The 'iocharset' option controls the encoding that userland sees, which
should be UTF-8 for all filesystems under Linux, no exceptions, and
definitely not dependent on locale (which the kernel doesn't know
anything about). I realise this is not the default, but that's an
historical accident.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121009204230.GP13292@decadent.org.uk">http://lists.debian.org/20121009204230.GP13292@decadent.org.uk

Bug#685186: IA64 (Itanium) Wheezy, ELILO installation failed, patch proposal
 

On Tue, Oct 09, 2012 at 09:09:46PM +0200, Stephan Schreiber wrote:
[...]
> 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.
[...]

This is what happens if you have applications that assume that
filename encoding matches the locale, and the locale encoding is
Latin-1 (or something very similar). You can work around those
applications by mounting FAT/VFAT volumes with iocharset set to match
the locale those applications run in. (But if you have a mix of
applications that assume different filename encodings then you lose.)

Sadly, basic commands like ls have this problem and probably can't
be changed due to compatibility concerns. Using a UTF-8 locale
(which I think the installer always selects by default) and
iocharset=utf8 is therefore likely to have the best result.

None of this is particularly relevant to the EFI boot volume, though,
as all filenames on there should be ASCII-only.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121009205938.GQ13292@decadent.org.uk">http://lists.debian.org/20121009205938.GQ13292@decadent.org.uk