Package: partman
Version: 0.30
I just tried the new partman (0.30, on mipsel with msdos labels), and
have some problems. Basically, it shows the whole hard drive, but
does not display the invididual partitions - even though it obviously
recognizes them because partman leaves some lines empty. When I
select an empty line, I get a window showing information about this
partition. But then I get the next problem: even if I tell partman to
format the partition, I am not able to specify the file system or
mount point.
Look for yourself:
This is an overview of your currently configured partitions and mount
points. Select a partition to modify its settings, a free space to
create partitions, or a device to initialise its partition table.
Finish partitioning and write changes to disk
Undo changes to partitions
IDE1 master - 30.7 GB Maxtor 6E030L0 #
Help on partitioning
Guided partitioning
<Go Back>
The empty lines are actually partitions.
When I choose the 4th line, I get:
You are editing partition #4 of IDE1 master. This partition is
formatted with the ext3 journalling file system.
Partition settings:
Usage method: format the partition
Bootable flag: off
Size: 25.2 GB
I choose "format the partition", get a menu like this:
How to use this partition:
Format the partition
But still cannot specify a mount point.
/var/log/partman is attached.
Partman needs to stop using non-breaking spaces. I thought I had this fixed,
but Anton put the non-breaking spaces back in:
- definitions.sh (debconf_select): convert the first space in the
options to non-break space as otherwise the default options is
ignored if it starts with space.
I think the default option may need to have the leading space escaped so
it looks the same as what is in the choices list. So you'd have:
Choices: \ a, \ b, \ c
Default: \ b
I probably did not think this through well enough when I was adding the
escaped spaces fix to cdebconf, but I think that will work.
I'm upgrading this bug to important, as it makes installation ugly and
difficult on all arches that need a serial console, as well as any laptop
where the frame buffer does not work.
I tried different ways with escaped spaces but without succes.
A properly setup non-framebufer console can support non-break spaces
and UTF-8. I think the following commands are sufficient:
for tty in /dev/tty[0-9]* /dev/vc/*; do
echo -ne '\e(K' >$tty
echo -ne '\e%G' >$tty
done
# kbd_mode -u
In principle I can look what needs to be changed/added to the
installer in order to setup properly the non-framebufer consoles;
unfortunately not during this and the next weeks because I have to go
on a short mission in Switzerland.
On the other hand we can not expect from every serial console to
support UTF-8. Because of that on serial consoles partman may not use
non ASCII-symbols.
Anton Zinoviev
Anton Zinoviev wrote: Can you point me to a place in partman where the default is wrong if I use the escaped space? I'll play around with it.
The partitions in the main menu. For example the user creates some new partition, setups it, returns to the main menu and it is not obvious which one of the partitions is the new one. Anton Zinoviev
* Joey Hess <joeyh@debian.org> [2004-04-14 14:32]: Just to clarify: is this just a display problem, or does this also explain why once I choose a partition and go to "format", I cannot choose a file system or mount point.
Martin Michlmayr wrote: AFAIK it's only a cosmetic problem. I have seen the behavior you describe when I tried to use a hurd partition as a linux root filesystem, iirc.
* Joey Hess <joeyh@debian.org> [2004-04-16 19:45]: Well, my partitions are normal Linux partitions, and they definitely worked with and older version of partman.
clone 243373 -1 retitle -1 Cannot give partition to be formated a mount point or file system thanks * Joey Hess <joeyh@debian.org> [2004-04-16 19:45]: In which case my original report contains two different issues, both important.
This is related to bug #189026 on debconf. The problem is that leading spaces are eaten both in Default: lines in the templates file, and in the SET command in the debconf protocol. We really need a solution that deals with all of these, and right now using escaped characters (\t, \n, \s or '\ ') strikes me as slightly better than quoted strings as it is easier to deal with, generalises to any problem character and supports newlines, and less likely to break existing stuff. But it's a big change, and a change likely to break stuff (anything with a literal "\n" in a question value for example), and one that we don't want to get wrong if we make the change because fixing it later would be very painful. Since it involves the debconf spec, it will need to go through the policy modification process anyway, which will be slow. Non-breaking spaces seem like a more palatable workaround from this new perspective. So we're back to why does cdebconf blank out entire lines if they start with a NBSP and it's not at a utf-8 terminal? Should this just be worked around by hacking on cdebconf to translate NBSP to spaces before display?
What is the behaviour of the text frontend? Anyway, using non-utf-8 terminal with C.UTF-8 locale is a bad idea. If the terminal is non-utf and the locale is C.UTF-8 then we may use only ASCII symbols. Or probably unset the LANG environment variable? Thus cdebconf (and its frontends) will know that the terminal is not utf-8. Anton Zinoviev
Anton Zinoviev wrote: I can reproduce the problem by simply running partman on vt 2 on i386. There TERM is linux and LANG is not set. I also see the problem if TERM is vt100. Actually, the only way I can get it to work there is by setting LANG=C.UTF-8, and belive me, that looks very funky.
I also reproduced this. It seams as if utf8 is hardcoded somehow in the newt frontend. The text frontend works fine. Anton Zinoviev
Anton Zinoviev wrote: I'm going to put a hack in partman to work around this, and reassign the bug to cdebconf. I'll make partman use a ">" instead of a NBSP, if the term is not bterm or xterm.
reassign 243373 libnewt0.51 thanks I can reproduce the same bug with whiptail --yesno '0xa0 This is a question' 12 34 where 0xa0 is the NBSP character, so I reassign this bug to libnewt0.51. Denis
I think this is the same, but in the partman the problem happens when partman tries to output an utf-8 non-break space (0xc2,0xa0) on non-utf-8 console. Anton Zinoviev
Hi, Please note that newt interprets the characters according to the current locale; eg. A Non-break space in a UTF-8 locale is 0xc2 0xa0 ; in ISO-8859-1 its 0xa0. A character 0xa0 in a UTF-8 locale will be treated as garbage and newt will stop output at that point -- the symptoms seen. I've tested the newt frontend with UTF-8 non-break space and it appears to work fine. I understand that having UTF-8 characters in the templates breaks non-UTF8 usages (eg text modes on serial consoles, etc.) I believe the best solution in those cases is to convert to ASCII on the text console -- note Non-Break space is not ASCII anyway, and shouldn't be relied on in serial consoles. Regards, Alastair
Hi, Please note that newt interprets the characters according to the current locale; eg. A Non-break space in a UTF-8 locale is 0xc2 0xa0 ; in ISO-8859-1 its 0xa0. A character 0xa0 in a UTF-8 locale will be treated as garbage and newt will stop output at that point -- the symptoms seen. I've tested the newt frontend with UTF-8 non-break space and it appears to work fine. I understand that having UTF-8 characters in the templates breaks non-UTF8 usages (eg text modes on serial consoles, etc.) I believe the best solution in those cases is to convert to ASCII on the text console -- note Non-Break space is not ASCII anyway, and shouldn't be relied on in serial consoles. Regards, Alastair
Alastair McKinstry wrote: Yes, that seems to be it, partman's definitions.sh uses 0xa0 for its non-breaking space. Yeah, that's a different bug, but one I'd like to see fixed.
Alastair McKinstry wrote: Yes, that seems to be it, partman's definitions.sh uses 0xa0 for its non-breaking space. Yeah, that's a different bug, but one I'd like to see fixed.
Ok, So as a fix for #243373 (non-breaking space in debconf strings problem), I propose: - reassigning #243373 to cdebconf-text - fix for cdebconf-text. Two solutions come to mind: (1) A "proper" iconv solution, converting UTF-8 to the current locale, by default ASCII, before printing. Would require iconv tables in the floppies, so not desirable. (2) Drop non-ASCII UTF-8 chars, replacing them with spaces, if in a non-UTF-8 locale. I recommend (2), and will write patch if agreed. Opinions? - Alastair
On Tue, May 04, 2004 at 10:13:59PM +0100, Alastair McKinstry wrote: [...] Okay, thanks for your explanations. I agree that this is a nice fix, but patching cdebconf-text-udeb does not seem trivial :( Denis
This has now been done in debconf using 'CAPB escape'. We just need to implement it in cdebconf too and then partman can use it (as well as fixing some of its multi-line SUBST hackery) ...