Re: Bug#784070: is it maybe possible to settle dislikings and fix this bug?
On Tue, 27 Oct 2015 17:04:43 + Dimitri John Ledkov wrote: [...] > I have outstanding patches to upload. And Michael previously asked me > to continue mdadm maintenance. That's really good news, Dimitri! Thanks a lot for stepping in, it's definitely appreciated. I think you should upload a version (or Debian revision) of mdadm with Michael's name replaced by yours in the Uploaders control field. Then, if you feel you could use some help from other people, you might consider the possibility of filing a RFH bug report (about mdadm) against the wnpp pseudo package... Thanks for your time and helpfulness. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpZtfYrt9Y0O.pgp Description: PGP signature
Re: mdadm: diff for NMU version 3.3.2-5.1
On Wed, 28 Oct 2015 17:34:42 +0100 Yann-externe SOUBEYRAND wrote: > You can find two packages on http://mentors.debian.net/package/mdadm : one > for jessie and one for sid. Can you upload these if you think they are > good, please? Dear Dimitri, is there any progress on this? Please let us know whether there's something blocking you from taking over mdadm Debian package maintenance and/or from fixing the annoying bug #784070. Thanks for your time. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp9WUY012l1S.pgp Description: PGP signature
Bug#759657: console-setup w/ systemd forgets font setting
Control: severity -1 important On Thu, 19 Nov 2015 13:31:57 -0500 Eric Cooper wrote: [...] > I see the same problem on every reboot. > > While booting, it looks like the font switches from VGA to Terminus > during the boot messages. But then the screen is cleared and the > getty login prompts are back in VGA. If I run "setupcon" manually, it > changes to Terminus. I am experiencing the same exact issue on the boxes where systemd is PID 1. I have different console settings, but they are not restored at boot, until I manually issue the setupcon command. I think the severity of this bug is at least important. Failing to set the console configuration at boot with systemd (which is the current default init system in Debian) is a really annoying misbehavior. Dear console-setup maintainers, this bug has been reported quite some time ago: is there any progress on this? Please fix this issue. Thanks for your time! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpnP1g6LCZcY.pgp Description: PGP signature
Bug#759657: console-setup w/ systemd forgets font setting
On Wed, 9 Dec 2015 16:42:34 +0200 Anton Zinoviev wrote: > On Tue, Dec 08, 2015 at 03:54:01PM +0100, Francesco Poli wrote: > > > > Dear console-setup maintainers, this bug has been reported quite some > > time ago: is there any progress on this? > > In order to be honest, I must admit that I don't use systemd in my > systems. I find the behaviour of systemd too complex and so far I > haven't have enough time to learn how exactly it works. Hello Anton, thanks for explaining and for your intellectual honesty (which is always appreciated!). I can understand and even sympathize with your position. I am no systemd enthusiast either, even though I must admit that it does have some advantages over sysvinit. Nonetheless, systemd is the current default init system in Debian, hence we have to learn how to live with it (or otherwise find a better alternative and persuade the Debian Project to switch to it as default...). > Therefore, for > the time being I am not qualified to work on this bug. > > However console-setup has many contributors. Hopefully one of them > will be able to fix this bug. OK, but perhaps there are better ways to express this than silently waiting for someone to come to the rescue... ;-) One possible way is adding the "help" tag to this bug report. I see [1] that there are currently 3 bug reports for console-setup which are tagged "help" and haven't received much help yet. So, maybe, the "help" tag is not too effective... Have you considered the possibility to (also) file a RFH bug report against wnpp [2] for console-setup? [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=help&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&src=console-setup [2] https://www.debian.org/devel/wnpp/ (as you sure already know) I hope a good fix for the issue may be found soon. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpNbuGJR200A.pgp Description: PGP signature
Bug#759657: console-setup w/ systemd forgets font setting
On Wed, 16 Dec 2015 16:28:34 +0200 Anton Zinoviev wrote: [...] > Anyway, the things will work even without such checks, so maybe your > proposed solution can be used unchanged after all... Hello again, I also tried the solution proposed [1] by Michael Biebl: $ cat /etc/udev/rules.d/90-setupcon.rules ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", RUN+="/bin/setupcon" and it works for me too. After boot, I get my console configuration without having to manually issue the setupcon command! [1] https://bugs.debian.org/759657#77 I think that package console-setup should ship such file as /lib/udev/rules.d/90-setupcon.rules Please add this file to the package in order to fix this annoying issue. Thanks for your time! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp92OeHMYhTv.pgp Description: PGP signature
Bug#759657: console-setup w/ systemd forgets font setting
On Tue, 5 Jan 2016 19:19:41 +0100 Samuel Thibault wrote: > Just my +1 > > Francesco Poli, on Tue 05 Jan 2016 19:00:30 +0100, wrote: > > [...] > > > Anyway, the things will work even without such checks, so maybe your > > > proposed solution can be used unchanged after all... > > > > Hello again, > > I also tried the solution proposed [1] by Michael Biebl: > > > > $ cat /etc/udev/rules.d/90-setupcon.rules > > ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", > > RUN+="/bin/setupcon" > > > > and it works for me too. > > Works for me too. Hello again, I also tried to create the same file on a system that has sysvinit as PID 1, in order to check whether the presence of this udev rule has any undesired side effects. It seems that this udev rule is completely harmless (although superfluous) on boxes with sysvinit as PID 1. On the other hand, it fixes the bug under consideration on boxes with systemd as PID 1. In conclusion, it really appears to be the solution to be adopted in order to fix this issue: once again, please consider adding such file as /lib/udev/rules.d/90-setupcon.rules to package console-setup. Thanks for your time! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpr8WaPIFMeM.pgp Description: PGP signature
Bug#759657: console-setup w/ systemd forgets font setting
On Mon, 11 Jan 2016 22:22:46 +0100 Francesco Poli wrote: [...] > In conclusion, it really appears to be the solution to be adopted in > order to fix this issue: once again, please consider adding such file > as /lib/udev/rules.d/90-setupcon.rules to package console-setup. [...] Dear console-setup package maintainers, is there anything blocking the adoption of the suggested solution for this bug? It seems to me that the solution has been explained by its proposer and tested by a number of different people. I am not aware of any undesired side effect or flaw. Hence I wonder what's preventing this solution from being accepted... Please let me know. Thanks for your time. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpVOHN7Fdv_z.pgp Description: PGP signature
Bug#759657: console-setup w/ systemd forgets font setting
On Sun, 17 Jan 2016 13:19:16 +0300 Anton Zinoviev wrote: > On Sat, Jan 16, 2016 at 06:37:18PM +0100, Francesco Poli wrote: > > On Mon, 11 Jan 2016 22:22:46 +0100 Francesco Poli wrote: > > > > Dear console-setup package maintainers, > > is there anything blocking the adoption of the suggested solution for > > this bug? > > I am sorry if I have created the impression that the proposed solution > is not accepted. Personally, I prefer to work on console-setup in a > batch mode and I plan to work on it during the second half of Ferbruary. > Although I am not sure if I will use exactly this solution, I don't mind > if other developers decide to upload a version of console-setup with it. That's OK, but, perhaps, next time you could reply earlier to inform interested parties about your plans. I got the (wrong) impression that something was preventing the proposed solution from being accepted just because of the total silence on the package maintainers' side! > > The discussion this bug was very helpful and I think I have a reasonable > hypothesis and understanding why the present version of console-setup > doesn't work with systemd. I sincerely thank all participants! OK, I am looking forward to seeing this bug fixed. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpIogRhwFCnE.pgp Description: PGP signature
Bug#411943: closed by Otavio Salvador <[EMAIL PROTECTED]> (Bug#411943: fixed in partman-lvm 62)
On Tue, 05 Aug 2008 17:09:09 + Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the partman-lvm package: > > #411943: partman-lvm: size of new LVs must be given in multiple of 1024 > instead of 1000 > > It has been closed by Otavio Salvador My original bug report used to have a different title (by reading the bug log, I see it has been retitled). I am not completely sure I understand what direction was taken to fix the bug: does partman-lvm use decimal (i.e.: SI) multiples everywhere *now*, on both input and output, consistently with the rest of partman? Could you please clarify? Thanks in advance. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! ..... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpZ2uQEnJA9D.pgp Description: PGP signature
Bug#411943: closed by Otavio Salvador <[EMAIL PROTECTED]> (Bug#411943: fixed in partman-lvm 62)
On Wed, 6 Aug 2008 22:32:00 +0200 Jérémy Bobbio wrote: > On Wed, Aug 06, 2008 at 03:29:23PM +0200, Francesco Poli wrote: [...] > > I am not completely sure I understand what direction was taken to fix > > the bug: does partman-lvm use decimal (i.e.: SI) multiples everywhere > > *now*, on both input and output, consistently with the rest of partman? > > > > Could you please clarify? > > Yes, partman-lvm should use decimal multiples everywhere now. Very good! :-) Thanks for the clarification! > Don't hesitate to tell us if we missed a spot. Should I notice some other inconsistency, I will report it as appropriate. Bye and thanks for fixing the bug (in the right direction!). -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! ..... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpTdy29dOiga.pgp Description: PGP signature
Bug#401233: debian-installer-manual: how to get the guide source should be clarified
reopen 401233 ! thanks On Sat, 2 Dec 2006 15:50:02 +0100 Francesco Poli wrote: > reopen 40123 ! ^^^ > thanks [...] Let's see if this time I manage to reopen the right bug! :-/ I hope I didn't reopen a very old bug by mistake: http://bugs.debian.org/40123 gives the following error message: | | There is no record of Bug #40123. Try the search page instead. | And the BTS replied to me: | | > reopen 40123 ! | Bug number 40123 not found. (Is it archived?) | Consequently it seems to me that I didn't reopen anything with my previous messed up control request... -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ ..... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgph27I4gaZUb.pgp Description: PGP signature
Bug#401233: debian-installer-manual: how to get the guide source should be clarified
On Sat, 02 Dec 2006 16:35:33 +0100 Frans Pop wrote: > On Saturday 02 December 2006 15:50, Francesco Poli wrote: > > The problem is: figuring out where to get the source by looking at > > the webpage[1] is not made easy. In that page[1] there are links > > for a great number of compiled versions of the manual, but no direct > > link the the source. > > Then you should probably look inside the manual itself, specifically: > http://www.debian.org/releases/stable/i386/apds02.html.en That is good for learning how to get the latest development version. But if one wants the source for the published stable version, well, it does not seem easy... > > I agree that for Sarge it is then still quite hard to make the link to > the manual, but for Etch, where the manual has its own source > package, I'd expect people to be able to find it. As I said, being aware that the manual is *actually* packaged in a .deb package is not trivial. *You* can perceive it as obvious, *I* can know it (even if, as I told you previously, I had forgotten it for a while...), but many people (especially those who are coming from some other distros, or from proprietary OSes) won't understand that immediately... > > If not, they can always ask on the debian-boot list. Finding the > address for that should be no problem. Why not making things clearer, rather than being prepared to answer questions on mailing lists? Once again, new users can be too shy to pop up on a mailing list... > Adding a link to the tarbal is next to impossible as it would have to > include a changing version number. What do you mean? I'm talking about the published stable version of the manual: it's been the same exact version since June 2005 so far (or am I wrong?). Adding a simple link should not be difficult... > > I honestly see no reason to add the info on the website. I think I described more than one reason to do so... -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpi4Pxhoujxt.pgp Description: PGP signature
Bug#401233: debian-installer-manual: how to get the guide source should be clarified
On Sat, 02 Dec 2006 19:02:55 +0100 Frans Pop wrote: > On Saturday 02 December 2006 18:27, Francesco Poli wrote: > > I'm talking about the published stable version of the manual: it's > > been the same exact version since June 2005 so far (or am I wrong?). > > Yes, you are wrong. Could you be a little more explicit? Are you referring to point releases? -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ ..... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpx3Rec2ajaH.pgp Description: PGP signature
Bug#405496: installation-report: successful installation on a rather old Pentium-MMX box
Package: installation-report Severity: wishlist Boot method: multi-arch netinst CD (as of 2006-12-28) Image version: http://cdimage.debian.org/cdimage/weekly-builds/multi-arch/iso-cd/debian-testing-MULTI-NETINST-1.iso Date: Wed, 03 Jan 2007 17:50:33 +0100 Machine: assembled box CPU: Pentium-MMX Clock frequency: 200 MHz RAM capacity: 64 Mibyte HD capacity: about 4.3 Gbyte Please see the attached hardware summary for further details Partitions: (the raw partition table, as written by cfdisk, is attached) # df -Tl FilesystemType 1K-blocks Used Available Use% Mounted on /dev/mapper/notsooldbox-root ext3 1318312250080 1001264 20% / tmpfstmpfs 31108 0 31108 0% /lib/init/rw udev tmpfs 1024056 10184 1% /dev tmpfstmpfs 31108 0 31108 0% /dev/shm /dev/hda1 ext3 241116 13326215342 6% /boot /dev/mapper/notsooldbox-home ext3 2439120 69256 2245960 3% /home Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[ ] Configure network: [ ] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[O] Comments/Problems: No problems AFAICS. Note that I tested the guided partitioning of the entire disk with encrypted LVM (choosing to separate /home): it seems to work fine. Also note that I only installed the base system, without selecting any task. hardware-summary.gz Description: Binary data raw-part-table.gz Description: Binary data
Bug#405496: installation-report: successful installation on a rather old Pentium-MMX box
On Thu, 04 Jan 2007 01:11:36 +0100 Frans Pop wrote: > On Thursday 04 January 2007 00:30, Francesco Poli wrote: > > Comments/Problems: > > No problems AFAICS. > > Note that I tested the guided partitioning of the entire disk with > > encrypted LVM (choosing to separate /home): it seems to work fine. > > I wonder how long the wipe of the encrypted LVM took, even though it > is only 4GB. If I read /var/log/installer/syslog correctly, it took 2458 s: that is the time interval between the following two log lines Jan 3 18:57:02 partman: mke2fs 1.40-WIP (14-Nov-2006) Jan 3 19:38:00 partman-crypto: kernel entropy_avail: 3613 bits > Nice to see that it works with only 64MB memory in the > box. Yes, even though in low memory mode. > > > Also note that I only installed the base system, without selecting > > any task. > > Thank you very much for submitting the installation report. As there > were no issues, I'm closing it. There's a little issue, now that I think better: I don't remember seeing any question whatsoever regarding the hardware clock. I mean: the Debian Installer asked me to select a country and I chose Italy. Hence the timezone was correctly set to Rome/Paris (that, in winter, makes CET, or +0100, if you prefer). So far so good. But nothing asked me whether the hardware clock was in local time or UTC! It was silently assumed to be UTC, which, BTW, was I what I wanted it to be, but forgot to set accordingly in the BIOS configuration menu. The result was that the box had the hardware clock correctly set to local time (because I forgot to set it to UTC), but the installed system assumed it to be set to UTC and displayed times with a +1 hour error. I fixed the problem by setting the hardware clock to UTC in the BIOS configuration menu, as I wanted. But I think that the Debian Installer should ask the user whether the hardware clock is set to local time or UTC, especially since machines that previously had (or still have) a Windows installation typically work with the hardware clock set to local time. -- http://frx.netsons.org/progs/scripts/releas-o-meter.html Try our amazing Releas-o-meter! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpwSHj9cp0h0.pgp Description: PGP signature
Bug#405496: installation-report: successful installation on a rather old Pentium-MMX box
On Thu, 04 Jan 2007 17:39:21 +0100 Frans Pop wrote: > On Thursday 04 January 2007 17:16, Francesco Poli wrote: > > But nothing asked me whether the hardware clock was in local time or > > UTC! > > It was silently assumed to be UTC, which, BTW, was I what I wanted > > it to be, but forgot to set accordingly in the BIOS configuration > > menu. > > It is asked in expert mode. For default installs, we have a smart > algorithm that determines the likely value. > Roughly: if the box also has Windows installed, local time is assumed; > if only Linux, UTC is assumed; in some cases the question is asked. > > If the time is incorrect after the boot, the user is expected to > either run 'date', or change the UTC setting in /etc/default/rcS. Ah, I see: I hope this is documented in the installation manual (I didn't check by myself). -- http://frx.netsons.org/progs/scripts/releas-o-meter.html Try our amazing Releas-o-meter! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpO7HMGsfNzK.pgp Description: PGP signature
Bug#410129: installation-guide: minor fix for section 1.1 _What is Debian_
Package: installation-guide Version: 20070122 Severity: wishlist Hi! Section 1.1 _What is Debian_[1] states, in part: | Debian is an all-volunteer organization dedicated to developing free | software and promoting the ideals of the Free Software Foundation. I'd say that Debian promotes (or should promote...) the ideals of Free Software, not necessarily those of the FSF, which not always agrees with the Debian Project (see the disagreements on the GFDL, for instance...). Hence, I would suggest: s/the ideals of the Free Software Foundation/the ideals of Free Software/ so that users that read the installation guide won't come back later and complain, when they find out that the Debian Project and the FSF have different opinions regarding some issues... [1] http://d-i.alioth.debian.org/manual/en.amd64/ch01s01.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410317: installation-guide: links to be fixed in section 1.2 _What is GNU/Linux?_
Package: installation-guide Version: 20070122 Severity: minor Hi! Section 1.2 _What is GNU/Linux?_[1] states, in part: | Development of what later became GNU/Linux began in 1984, when the | _Free Software Foundation_ began development of a free Unix-like | operating system called GNU. | | The GNU Project has developed a comprehensive set of free software | tools for use with Unix(TM) and Unix-like operating systems such | as Linux. where the underlined _Free Software Foundation_ is a link pointing to http://www.gnu.org/ I think it would be better if such link pointed to http://www.fsf.org/ instead. The "GNU Project" in the next paragraph could be turned into a link pointing to http://www.gnu.org/ at the same time... Later on, the same section states: | | See Linux International's _Linux History Page_ | where the underlined _Linux History Page_ is a link pointing to http://www.li.org/linuxhistory.php Well, maybe it's me, but I could not find anything related to Linux history on that website... Wrong URL? Changed website that used to host useful information, but no longer does? I don't know, but I think that the link should be fixed (or otherwise dropped). [1] http://d-i.alioth.debian.org/manual/en.amd64/ch01s02.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411399: installation-guide: claims that the swap partition is created *outside* the LVM partition
Package: installation-guide Version: 20070122 Severity: normal Hi! Section 6.3.2.1. _Partitioning Your Disks_[1] states: | If you choose guided partitioning using (encrypted) LVM, the installer | will also create a separate /boot partition. The other partitions, | except for the swap partition, will be created inside the LVM partition. ^ [1] which is inside http://d-i.alioth.debian.org/manual/en.amd64/ch06s03.html#di-partition AFAICT, guided partitioning creates all the other partitions, apart from the /boot partition, *inside* the LVM partition. That is to say: disk --+ |-- /boot |-- PV ---+ |- VG ---+ |-- LV home |-- LV root |-- LV swap |-- LV tmp |-- LV usr |-- LV var Hence, I would say: s/except for the swap partition/including the swap partition/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411586: partman-auto-lvm: LVM guided partitioning does not seem to be customisable
Package: partman-auto-lvm Version: 18 Severity: normal Hi! I'm trying to configure an LVM partitioning in a virgin disk on a brand new machine. I'm using the CD labeled as: Debian GNU/Linux testing "Etch" - Official Snapshot amd64 NETINST Binary-1 20070218-08:47 that is to say http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Using the textual user interface debian-installer, I reach the partitioning stage. I choose the partitioning method called "Guided - use entire disk and set up LVM" and select the disk to partition (there's only one to choose). I choose "Separate /home, /usr, /var, and /tmp partitions" as partitioning scheme and confirm to write the physical partition table. At that point, I get an automatically generated LVM and partition layout: LVM VG hostname, LV home - 239.4 GB Linux device-mapper #1 239.4 GB f ext3 /home LVM VG hostname, LV root - 289.4 MB Linux device-mapper #1 289.4 MB f ext3 / LVM VG hostname, LV swap_1 - 1.5 GB Linux device-mapper #1 1.5 GB f swap swap LVM VG hostname, LV tmp - 411.0 MB Linux device-mapper #1 411.0 MB f ext3 /tmp LVM VG hostname, LV usr -5.1 GB Linux device-mapper #1 5.1 GB f ext3 /usr LVM VG hostname, LV var -3.1 GB Linux device-mapper #1 3.1 GB f ext3 /var SCSI1 (0,0,0) (sda) - 250.1 GB ATA MAXTOR STM325082 #1 primary 255.0 MB B f ext3 /boot #5 logical 249.8 GB K lvm This is not bad, but I would like to customise it a bit. I would like to resize some logical volumes, before finishing partitioning. The debian-installer told me that I would be able to customise the layout after seeing the results of guided partitioning... Hence, I try to resize the /home logical volume. Selecting the "LV home" line seems to yield to no effect at all. Selecting the "/home" line leads to a partition properties screen, but I cannot figure out how to resize the partition: I can delete it, I can erase its data, I can copy data from another partition, I can change mount point, filesystem, and so forth, but no size handling... I cannot understand what's wrong. Does the confirmation message mean that nothing can be customised? I thought it referred to the physical partitioning only (that is to say, the /dev/sda1,/dev/sda5 split)... Even selecting "Undo changes to partitions", "Guided partitioning" and then "Manual" does not seem to allow me to set logical volume sizes... Have I to restart the installation from scratch on a clean disk and select "Manual partitioning" without ever touching any guided process at all, in order to set up an LVM layout with sizes that fit my tastes? I am a bit confused... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411586: partman-auto-lvm: LVM guided partitioning does not seem to be customisable
On Tue, 20 Feb 2007 01:04:02 +0100 Frans Pop wrote: > reassign 411586 partman-lvm > severity 411586 minor > thanks I think you forgot to Cc: [EMAIL PROTECTED] ... > > On Tuesday 20 February 2007 00:44, Francesco Poli wrote: > > I cannot understand what's wrong. > > Does the confirmation message mean that nothing can be customised? > > I thought it referred to the physical partitioning only (that is > > to say, the /dev/sda1,/dev/sda5 split)... > > Resizing LVM partitions is not supported. This is awkward, as I will be able to resize them *after* the system is installed and running. IIUC, this is the whole point of using LVM! As a consequence, I find it strange that I cannot resize them while I'm about to create their layout... > If you want to customize > them, you need to go to the "configure LVM" at the top of the main > partman menu option and make your changes there by deleting LVs and > recreating them at the desired size. Then you probably will have to > assign mountpoints again. This is more or less equivalent to setting up the whole layout using the Manual method, isn't it? What's the point of having a Guided LVM method, then? It's just a "take it or leave it" offer, and one that is not even easily undoable, IIUC... > > I agree that the user interface is not optimal for this. Undoubtedly > it will be improved in the future, just as support for LVM has > improved steadily between sarge and etch. > I hope it will. Anyway, I'll try the Manual method, for the time being... -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJiZDwqU49u.pgp Description: PGP signature
Bug#411943: partman-lvm: inconsistent usage of unit symbols for decimal and binary multiples
Package: partman-lvm Version: 50 Severity: important Hi! I'm again trying to configure an LVM partitioning in a virgin disk on the same brand new machine, as described in bug#411586. I'm using the CD labeled as: Debian GNU/Linux testing "Etch" - Official Snapshot amd64 NETINST Binary-1 20070218-08:47 that is to say http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Using the textual user interface debian-installer, I reach the partitioning stage. I choose the partitioning method called "Manual". The next screen displays the current disk partition table: | SCSI3 (0,0,0) (sda) - 250.1 GB ATA MAXTOR STM325082 | pri/log 250.1 GB FREE SPACE So far so good. I select the free space line and choose "Create a new partition" from the dialog screen, enter 250 MB as partition size, choose "Primary" as partition type, ask that the partition be created at the beginning of the available space, change the mount point to /boot, and set the bootable flag to "on". After choosing "Done setting up the partition", I get back to the partition table screen, with the following updated status: | SCSI3 (0,0,0) (sda) - 250.1 GB ATA MAXTOR STM325082 |#1 primary 246.7 MB B f ext3 /boot | pri/log 249.8 GB FREE SPACE I again select the free space line and choose "Create a new partition", enter "max" as partition size, choose "Logical" as partition type, and change the "Use as" entry to "physical volume for LVM". After choosing "Done setting up the partition", I get back to the partition table screen, with the following updated status: | SCSI3 (0,0,0) (sda) - 250.1 GB ATA MAXTOR STM325082 |#1 primary 246.7 MB B f ext3 /boot |#5 logical 249.8 GB K lvm I choose "Configure the Logical Volume Manager" and confirm to write the partition table. The next screen allows me to configure the LVM: I choose "Create volume group", and enter the hostname as volume group name. I select /dev/sda5 for the new volume group. Back to the LVM configuration menu: I choose "Create logical volume" and select the only possible volume group. I enter "home" as logical volume name and get to the logical volume size screen: the size field initially displays "249808MB" which seems to be the correct maximum allowed size for this new logical volume. That "MB" seems to mean megabyte, that is to say 10^6 byte. OK: I want this logical volume to have a size of 232.8 Gbyte, (i.e.: 232.8 * 10^9 byte), hence I enter "232800MB". Everything seems to go OK, as I'm back to the LVM configuration menu. But, if I choose "Display configuration details" I see something very worrying: | Unallocated physical volumes: | * none | | Volumes groups: | * hostname (249808MB) | - Uses physical volume: /dev/sda5(249808MB) | - Provides logical volume: home (244108MB) What?!? 244.108 Gbyte for my home lv?!? I didn't asked for such a huge lv! Now I have too little space for the other logical volumes! Indeed, if I try to create a second lv, I see that only 5700 Mbyte are usable, while I wanted to have about 17 Gbyte ... I go back to the LVM configuration menu and delete the home lv. Let's try again: "Create logical volume". Again I enter "home" as lv name and again I get 249808MB as maximum size. I notice that the help text says the possible formats are 10K, 10M, 10G, 10T and that the default unit is Megabytes. I try with "232800M" and I again get "244108MB" ! OK, delete and recreate... I try with "232.8GB" and I get an error message stating: | Error while creating a new logical volume | Unable to create a new logical volume (home) on hostname with the new | size 0. | | Check /var/log/syslog or see virtual console 4 for the details. Virtual console 4 says: | partman-lvm: Insufficient free extents (59559) in volume group hostname: 59597 required | partman-lvm: | partman-lvm: Rounding up size to full physical extent 232.80 GB OK, try again: if I enter "232800" with no unit, I should get 232800 Mbyte, right? No, I again get 244108 Mbyte ! Now I notice something suspicious: 232800 * 2^20 byte = 244108492800 byte =~ 244108 Mbyte 232.8 * 2^30 byte =~ 249967096627.2 byte > 249808 Mbyte There seems to be a big mess on binary and decimal prefixes for units. This is a serious usability issue: the interface uses the same symbol (e.g.: "MB") for different meanings (Mebibyte = 2^20 byte and Megabyte = 10^6 byte) and thus heavily confuses the user. Please fix this big inconsistency: switch to decimal multiples for everything in partman. Hard disk vendors describe disk capacities using decimal multiples of the byte unit (1 kbyte = 10^3 byte, 1 Mbyte = 10^6 byte, 1 Gbyte = 10^9 byte, ...) and partman should speak consistently. P.S.: I set the severity of this bug to "important" bug, since it has a major effect on the usability of a package, but I strongly believe that etc
Bug#411943: partman-lvm: inconsistent usage of unit symbols for decimal and binary multiples
On Thu, 22 Feb 2007 01:51:58 +0100 Frans Pop wrote: > On Thursday 22 February 2007 01:17, Francesco Poli wrote: > > I set the severity of this bug to "important" bug, since it has a > > major effect on the usability of a package, but I strongly believe > > that etch debian-installer should *not* be released with such a > > usability issue. > > This issue has been in partman for quite some time. There's absolutely > no reason to consider it anything than a cosmetic issue. I'm sorry, but I have to strongly disagree. Creating the graphical installer was useful to solve a cosmetic issue. This is instead a usability issue: user interface consistency is one of the key principles of usability. When the user asks for a value and gets another one, just because the same symbol is used with different meanings on input and output, he/she gets heavily confused and goes away telling other people that Debian is too hard to install... Believe me, I lost almost half an evening in trying to understand what was going on, before I figured out that "MB" was being used with two different meanings on input and output. And I consider myself as an informed user, especially on unit of measurement issues... > We'll look at this at our leasure after Etch has been released. > Leaving severity at important, even though you could just as well > argue for minor. I could argue for grave, IMHO. > > Your testing and feedback is appreciated, but we're not going to delay > the release or hazard the stability of the code we have now by making > rash changes to fix this. As I said, I think that this is something that should really be fixed *before* etch is out. It's well known that Debian releases when it's ready: I don't think that partman in the current status is actually ready. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpNzK7DeTSi6.pgp Description: PGP signature
Bug#410317: closed by Frans Pop <[EMAIL PROTECTED]> (Bug#410317: fixed in installation-guide 20070319)
On Mon, 19 Mar 2007 19:27:07 + Debian Bug Tracking System wrote: [...] > - make links to FSF and GNU more consistent (closes: #410317) I see the FSF and GNU links fixed (and that's OK), but I still see the seemingly off-topic link to http://www.li.org/linuxhistory.php . Please reopen the bug, as appropriate, or otherwise explain where anything related to Linux history can be found in http://www.li.org/linuxhistory.php ... -- http://frx.netsons.org/doc/nanodocs/etch_workstation_install.html Need to read a Debian etch installation walk-through? ..... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpVnjVgGQmeu.pgp Description: PGP signature
Bug#410317: closed by Frans Pop <[EMAIL PROTECTED]> (Bug#410317: fixed in installation-guide 20070319)
On Tue, 20 Mar 2007 01:28:48 +0100 Frans Pop wrote: > On Monday 19 March 2007 21:55, Francesco Poli wrote: > > I see the FSF and GNU links fixed (and that's OK), but I still see > > the seemingly off-topic link to http://www.li.org/linuxhistory.php . > > Thanks for reminding. I missed that. You're welcome. > The original page can be found using the Internet Wayback Machine: > http://web.archive.org/web/20051213084641/http://www.li.org/linuxhistory.php > > I found another copy of the same text at a university in cs, so I've > changed the link to there: > http://www.cs.cmu.edu/~awb/linux.history.html Ah, I see. Maybe the bug could be reopened and tagged pending, what do you think? > > Too late for Etch though. Well, it's a minor bug anyway, so I don't see this as a problem... -- http://frx.netsons.org/doc/nanodocs/etch_workstation_install.html Need to read a Debian etch installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpwQO4gHHjlA.pgp Description: PGP signature
Bug#401233: debian-installer-manual: how to get the guide source should be clarified
Package: debian-installer-manual Severity: wishlist Hi! It's not clear to me how to get the source for the Debian Installation Guide. At the Debian Documentation Project page[1], there's a Subversion command line that will probably checkout the latest development version (right?). This seems OK. But the published version for the stable release[2] does not tell any method to get source for that version. I think it should made easy to get the source for the published version of the guide, ideally with a link to a good (gzipped or bzipped2) tar archive of the complete source. I tried to browse through the WebSVN interface, but I quickly got lost... :-( After some failed tries, I figured out that I could get the source package of debian-installer-manual (sarge version), but it's not really clear to me whether this is the same exact version as the one "published for the stable release"[2]... Is it the same? In any case, I think that a good link in the webpage[2] would really make things easier (especially for users that lack enough familiarity with Debian). Can we have this fixed for the next stable release (etch), please? Thanks for your attention. [1] http://www.debian.org/doc/user-manuals#install-sarge [2] http://www.debian.org/releases/stable/installmanual -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401233: debian-installer-manual: how to get the guide source should be clarified
reopen 40123 ! thanks On Sat, 02 Dec 2006 11:05:22 +0100 Frans Pop wrote: > On Saturday 02 December 2006 00:59, Francesco Poli wrote: > > It's not clear to me how to get the source for the Debian > > Installation Guide. > > For the Sarge version: apt-get source debian-installer > For the Etch version: apt-get source installation-guide > > In both cases you could have found out by looking at the > packages.debian.org website as that lists which source package each > normal package belongs to. > http://packages.debian.org/stable/devel/debian-installer-manual > http://packages.debian.org/testing/doc/installation-guide-i386 [...] Apologies for not being clear enough. Let's try to explain things better... The problem is *not* that the source for the stable version of the manual is not distributed: it is, and that's OK. Hence the wishlist severity of the bug. The problem is: figuring out where to get the source by looking at the webpage[1] is not made easy. In that page[1] there are links for a great number of compiled versions of the manual, but no direct link the the source. I searched inside the page and found no hints. I found hints to use the subversion repository elsewhere, tried to dig the WebSVN interface and got lost. Only *then* I remembered that the manual is also packaged and thus found the source tar archive[2]. I could have been smarter in the first place, I admit it's my poor brain's fault, but anyway why not making things easier? I've been using Debian since 2002 and I don't consider myself a totally inexperienced user. Just imagine some casual Gordon Gpllover that knows little about Debian and wants (for reasons unknown) to redistribute a PDF version of the stable Debian installation guide. He does *not* know that the manual is also packaged: he finds the webpage[1] and downloads the PDF. He reads that the guide is under the GNU GPL and thus knows that he must make the source available in order to redistribute it (Gordon knows little about Debian, but is quite familiar with the GNU GPL license!). In this scenario, a little link to the tar archive[2] from the webpage[1] would do the trick and make Gordon's life much easier... I hope I clarified what I meant. [1] http://www.debian.org/releases/stable/installmanual [2] http://ftp.debian.org/debian/pool/main/d/debian-installer/debian-installer_20050317sarge1.tar.gz -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp4HT7xzRjk6.pgp Description: PGP signature
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
On Wed, 16 Sep 2009 20:50:38 +0200 Francesco Poli (t1000) wrote: [...] > Today, I booted up the notebook and logged in on the console > (I do not use any graphical login manager) and noticed that > the keyboard layout was set to US, while my notebook has an > Italian keyboard [...] > Please help! > I really cannot understand why setting a non-US keyboard layout > has suddenly become *so* hard in Debian testing! May I have some sort of reply, please? What's wrong with my configuration? Why cannot I set a non-US keyboard layout on the console? -- New location for my website! Update your bookmarks! http://www.inventati.org/frx ..... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpWd2u4BqUPG.pgp Description: PGP signature
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
On Wed, 11 Nov 2009 19:43:29 +0200 Anton Zinoviev wrote: > On Wed, Sep 16, 2009 at 08:50:38PM +0200, Francesco Poli (t1000) wrote: > > > > Despite XKBLAYOUT is clearly set to "it", I still get a US keyboard > > map on the console (X is fine, instead). > > I am unable to reproduce this. Ouch! :-( > Can you make the following tests: > > 1. What happens if you run on the console 'setupcon' as root? I login as root on the console: I get a US keymap. # setupcon Mmmh, the screen flashed a few times and now I get an IT keymap. However, console fonts changed: take into account that I have $ tail -n 6 /etc/console-tools/config SCREEN_FONT=lat1u-16 SCREEN_FONT_vc2=lat1u-16 SCREEN_FONT_vc3=lat1u-16 SCREEN_FONT_vc4=lat1u-16 SCREEN_FONT_vc5=lat1u-16 SCREEN_FONT_vc6=lat1u-16 I ended up using those fonts, since those ones are the only fonts I found that let me see the symbols produced by $ toilet -f future "hello" ╻ ╻┏━╸╻ ╻ ┏━┓ ┣━┫┣╸ ┃ ┃ ┃ ┃ ╹ ╹┗━╸┗━╸┗━╸┗━┛ If you are able to suggest better fonts, please do not hesitate to do so! After running 'setupcon' the console is no longer able to correctly show such symbols. After a reboot, the situation is back as before: fonts are as I want them to be, but keymap is US... > 2. What happens if you run on the console > /etc/init.d/keyboard-setup start I do not have any /etc/init.d/keyboard-setup on my system! That's because I do not have console-setup installed, but console-setup-mini, instead: $ aptitude search console-setup | cut -c 1-35 p console-setup i A console-setup-mini > 3. What happens if you run on the console > /etc/init.d/console-setup start I do not have any /etc/init.d/console-setup either! Same reason as above. > 4. If all this works that check that there are files >/etc/rcS.d/S06keyboard-setup and /etc/rcS.d/S49console-setup $ ls /etc/rcS.d/*keyboard-setup /etc/rcS.d/*console-setup ls: cannot access /etc/rcS.d/*keyboard-setup: No such file or directory ls: cannot access /etc/rcS.d/*console-setup: No such file or directory That's probably, once again, because I have console-setup-mini, rather than console-setup, installed on my system. > 5. If some of this doesn't work, then open /etc/default/console-setup >and put there >VERBOSE_OUTPUT=yes Done. >Then send the output of 'setupcon' Here's the stderr dump: Loading 256-chars 8x16 font from file `/usr/share/consolefonts/Lat15-TerminusBold16.psf'. Setting kernel SFM. Loading 256-chars 8x16 font from file `/usr/share/consolefonts/Lat15-TerminusBold16.psf'. Setting kernel SFM. Loading 256-chars 8x16 font from file `/usr/share/consolefonts/Lat15-TerminusBold16.psf'. Setting kernel SFM. Loading 256-chars 8x16 font from file `/usr/share/consolefonts/Lat15-TerminusBold16.psf'. Setting kernel SFM. Loading 256-chars 8x16 font from file `/usr/share/consolefonts/Lat15-TerminusBold16.psf'. Setting kernel SFM. Loading 256-chars 8x16 font from file `/usr/share/consolefonts/Lat15-TerminusBold16.psf'. Setting kernel SFM. Loading /etc/console-setup/cached.kmap.gz I hope this helps in pinpointing the problem. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpDUxk22bi64.pgp Description: PGP signature
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
On Thu, 12 Nov 2009 07:42:02 +0200 Anton Zinoviev wrote: > On Thu, Nov 12, 2009 at 12:26:52AM +0100, Francesco Poli wrote: [...] > > If you are able to suggest better fonts, please do not hesitate to do > > so! > > First you need to install console-setup. Console-setup-mini supports > limited set of fonts. Then use "dpkg-reconfigure console-setup" in > order to test the fontsets provided by console-setup. They are VGA, > Fixed, Terminus and TerminusBold. After dpkg-reconfigure you can use > setupcon to activate the changes and to test the result. I did the following: # aptitude -t unstable install console-setup console-setup-mini- # aptitude purge console-setup-mini This installed console-setup/1.46 and console-terminus/4.28-2, while removing console-setup-mini. # dpkg-reconfigure console-setup I answered the questions in the following way: Keyboard model? Acer Laptop Keyboard layout? Italy AltGr key replacement? The default for the keyboard layout Compose key? Menu key Use Control+Alt+Backspace to terminate the X server? No Encoding to use on the console? UTF-8 Character set to support? Latin1 and Latin5 Font for the console? Fixed Font size? 16 I got the following error: /var/lib/dpkg/info/console-setup.postinst: line 115: /etc/console-setup/cached.kmap.gz: No such file or directory Then: # setupcon /bin/setupcon: line 367: /etc/console-setup/cached.kmap.gz: No such file or directory Fonts do *not* show "toilet -f future" symbols correctly, the layout is still US (why?), and some keys (e.g.: Shift+6) do not produce the corresponding (US layout) character until other keys are pressed (I had never seen such a behavior before). OK, let's restart from scratch. # dpkg-reconfigure console-setup Keyboard model? Generic 105-key (Intl) PC Now I get the following complain: | The configuration file /etc/default/console-setup specifies a keyboard | layout (us,dvorak), which is not supported by the configuration program. | | Please choose whether you want to keep it. If you choose this option, no | questions about the keyboard layout will be asked and the current | configuration will be preserved. | | Keep unsupported settings in configuration file? Why us,dvorak ? I have never asked for a dvorak layout !! I answer "No" to the question. Then: Origin of the keyboard? Italy Keyboard layout? Italy AltGr key replacement? Right Alt Compose key? No compose key Use Control+Alt+Backspace to terminate the X server? No Encoding to use on the console? UTF-8 Character set to support? Latin1 and Latin5 Font for the console? Terminus Font size? 16 Again the following error message is shown: /var/lib/dpkg/info/console-setup.postinst: line 115: /etc/console-setup/cached.kmap.gz: No such file or directory Then: # setupcon /bin/setupcon: line 367: /etc/console-setup/cached.kmap.gz: No such file or directory Once again, fonts do *not* show "toilet -f future" symbols correctly, the layout is still US (why?), and some keys do not produce the corresponding (US layout) character until other keys are pressed. During the tests I also got the following kernel errors: [21794.596239] circuit:12185 conflicting memory types 9000-9500 uncached-minus<->write-combining [21794.596425] reserve_memtype failed 0x9000-0x9500, track uncached-minus, req uncached-minus I don't know if those are related, but I had never seen them before... For the record, the generated /etc/default/console-setup is as follows and it does not seem to comply with my debconf answers: # grep -v '^#' /etc/default/console-setup VERBOSE_OUTPUT=no ACTIVE_CONSOLES="/dev/tty[1-6]" CHARMAP=UTF-8 CODESET=Lat15 FONTFACE=TerminusBoldVGA FONTSIZE=16 XKBMODEL=pc105 # the model of the keyboard XKBLAYOUT=us,dvorak # US QWERTY and Dvorak keyboards XKBVARIANT=intl,# the US keyboard can generate international symbols XKBOPTIONS=lv3:ralt_switch,grp:ctrl_shift_toggle # the right Alt selects international symbols, Control+Shift toggles between QWERTY and Dvorak Now I am more puzzled than before. I will try and perform some more tests tomorrow... The following commands got back to my initial situation: # aptitude --purge-unused install console-setup- console-setup-mini # aptitude purge console-setup [...] > > I hope this helps in pinpointing the problem. > > Yes, thank you. You're welcome. > But there is another problem to solve: Why you system > is using console-setup-mini instead of console-setup? As I told in the original bug report, it was simply pulled in as a dependency during an upgrade... However, on a more recently installed (Debian testing) box console-setup was installed instead. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx ..
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
On Sat, 14 Nov 2009 01:03:37 +0100 Francesco Poli wrote: [...] > I will try and perform some more tests tomorrow... Let's *really* restart from scratch: # aptitude -t unstable install console-setup console-setup-mini- This installed console-setup/1.46 and console-terminus/4.28-2, while removing console-setup-mini. However, this left configuration files for console-setup-mini around: # dpkg -l | grep ^rc | cut -c 1-60 rc console-setup-mini 1.45 # ls /etc/console-setup/ cached.kmap.gzcompose.ISO-8859-11.inc compose.ISO-8859-6.inc compose.ARMSCII-8.inc compose.ISO-8859-13.inc compose.ISO-8859-7.inc compose.CP1251.inccompose.ISO-8859-14.inc compose.ISO-8859-8.inc compose.CP1255.inccompose.ISO-8859-15.inc compose.ISO-8859-9.inc compose.CP1256.inccompose.ISO-8859-16.inc compose.KOI8-R.inc compose.GEORGIAN-ACADEMY.inc compose.ISO-8859-1.inc compose.KOI8-U.inc compose.GEORGIAN-PS.inc compose.ISO-8859-2.inc compose.TIS-620.inc compose.IBM1133.inc compose.ISO-8859-3.inc compose.VISCII.inc compose.ISIRI-3342.inccompose.ISO-8859-4.inc remap.inc compose.ISO-8859-10.inc compose.ISO-8859-5.inc I think there's a problem though: if I purge console-setup-mini, I lose the /etc/console-setup/ directory!! # aptitude purge console-setup-mini # /etc/console-setup/ ls: cannot access /etc/console-setup/: No such file or directory It seems that I can (at least partially) fix things up by reinstalling console-setup: # aptitude -t unstable reinstall console-setup # ls /etc/console-setup/ cached.kmap.gz Do you want me to file a separate bug report for this problem? Let's see the generated configuration: # grep -v '^#' /etc/default/console-setup VERBOSE_OUTPUT=no ACTIVE_CONSOLES="/dev/tty[1-6]" CHARMAP="UTF-8" CODESET="Lat15" FONTFACE="TerminusBoldVGA" FONTSIZE="16" XKBMODEL="pc105" XKBLAYOUT="it" XKBVARIANT="" XKBOPTIONS="lv3:ralt_switch" Let's see how it looks like: # setupcon # invoke-rc.d hal restart Restarting Hardware abstraction layer: hald. Result: 'toilet -f future' symbols are *not* correctly shown, but the keyboard layout is Italian as desired (both on the console and in X). Let's try and tweak the configuration: # dpkg-reconfigure console-setup I answered the questions in the following way: Keyboard model? Generic 105-key (Intl) PC Keyboard layout? Italy AltGr key replacement? The default for the keyboard layout Compose key? Menu key Use Control+Alt+Backspace to terminate the X server? No Encoding to use on the console? UTF-8 Character set to support? Latin1 and Latin5 Font for the console? Fixed Font size? 16 Let's see how it worked out: # grep -v '^#' /etc/default/console-setup VERBOSE_OUTPUT=no ACTIVE_CONSOLES="/dev/tty[1-6]" CHARMAP="UTF-8" CODESET="Lat15" FONTFACE="Fixed" FONTSIZE="16" XKBMODEL="pc105" XKBLAYOUT="it" XKBVARIANT="" XKBOPTIONS="compose:menu" Let's test it out: # setupcon # invoke-rc.d hal restart Restarting Hardware abstraction layer: hald. Result: 'toilet -f future' symbols are *not* correctly shown, but the keyboard layout is Italian as desired (both on the console and in X). Let's test the other possible fonts: # vim /etc/default/console-setup After setting FONTFACE to each possible font, I issued the following commands: # setupcon # invoke-rc.d hal restart Restarting Hardware abstraction layer: hald. None of available fontfaces satisfies me. BTW, I think the reference to Goha and GohaClassic in the conffile comments is obsolete, as no such fonts seem to exist now. Do you want me to file a separate bug report for this minor issue? I added the following line to /etc/default/console-setup FONT="lat1u-16.psf.gz" and set the following variables to empty strings: FONTFACE="" FONTSIZE="" After issuing # setupcon # invoke-rc.d hal restart Restarting Hardware abstraction layer: hald. I finally get the fonts I wanted to get and an Italian layout (both on the console and in X). Thanks for the help! -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpikyl9K6QgT.pgp Description: PGP signature
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
On Wed, 18 Nov 2009 22:16:22 +0200 Anton Zinoviev wrote: > Hello! > > I really appreciate you efforts to report everything relevant in the bug > tracking system. I am glad you find my efforts useful! :-) > > On Sat, Nov 14, 2009 at 01:03:37AM +0100, Francesco Poli wrote: > > > > I got the following error: > > > > /var/lib/dpkg/info/console-setup.postinst: line 115: > > /etc/console-setup/cached.kmap.gz: No such file or directory > > This means the directory /etc/console-setup didn't exist. As it is part > of the package console-setup-mini I suppose this was caused by previous > errors. Not really. It was caused by the fact that I purged console-setup-mini, as I later found out and reported! [...] > On Sun, Nov 15, 2009 at 12:29:13PM +0100, Francesco Poli wrote: [...] > > I think there's a problem though: if I purge console-setup-mini, I lose > > the /etc/console-setup/ directory!! > > You are right! Hopefuly with the new version of console-setup (1.47) > there are no shared configuration files so there will be no problems of > this sort any more. > > > Do you want me to file a separate bug report for this problem? > > I believe it is fixed in 1.47. If you find a problem in version 1.47 or > following, do not hesitate to report it. I upgraded to version 1.47 last night: I reconfigured console-setup and keyboard-setup and tested the beast... It seems to work as I want it to. As soon as I find the time to migrate other boxes from console-setup-mini to console-setup, I will check if everything is OK: should something go wrong, I will report to the BTS, as appropriate. [...] > > I added the following line to /etc/default/console-setup > > > > FONT="lat1u-16.psf.gz" > > > > and set the following variables to empty strings: > > > > FONTFACE="" > > FONTSIZE="" > > I suppose it wasn't necessary to put empty strings here. Actually, I don't know if this last change was necessary: it just looked like the "right" thing to do, hence I did so without checking if it was really needed... ;-) > > > After issuing > > > > # setupcon > > # invoke-rc.d hal restart > > Restarting Hardware abstraction layer: hald. > > > > I finally get the fonts I wanted to get and an Italian layout (both > > on the console and in X). > > I don't know why the fonts in console-setup didn't work for you (as I > don't use toilet) It should be easy to see for yourself: I suggest you to install toilet # aptitude install toilet and then try it out: $ toilet -f future "hello, world" Please compare the result of this command in X (inside a properly configured UTF-8 capable terminal) and on a console with any of the main fonts (Fixed, Terminus, and so forth). > but I am glad that with lat1u-16 finaly everything is > ok. :) Well, everything works as before... I wish the Linux console fully supported Unicode (UTF-8), but that's another story (see bug #500403). Bye. P.S.: Thank you so much for your explanations (even for those that I cut in my reply). -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpwSxYXXQCT0.pgp Description: PGP signature
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
On Thu, 19 Nov 2009 18:56:59 +0200 Anton Zinoviev wrote: > On Wed, Nov 18, 2009 at 11:13:57PM +0100, Francesco Poli wrote: > > > > > I don't know why the fonts in console-setup didn't work for you (as I > > > don't use toilet) > > > > It should be easy to see for yourself: I suggest you to install toilet > > > > # aptitude install toilet > > > > and then try it out: > > Now I see. Excellent! ;-) > > Well, the fonts in console-setup are produced automatically, so maybe it > will be possible to support at least some of the symbols used by toilet This sounds as good news indeed (even though it doesn't mean the console will get full Unicode support/coverage, or am I wrong?). :-) > Where can I find a list of the symbols that the fonts in console-setup > need to support? As far as the toilet "future" font is concerned, you may wish to take a look at its complete definition in /usr/share/figlet/future.tlf (shipped in package toilet-fonts)... -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp0VnXUMaYO0.pgp Description: PGP signature
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
On Sun, 22 Nov 2009 15:32:25 +0200 Anton Zinoviev wrote: > On Fri, Nov 20, 2009 at 12:47:41AM +0100, Francesco Poli wrote: > > > > > Where can I find a list of the symbols that the fonts in console-setup > > > need to support? > > > > As far as the toilet "future" font is concerned, you may wish to take a > > look at its complete definition in /usr/share/figlet/future.tlf > > (shipped in package toilet-fonts)... > > Version 4.30-2 of console-terminus and version 1.49 of console-tools > contain fonts that can display the characters in "future" by using > approximations. Wow! That's great! :-) I've just tested all the "standard" fonts (Fixed, Terminus, TerminusBold, TerminusBoldVGA, VGA): they are all able to display 'toilet -f future' symbols in a strange, yet charming way! I really like the result: I finally chose TerminusBoldVGA as my favorite font. Thank you very, very much for this console enhancement! :-) > Because of this your font (lat9u) is still better. I tend to disagree: I now prefer TerminusBoldVGA! ;-) Actually, lat1u-16.psf.gz was a compromise solution for me, since it was the only way I had to actually display 'toilet -f future' symbols in a legible manner, but I wasn't really satisfied with the result... Your "approximations" of 'toilet -f future' symbols with "standard" fonts (especially with TerminusBoldVGA) really look futuristic and great! ;-) Thank you again. Bye. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpVCeJS1q5rI.pgp Description: PGP signature
Bug#561008: console-setup: approximations for 'toilet -f future' symbols look different before and after X
On Mon, 14 Dec 2009 16:19:55 +0200 Anton Zinoviev wrote: > On Sun, Dec 13, 2009 at 05:35:38PM +0100, Francesco Poli (t1000) wrote: [...] > > If I switch back to the console (by pressing [Ctrl+Alt+F1]) and I login > > again, then the output of > > > > $ toilet -f future hello [...] > > looks different! > > Can you use the command 'showconsolefont' in order to see whether the > font is changed after you return to the console or the font is the same > but it is displayed in a different way? No, I cannot: this command belongs to the kbd package, but I do not have this package installed on any of the Debian boxes I use. This holds even for the most recently installed box (about 1 month old), apparently because $ aptitude why console-tools i acpi-support-base Depends console-tools | console-utilities and hence the console-terminus recommendation was already satisfied by console-tools: $ aptitude why kbd i console-setupDependsconsole-terminus (>= 4.26) i A console-terminus Recommends kbd | console-tools Should I switch from console-tools to kbd, in your opinion? Or is there an equivalent command in console-tools? > > Does the look of 'toilet -f future hello' restore if you use the command > 'setupcon'? No, it doesn't. After issuing the 'setupcon' command (as root), the look stays the same (broken lines). -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpDTz0s4QIhe.pgp Description: PGP signature
Bug#561008: console-setup: approximations for 'toilet -f future' symbols look different before and after X
On Mon, 14 Dec 2009 23:02:53 +0200 Anton Zinoviev wrote: > On Mon, Dec 14, 2009 at 08:08:12PM +0100, Francesco Poli wrote: > > > > No, I cannot: this command belongs to the kbd package, but I do not > > have this package installed on any of the Debian boxes I use. > > > > Should I switch from console-tools to kbd, in your opinion? > > Console-tools has several bugs that are not going to be fixed, it > doesn't have upstream maintainer. On the other hand Kbd is actively > maintained (both in Debian and by the upstream). Thats why the future > versions of Debian are going to use Kbd instead of console-tools. That's useful news, thanks: I now begin to remember reading some similar considerations, but it was long ago and I had forgotten... :-( I'll probably try and switch to kbd, as soon as I find some time to do so. [...] > > Or is there an equivalent command in console-tools? > > The equivalent command is 'showcfont' but it doesn't work on my machine > (outdated version of Debian unstable). I had tried with 'showcfont', but I thought it didn't do what you wanted. Instead of telling me the name of the used font (as I expected), it wrote a complete table with all the gliphs and codes. Well, I am not able to be sure the font has not changed, just by looking at this table! > > > > Does the look of 'toilet -f future hello' restore if you use the command > > > 'setupcon'? > > > > No, it doesn't. > > After issuing the 'setupcon' command (as root), the look stays the same > > (broken lines). > > I suppose that only the horizontal lines are broken (the vertical are > OK)? Bingo! You guessed! Does this help? Sorry for not saying it explicitly before... > Can you use the command 'consolechars -f FONTNAME' in order to > make sure that the other fonts (both in console-setup and console-data) > have the same problem. In particular can you see whether the fonts that > you used before console-setup are also with broken lines? I've just tested the following commands: $ consolechars -f Lat15-Fixed16 $ consolechars -f Lat15-Terminus16 $ consolechars -f Lat15-TerminusBold16 $ consolechars -f Lat15-TerminusBoldVGA16 $ consolechars -f Lat15-VGA16 $ consolechars -f lat1u-16 All these fonts share the problem. As far as lat1u-16 is concerned, please note that it has always had this problem (broken horizontal lines): that's why I labeled it as a "compromise solution". With TerminusBoldVGA the problem doesn't show up before starting X, hence I was astonished to see it come back, as soon as I started X and switched back to the console! P.S.: Anton, I cannot stress enough how I appreciate your quick and helpful replies; your dedication to the improvement of console-setup and your assistance for users are really great! :-) -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpsnSa3X3bYg.pgp Description: PGP signature
Bug#561008: console-setup: approximations for 'toilet -f future' symbols look different before and after X
On Tue, 15 Dec 2009 20:45:35 +0200 Anton Zinoviev wrote: > On Mon, Dec 14, 2009 at 11:01:38PM +0100, Francesco Poli wrote: [...] > > I had tried with 'showcfont', but I thought it didn't do what you > > wanted. Instead of telling me the name of the used font (as I > > expected), it wrote a complete table with all the gliphs and codes. > > > > Well, I am not able to be sure the font has not changed, just by > > looking at this table! > > Yes, if the font is the same you can not be sure that it has not > changed but sometimes if it has changed you can be sure that it has > changed. :) > > In your case the font has not changed, so there is no need of more > tests. OK... > > > > I suppose that only the horizontal lines are broken (the vertical > > > are OK)? > > > > Bingo! > > You guessed! > > Then it seems this bug must be reassigned to some of the x server > video drivers. What is the type of your videocard? I took a look at the different boxes I administer: I experience this problem on two machines with Intel integrated graphics (driver xserver-xorg-video-intel/2:2.9.1-1), but *not* on an old laptop with an S3 ProSavage KN133 integrated graphics chip (driver xserver-xorg-video-savage/1:2.3.0-1). It seems that this issue is intel-graphics-specific. > Can you attach > the contents of /var/log/Xorg.0.log Do you need a log file that was updated during the [Ctrl+Alt+F1] switch? Or just a simple log file, as it is as soon I open an X session? > What happens if you don't use Ctrl+Alt+F1 but rather exit X the > normal way? I experience the same bug, after closing my Fluxbox session the usual way. > > In order to work with 9x16 and 9x14 fonts the video card does a > magic: for some of the symbols (the pseudographic symbols) it uses > the 8-th bit in each line as 9-th bit. This magic is due to the fact > that even the most modern cards are emulating the old VGA hardware > that was developed 20 years ago when only the 8-bit technologies were > cheap. Somehow X leaves the videocard in a mode when it doesn't use > the 8-th bit as 9-th and leaves the 9-th bit empty. Hence, it seems that this bug should be fixed in xserver-xorg-video-intel. If this is the case, I think the bug report should be reassigned to package xserver-xorg-video-intel, version 2:2.9.1-1 . > > > As far as lat1u-16 is concerned, please note that it has always had > > this problem (broken horizontal lines): that's why I labeled it as a > > "compromise solution". > > I suppose this was because of the way this font was loaded. I think > if you put FONT='lat1u-08.psf.gz' in /etc/default/console-setup the > lines will not be broken. I've just tried with FONT='lat1u-08.psf.gz' in /etc/default/console-setup, and then with FONT='lat1u-16.psf.gz' . I see horizontally broken pseudo-graphic symbols with both of them. > > If you start using framebuffer all lines will display correctly but > the console will use 8x16 and 8x14 fonts instead of 9x16 and 9x14. I > don't know how the problem you are experiencing can be fixed in the > regular text mode. I am quite ignorant about framebuffer consoles (and about framebuffer in general, for that matter...). What are the pros and cons of a framebuffer console? Is it difficult to configure the system so that it uses a framebuffer console? -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpF2P2VgcfTK.pgp Description: PGP signature
Bug#561008: console-setup: approximations for 'toilet -f future' symbols look different before and after X
On Fri, 18 Dec 2009 23:49:36 +0100 Francesco Poli wrote: > On Tue, 15 Dec 2009 20:45:35 +0200 Anton Zinoviev wrote: > > > On Mon, Dec 14, 2009 at 11:01:38PM +0100, Francesco Poli wrote: [...] > > > > > > I suppose that only the horizontal lines are broken (the vertical > > > > are OK)? > > > > > > Bingo! > > > You guessed! > > > > Then it seems this bug must be reassigned to some of the x server > > video drivers. What is the type of your videocard? > > I took a look at the different boxes I administer: I experience this > problem on two machines with Intel integrated graphics (driver > xserver-xorg-video-intel/2:2.9.1-1), but *not* on an old laptop with an > S3 ProSavage KN133 integrated graphics chip (driver > xserver-xorg-video-savage/1:2.3.0-1). > > It seems that this issue is intel-graphics-specific. [...] > > In order to work with 9x16 and 9x14 fonts the video card does a > > magic: for some of the symbols (the pseudographic symbols) it uses > > the 8-th bit in each line as 9-th bit. This magic is due to the fact > > that even the most modern cards are emulating the old VGA hardware > > that was developed 20 years ago when only the 8-bit technologies were > > cheap. Somehow X leaves the videocard in a mode when it doesn't use > > the 8-th bit as 9-th and leaves the 9-th bit empty. > > Hence, it seems that this bug should be fixed in > xserver-xorg-video-intel. If this is the case, I think the bug report > should be reassigned to package xserver-xorg-video-intel, version > 2:2.9.1-1 . Do you want me to reassign the bug report to xserver-xorg-video-intel/2:2.9.1-1 ? -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJhxoSDC15R.pgp Description: PGP signature
Bug#561008: console-setup: approximations for 'toilet -f future' symbols look different before and after X
On Thu, 14 Jan 2010 15:07:55 +0200 Anton Zinoviev wrote: > On Wed, Jan 06, 2010 at 06:40:25PM +0100, Francesco Poli wrote: > > > > > > Hence, it seems that this bug should be fixed in > > > xserver-xorg-video-intel. If this is the case, I think the bug report > > > should be reassigned to package xserver-xorg-video-intel, version > > > 2:2.9.1-1 . > > > > Do you want me to reassign the bug report to > > xserver-xorg-video-intel/2:2.9.1-1 ? > > The good news is I was able to reproduce the broken lines on my machine > (it has intel video) and I am sure there is a regression bug somewhere > in the X server. The bad news is I failed to notice after which upgrade > this happened. Well, that's progress, anyway: thank you very much for further investigating this issue! :) [...] > I have absolutely no explanation why the fonts in console-setup look > good while lat1u-16.psf.gz and lat1u-08.psf.gz have always broken > horizontal lines (even without X). Can you try the following: > > 1. Configure the console with the fonts of console-setup. Make sure the > lines look OK. > > 2. setfont lat1u-16.psf.gz > > 3. Test the lines with toilet. > > On my machine the fonts of console-setup and the fonts of console-data > are either all good or all with broken lines. You are right, sorry! I have just performed the test you requested, and I can confirm that lat1u-16.psf.gz is OK (without X). I really can't understand why I was convinced that lat1u-16.psf.gz was always broken: I probably failed to recall correctly... :-( -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJGmeoCSkZm.pgp Description: PGP signature
Bug#701493: installation-reports: successful installation on an Acer TravelMate P253, but fstab had to be fixed
On Sat, 23 Feb 2013 20:17:55 +0100 Francesco Poli (wintermute) wrote: [...] > After booting the installed system, I noticed that the /etc/fstab > needed to be fixed by hand. [...] I forgot to mention that this bug looks similar to #609716, but it is not exactly the same... I experienced #609716 in the past, and that's the reason why I checked the /etc/fstab file immediately after booting the newly installed system. But what I have just experienced is a slightly different bug, or maybe it's the current incarnation of bug #609716 (sometimes bugs evolve with time!). I hope this additional information may be useful to pinpoint the problem. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpQMS17cjW2G.pgp Description: PGP signature
Bug#546983: console-setup-mini: fails to set the keyboard layout (and falls back to "us" layout)
Package: console-setup-mini Version: 1.44 Severity: important Hi! I upgraded my Debian testing (squeeze) notebook yesterday and various packages were upgraded (among which several xorg packages). Due to dependencies, console-setup-mini was pulled in, as confirmed by /var/log/aptitude : [INSTALL, DEPENDENCIES] console-setup-mini During the configuration step, various debconf questions were asked: I tried hard to reply reasonably. Today, I booted up the notebook and logged in on the console (I do not use any graphical login manager) and noticed that the keyboard layout was set to US, while my notebook has an Italian keyboard (buying a notebook with a US keyboard is close to impossible down here in Italy...). I thought I messed up with debconf questions, hence I re-ran: # dpkg-reconfigure console-setup-mini The resulting configuration is shown below and translates into the following conffile: $ grep -v '^#\|^$' /etc/default/console-setup VERBOSE_OUTPUT=no ACTIVE_CONSOLES="/dev/tty[1-6]" CHARMAP="UTF-8" CODESET="Lat15" FONTFACE="VGA" FONTSIZE="16" XKBMODEL="pc105" XKBLAYOUT="it" XKBVARIANT="" XKBOPTIONS="" Despite XKBLAYOUT is clearly set to "it", I still get a US keyboard map on the console (X is fine, instead). I even tried to upgrade to console-setup-mini/1.45 from unstable and I even rebooted the notebook, just in case... Nothing changed: still US layout, no matter what! I tried to issue the following command (going from memory, since the last time I needed to *manually* set the keyboard layout was some 7 or 8 years ago!): $ loadkeys it Loading /usr/share/keymaps/i386/qwerty/it.kmap.gz Keymap 0: Permission denied Keymap 1: Permission denied Keymap 2: Permission denied KDSKBENT: Operation not permitted loadkeys: could not deallocate keymap 3 As you can see, it didn't work. Please help! I really cannot understand why setting a non-US keyboard layout has suddenly become *so* hard in Debian testing! What's wrong with my notebook? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages console-setup-mini depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy Versions of packages console-setup-mini recommends: ii console-tools 1:0.2.3dbs-66 Linux console and font utilities Versions of packages console-setup-mini suggests: ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip -- debconf information: * console-setup/variant: Italy console-setup/unsupported_options: true * console-setup/ctrl_alt_bksp: false console-setup/modelcode: pc105 console-setup/use_system_font: console-setup/fontsize: 16 console-setup/unsupported_layout: true console-setup/layoutcode: it console-setup/codesetcode: Lat15 * console-setup/altgr: The default for the keyboard layout * console-setup/codeset: # Latin1 and Latin5 - western Europe and Turkic languages console-setup/toggle: No toggling * console-setup/fontface: VGA * console-setup/fontsize-text: 16 * console-setup/compose: No compose key debian-installer/console-setup-udeb/title: console-setup/other: console-setup/switch: No temporary switch console-setup/unsupported_config_layout: true * console-setup/charmap: UTF-8 console-setup/optionscode: console-setup/unsupported_config_options: true console-setup/layout: console-setup/variantcode: * console-setup/model: console-setup/fontsize-fb: 16 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561005: purging console-setup-mini makes you lose some console-setup configuration
Package: console-setup Version: 1.50 Severity: normal Hi and thanks for maintaining console-setup! On a box where console-setup-mini was installed, I issued the following command: # aptitude install console-setup console-setup-mini- in order to switch from console-setup-mini to console-setup. Some configuration files are present in /etc/console-setup/ : $ ls /etc/console-setup/ cached.kmap.gzcompose.ISO-8859-13.inc compose.ISO-8859-8.inc compose.ARMSCII-8.inc compose.ISO-8859-14.inc compose.ISO-8859-9.inc compose.CP1251.inccompose.ISO-8859-15.inc compose.KOI8-R.inc compose.CP1255.inccompose.ISO-8859-16.inc compose.KOI8-U.inc compose.CP1256.inccompose.ISO-8859-1.inc compose.TIS-620.inc compose.GEORGIAN-ACADEMY.inc compose.ISO-8859-2.inc compose.VISCII.inc compose.GEORGIAN-PS.inc compose.ISO-8859-3.inc Lat15-Fixed16.psf.gz compose.IBM1133.inc compose.ISO-8859-4.inc Lat15-TerminusBold16.psf compose.ISIRI-3342.inccompose.ISO-8859-5.inc remap.inc compose.ISO-8859-10.inc compose.ISO-8859-6.inc compose.ISO-8859-11.inc compose.ISO-8859-7.inc They seem to belong to console-setup-mini: $ dpkg -l | grep ^rc | cut -c 1-60 rc console-setup-mini 1.50 OK, let's purge console-setup-mini, in order to clean the system up: # aptitude purge console-setup-mini Let's check: $ dpkg -l | grep ^rc | cut -c 1-60 $ ls /etc/console-setup/ ls: cannot access /etc/console-setup/: No such file or directory Wait, but that directory has a name that makes me think it should be useful to console-setup... # aptitude reinstall console-setup And now: $ ls /etc/console-setup/ cached.kmap.gz Lat15-Fixed16.psf.gz Hence, after switching from console-setup-mini to console-setup and purging console-setup-mini, some configuration files that seem to be useful for both console-setup-mini and console-setup get lost. This problem was mentioned by me during the discussions of bug #546983, but it seems to be still unfixed. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages console-setup depends on: ii console-terminus 4.30-2 Fixed-width fonts for fast reading ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii keyboard-configuration1.50 system-wide keyboard preferences ii xkb-data 1.7-1 X Keyboard Extension (XKB) configu Versions of packages console-setup recommends: ii console-tools 1:0.2.3dbs-66 Linux console and font utilities Versions of packages console-setup suggests: ii locales 2.10.2-2 GNU C Library: National Language ( ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip -- debconf information excluded -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561008: console-setup: approximations for 'toilet -f future' symbols look different before and after X
Package: console-setup Version: 1.50 Severity: normal Hi (again)! During the discussions for bug #546983, console-setup was greatly improved by Anton Zinoviev (which I would like to thank again): the console is now able to display 'toilet -f future' symbols in a strange, yet charming way, by using "approximations". All "standard" fonts (Fixed, Terminus, TerminusBold, TerminusBoldVGA, VGA) are able to perform this magic. I chose TerminusBoldVGA, as shown below in the debconf settings section. This is really great. I noticed an awkward behavior, though. As soon as the box has finished booting, I login on the console and I see the output of, e.g.: $ toilet -f future hello ╻ ╻┏━╸╻ ╻ ┏━┓ ┣━┫┣╸ ┃ ┃ ┃ ┃ ╹ ╹┗━╸┗━╸┗━╸┗━┛ displayed correctly. I mean, the letters don't have the same height, but that's OK (it even somehow enhance the futuristic look of this toilet font!), but each letter is displayed with lines that join perfectly and form a continuous gliph. OK, after that, I start an X session: $ startx & logout If I switch back to the console (by pressing [Ctrl+Alt+F1]) and I login again, then the output of $ toilet -f future hello ╻ ╻┏━╸╻ ╻ ┏━┓ ┣━┫┣╸ ┃ ┃ ┃ ┃ ╹ ╹┗━╸┗━╸┗━╸┗━┛ looks different! I mean, each letter is displayed with lines that fail to join perfectly and thus form a discontinous gliph (as if made of "broken" pieces). This is less nice than before, but the point is: why does it look different?!? I hope this little flaw is easy to fix... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages console-setup depends on: ii console-terminus 4.30-2 Fixed-width fonts for fast reading ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii keyboard-configuration1.50 system-wide keyboard preferences ii xkb-data 1.7-1 X Keyboard Extension (XKB) configu Versions of packages console-setup recommends: ii console-tools 1:0.2.3dbs-66 Linux console and font utilities Versions of packages console-setup suggests: ii locales 2.10.2-2 GNU C Library: National Language ( ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip -- debconf information: * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages console-setup/use_system_font: console-setup/fontsize: 16 * console-setup/fontface47: TerminusBoldVGA * console-setup/fontsize-text47: 16 * console-setup/charmap47: UTF-8 console-setup/codesetcode: Lat15 console-setup/fontsize-fb47: 16 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701493: installation-reports: successful installation on an Acer TravelMate P253, but fstab had to be fixed
Package: installation-reports Severity: normal Tags: d-i Hello, I would like to report a successful (well, let's say almost successful) installation, with a single little issue in the auto-generated /etc/fstab file. The issue may be easily fixed by hand, but, still, I think it's caused by a bug: that's why I am reporting it. Thanks a lot for the great job in developing debian-installer: it's getting more and more practical to use. Well done! :-) See below for the details. -- Package-specific info: Boot method: USB stick Image version: http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: 2013-02-23 10:13 MD5SUM of image: a344ded2e4a1895a28b87acda348098b debian-testing-amd64-netinst.iso Machine: Acer TravelMate P253-E-B9602G32Mnks (NX.V7XET.004) Partitions: some partitions and LVM volumes inside /dev/sda, created through manual partitioning; I think the details are not especially relevant Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[O] Comments/Problems: The machine is a Acer TravelMate P253-E-B9602G32Mnks (NX.V7XET.004) laptop. The output of "lspci -n" and of "lspci -vvv" are attached. Overall, the installation went fine. I downloaded the above mentioned debian-installer image today and wrote it to a USB stick with "dd". After configuring the BIOS so that the laptop can boot from USB HDD or USB CDROM, I started the installation process. The Ethernet adapter (Broadcom Corporation NetLink BCM57785 Gigabit Ethernet PCIe) was correctly detected and used as primary network interface. It also seems to work fine after booting the installed system (without any non-free drivers or firmware blobs!). I still have to test the wireless network adapter (Atheros Communications Inc. AR9485 Wireless Network Adapter), but it was correctly detected during the installation and offered as a possible alternative, when choosing the primary network interface. And the ath9k kernel module is automatically loaded on the installed system (the wireless adapter should work without any non-free drivers or firmware blobs, as far as I know!). Please note that I worked around the bug in the GRUB installation, as currently suggested in the errata page: http://www.debian.org/devel/debian-installer/errata In other words, I answered "No" when asked to install GRUB to the MBR, and then explicitly specified "/dev/sda" as device for boot loader installation. I don't know what would have happened, if I had not followed this strategy. After booting the installed system, I noticed that the /etc/fstab needed to be fixed by hand. The last four lines looked like: /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sr1/media/cdrom1 udf,iso9660 user,noauto 0 0 /dev/sdb1 /media/usb0 autorw,user,noauto 0 0 /dev/sdb2 /media/usb1 autorw,user,noauto 0 0 The last three lines should not be present: only the first one (of the above mentioned lines) is correct, since the laptop has only one DVD drive and there is no /dev/sdb (after removing the USB stick...). I manually deleted the last three lines with a text editor. I also had to remove the extraneous mount points: # ls -F /media cdrom@ cdrom0/ cdrom1/ usb@ usb0/ usb1/ # rmdir /media/cdrom1 /media/usb? # rm /media/usb # ls -F /media cdrom@ cdrom0/ I don't know exactly why the fstab file was created that way, but it really looks wrong (even though easy to fix). Please investigate and fix this little bug. Thanks for your time! 00:00.0 0600: 8086:0104 (rev 09) 00:02.0 0300: 8086:0106 (rev 09) 00:16.0 0780: 8086:1e3a (rev 04) 00:1a.0 0c03: 8086:1e2d (rev 04) 00:1b.0 0403: 8086:1e20 (rev 04) 00:1c.0 0604: 8086:1e10 (rev c4) 00:1c.1 0604: 8086:1e12 (rev c4) 00:1d.0 0c03: 8086:1e26 (rev 04) 00:1f.0 0601: 8086:1e5e (rev 04) 00:1f.2 0106: 8086:1e03 (rev 04) 00:1f.3 0c05: 8086:1e22 (rev 04) 02:00.0 0200: 14e4:16b5 (rev 10) 02:00.1 0805: 14e4:16bc (rev 10) 02:00.2 0880: 14e4:16be (rev 10) 02:00.3 0880: 14e4:16bf (rev 10) 03:00.0 0280: 168c:0032 (rev 01) lspci-vvv.out.gz Description: GNU Zip compressed data
