Re: [arch-general] Reboot - Versioned Kernel Installs

[Heiko Baums]

Am Sat, 11 Jun 2011 23:07:00 -0400
schrieb "Joe(theWordy)Philbrook" :

> Actually It's been a long time since I had actual boot failures with
> Arch... And if memory serves it wasn't the updated kernels fault,
> though I no longer remember what I'd done...

You see, those cases in which a kernel update leads to a boot failure
are very rare. ;-)

And Arch Linux kernels are usually tested in [testing] and are only
moved to [core] if there are no bigger issues found.

> However I have
> experienced other Linux that no longer booted properly upon kernel
> upgrades... When my grub installation fails to properly boot one of
> my Linux, I immediately use the chainloader entry to get that
> distro's own grub. Having a back-up in case a new kernel doesn't work
> for me just feels like the right thing to do. And now I know (and
> will have notes) how to resolve that problem in the event that an
> Arch kernel upgrade ever does fail me. Thanks again! 
> ...
> Well I call it grub legacy because that's what gnu.org is calling it
> now...

That's what it's called.

> According to them the old grub has been replaced with a new version.
> Though I don't see it as an improvement. 
> I think the only Distro I've got installed that really likes "grub 2"
> is Ubuntu, But since I didn't let it use ext4, I can still even boot
> that with the classic grub. ☻  

Which bootloader you need depends on your installation and hardware,
not on the distro. There are at least 3 bootloaders (grub legacy, grub2
and syslinux) which have different capabilities and can't easily be
replaced in any case. But all of them can handle ext4.

> I guess you would either call it just a "grub partition" Or perhaps
> you would have said "boot partition" without specifying which boot
> loader is installed there.

I guess you meant the /boot partition. ;-)

> It is not that uncommon among multi-Linux-Distro, multi-booters to
> have a separate bootloader installed to the MBR from the ones each
> distro installed to their root partitions. Though the others I've
> heard about usually just select the appropriate chainloader entry for
> the Linux they want to boot, which in turn usually has a very short
> timeout before it automatically boots it's default entry.
> 
> I myself rarely bother with the chainloader entries. They are mostly
> only there in case I goof when I edit the entries I normally boot
> from. This configuration also makes it easy to use a supergrub disc
> in the event that my normal boot partition gets corrupted as each
> installed Linux has it's own boot loader so all I'd need to tell
> supergrub is to boot the appropriate partition...

I would completely remove the chainloaders.

Make one /boot parition for every distro, but only install one
bootloader from your main distro into the MBR. Don't let the other
distros install a bootloader and just configure the one bootloader to
boot the other distros, too. That's the easiest way which should always
work.

Btw., if you let every distro install a bootloader into the MBR, the
previously installed one will be overwritten. There won't be two
different bootloaders in the MBR.

Depending on what you are doing with your multi-boot system, you
probably should consider using virtualization.

Heiko

Re: [arch-general] Reboot - Versioned Kernel Installs

[Joe(theWordy)Philbrook]

It would appear that on Jun 11, Heiko Baums did say:

> Am Sat, 11 Jun 2011 12:40:36 -0400
> schrieb "Joe(theWordy)Philbrook" :
> 
> > OK so lets see if I understand... I already maintain a manually
> > configured grub legacy partition where each of my installed Linux
> > have both a chainloader menu entry to whichever grub that Linux has
> > installed to /boot on it's root partition, AND a regular menu entry
> > that specified the initrd & vmlinuz that I routinely copy to MY grub
> > partition shortly after any kernel upgrade...
> > 
> > So in the event that the new kernel was effectively broken that on MY
> > hardware neither the chainloaded Arch nor the arch fallback menu
> > entries were able to boot, I could then boot the not yet replaced
> > last known good kernel and initrd directly from MY grub and then from
> > a console root prompt:
> > 
> > «assuming that the following tar.xz file is still there»
> > 
> > pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz
> > 
> > And when I next reboot using the chainloader to where arch has it's
> > grub installed, and selected "Arch Linux" it should boot that kernel
> > with it's initrd AND it's modules would be where it expects them with
> > the result that it should be as fully functioning as it was before
> > pacman upgraded from it???
> 
> Principally, yes.

Thanks!
 
> But are you really sure that it is the updated kernel package and not
> your grub installation or config which causes your boot failures?

Actually It's been a long time since I had actual boot failures with Arch...
And if memory serves it wasn't the updated kernels fault, though I no
longer remember what I'd done... However I have experienced other Linux
that no longer booted properly upon kernel upgrades... When my grub
installation fails to properly boot one of my Linux, I immediately use the
chainloader entry to get that distro's own grub. Having a back-up in case a
new kernel doesn't work for me just feels like the right thing to do.
And now I know (and will have notes) how to resolve that problem in the
event that an Arch kernel upgrade ever does fail me. Thanks again!
 
> Your description sounds pretty weird to me. Above all, what is a grub
> legacy partition and why do you need chainload in grub legacy for
> booting a Linux kernel? And are you sure that grub legacy is the right
> bootloader for your uefi mainboard?

Well I call it grub legacy because that's what gnu.org is calling it now...

http://www.gnu.org/software/grub/grub-legacy.en.html

http://www.gnu.org/software/grub/manual/html_node/Changes-from-GRUB-Legacy.html

«Which incidentally is the kind of grub that Arch is using on my PC»

According to them the old grub has been replaced with a new version. Though
I don't see it as an improvement. 
I think the only Distro I've got installed that really likes "grub 2" is
Ubuntu, But since I didn't let it use ext4, I can still even boot that with
the classic grub. ☻  

I guess you would either call it just a "grub partition" Or perhaps you
would have said "boot partition" without specifying which boot loader is
installed there.

It is not that uncommon among multi-Linux-Distro, multi-booters to have a
separate bootloader installed to the MBR from the ones each distro installed
to their root partitions. Though the others I've heard about usually just
select the appropriate chainloader entry for the Linux they want to boot, which
in turn usually has a very short timeout before it automatically boots it's
default entry.

I myself rarely bother with the chainloader entries. They are mostly only
there in case I goof when I edit the entries I normally boot from. This
configuration also makes it easy to use a supergrub disc in the event that my
normal boot partition gets corrupted as each installed Linux has it's own boot
loader so all I'd need to tell supergrub is to boot the appropriate partition...

-- 
|   ---   ___
|   <0>   <-> Joe (theWordy) Philbrook
|   ^  J(tWdy)P
|~\___/~  <>

Re: [arch-general] Network Config - Fixed IP - ifconfig no longer reports broadcast address?

[David C. Rankin]

On 06/11/2011 06:23 PM, Tom Gundersen wrote:

On Sun, Jun 12, 2011 at 12:59 AM, David C. Rankin
  wrote:

  Bug or feature? After updating rc.conf to contain the new network
configuration for a fixed IP, ifconfig no longer reports the broadcast
address. Using the new config of:


Bug. Fixed in git:
.

-t



Well done :)

--
David C. Rankin, J.D.,P.E.

Re: [arch-general] [signoff] kernel26-2.6.39.1-1

[David C. Rankin]

On 06/10/2011 10:09 AM, Tobias Powalowski wrote:

Hi guys,
please signoff 2.6.39 series for both arches.

Upstream
changes:
http://kernelnewbies.org/LinuxChanges


Signoff both -- But -- Where is the kernel26-2.6.39.1-1-i686.pkg.tar.xz saved 
now? Not in /var/cache/pacman/pkg anymore?


--
David C. Rankin, J.D.,P.E.

Re: [arch-general] Network Config - Fixed IP - ifconfig no longer reports broadcast address?

[Tom Gundersen]

On Sun, Jun 12, 2011 at 12:59 AM, David C. Rankin
 wrote:
>  Bug or feature? After updating rc.conf to contain the new network
> configuration for a fixed IP, ifconfig no longer reports the broadcast
> address. Using the new config of:

Bug. Fixed in git:
.

-t

Re: [arch-general] Network Config - Fixed IP - ifconfig no longer reports broadcast address?

[Richard Schütz]

Am 12.06.2011 00:59, schrieb David C. Rankin:

Guys,

Bug or feature? After updating rc.conf to contain the new network
configuration for a fixed IP, ifconfig no longer reports the broadcast
address. Using the new config of:

interface=eth0
address=192.168.6.14
netmask=255.255.255.0
gateway=192.168.6.13

I get:

17:48 archangel:~> ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA
inet addr:192.168.6.14 Bcast:0.0.0.0 Mask:255.255.255.0
^^
inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:102 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14657 (14.3 Kb) TX bytes:15177 (14.8 Kb)
Interrupt:41 Base address:0x2000

Prior to the change, the broadcast address was correctly reported.

eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA
inet addr:192.168.6.14 Bcast:192.168.6.255 Mask:255.255.255.0
inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:103 errors:0 dropped:0 overruns:0 frame:0
TX packets:139 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14683 (14.3 Kb) TX bytes:15505 (15.1 Kb)
Interrupt:41 Base address:0x2000

If I modify rc.conf and change back to the old format:

# old network config for broadcast address
eth0="eth0 192.168.6.14 netmask 255.255.255.0 broadcast 192.168.6.255"
INTERFACES=(eth0)
gateway="default gw 192.168.6.13"
ROUTES=(gateway)

then the broadcast address is correctly reported again. Is this a bug or
feature?




What says "ip addr show"?

--
Regards,
Richard Schütz

[arch-general] Network Config - Fixed IP - ifconfig no longer reports broadcast address?

[David C. Rankin]

Guys,

  Bug or feature? After updating rc.conf to contain the new network 
configuration for a fixed IP, ifconfig no longer reports the broadcast address. 
Using the new config of:


interface=eth0
address=192.168.6.14
netmask=255.255.255.0
gateway=192.168.6.13

I get:

17:48 archangel:~> ifconfig
eth0  Link encap:Ethernet  HWaddr 00:21:85:1A:8C:FA
  inet addr:192.168.6.14  Bcast:0.0.0.0  Mask:255.255.255.0
  ^^
  inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:102 errors:0 dropped:0 overruns:0 frame:0
  TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:14657 (14.3 Kb)  TX bytes:15177 (14.8 Kb)
  Interrupt:41 Base address:0x2000

Prior to the change, the broadcast address was correctly reported.

eth0  Link encap:Ethernet  HWaddr 00:21:85:1A:8C:FA
  inet addr:192.168.6.14  Bcast:192.168.6.255  Mask:255.255.255.0
  inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:103 errors:0 dropped:0 overruns:0 frame:0
  TX packets:139 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:14683 (14.3 Kb)  TX bytes:15505 (15.1 Kb)
  Interrupt:41 Base address:0x2000

If I modify rc.conf and change back to the old format:

# old network config for broadcast address
eth0="eth0 192.168.6.14 netmask 255.255.255.0 broadcast 192.168.6.255"
INTERFACES=(eth0)
gateway="default gw 192.168.6.13"
ROUTES=(gateway)

then the broadcast address is correctly reported again.  Is this a bug or 
feature?


--
David C. Rankin, J.D.,P.E.

Re: [arch-general] blacklisting/MOD_AUTOLOAD - what drove the change?

[Jan Steffens]

On Sun, Jun 12, 2011 at 12:44 AM, David C. Rankin
 wrote:
> Guys,
>
>  Just curious for the reason behind the changes to blacklisting and
> MOD_AUTOLOAD.  What drove the change?
>
> --
> David C. Rankin, J.D.,P.E.
>

Going with what upstream does. The module-init-tools already provide
blacklisting. Also, the overhead of the shellscript we used to provide
our own blacklisting added a few seconds to boot time.

[arch-general] blacklisting/MOD_AUTOLOAD - what drove the change?

[David C. Rankin]

Guys,

  Just curious for the reason behind the changes to blacklisting and 
MOD_AUTOLOAD.  What drove the change?


--
David C. Rankin, J.D.,P.E.

Re: [arch-general] Reboot - Versioned Kernel Installs

[Paul Gideon Dann]

On Friday 10 June 2011 20:44:16 Mauro Santos wrote:
> Arch users have lived without the last good known kernel so far and
> without an -lts kernel until recently. IMHO it is a lot more advisable
> to have an install cd/usb, or even better, a custom install in some
> external media that can be used to boot the system in case something
> goes wrong or in case of emergency. Then you can just chroot into the
> broken install and fix the problem or tell pacman where the root and
> cache are located and fix things.

To me, that just doesn't sound like a sensible rescue plan for a modern OS.  I 
like tinkering and learning, but being forced to boot a CD, load dm-mod, bring 
up my LVM volumes, mount the root, bind proc, sys, and dev, chroot, and finally 
get pacman to install the last kernel?  That's something I'd like to avoid 
unless I'm doing it for fun :)

Paul

Re: [arch-general] Reboot - Versioned Kernel Installs

[Heiko Baums]

Am Sat, 11 Jun 2011 12:40:36 -0400
schrieb "Joe(theWordy)Philbrook" :

> OK so lets see if I understand... I already maintain a manually
> configured grub legacy partition where each of my installed Linux
> have both a chainloader menu entry to whichever grub that Linux has
> installed to /boot on it's root partition, AND a regular menu entry
> that specified the initrd & vmlinuz that I routinely copy to MY grub
> partition shortly after any kernel upgrade...
> 
> So in the event that the new kernel was effectively broken that on MY
> hardware neither the chainloaded Arch nor the arch fallback menu
> entries were able to boot, I could then boot the not yet replaced
> last known good kernel and initrd directly from MY grub and then from
> a console root prompt:
> 
> «assuming that the following tar.xz file is still there»
> 
> pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz
> 
> And when I next reboot using the chainloader to where arch has it's
> grub installed, and selected "Arch Linux" it should boot that kernel
> with it's initrd AND it's modules would be where it expects them with
> the result that it should be as fully functioning as it was before
> pacman upgraded from it???

Principally, yes.

But are you really sure that it is the updated kernel package and not
your grub installation or config which causes your boot failures?

Your description sounds pretty weird to me. Above all, what is a grub
legacy partition and why do you need chainload in grub legacy for
booting a Linux kernel? And are you sure that grub legacy is the right
bootloader for your uefi mainboard?

Heiko

Re: [arch-general] Reboot - Versioned Kernel Installs

[Joe(theWordy)Philbrook]

It would appear that on Jun 11, Heiko Baums did say:

> Am Fri, 10 Jun 2011 21:21:17 -0400
> schrieb "Joe(theWordy)Philbrook" :
> 
> > Mind specifying for an idiot like me just which package-file-names
> > I'd need to use with pacman -U to restore the previous kernel,
> > complete with it's modules?
> 
> Try `ls /var/cache/pacman/pkg/kernel26*` and I guess you will find it.

OK so lets see if I understand... I already maintain a manually configured grub
legacy partition where each of my installed Linux have both a chainloader menu
entry to whichever grub that Linux has installed to /boot on it's root
partition, AND a regular menu entry that specified the initrd & vmlinuz that
I routinely copy to MY grub partition shortly after any kernel upgrade...

So in the event that the new kernel was effectively broken that on MY
hardware neither the chainloaded Arch nor the arch fallback menu entries
were able to boot, I could then boot the not yet replaced last known good
kernel and initrd directly from MY grub and then from a console root prompt:

«assuming that the following tar.xz file is still there»

pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz

And when I next reboot using the chainloader to where arch has it's grub
installed, and selected "Arch Linux" it should boot that kernel with it's
initrd AND it's modules would be where it expects them with the result that
it should be as fully functioning as it was before pacman upgraded from it???

-- 
|  ~^~   ~^~
|Joe (theWordy) Philbrook
|  ^J(tWdy)P
|\___/ <>

Re: [arch-general] Dejavu sans mono fonts rendering issue.

[Yclept Nemo]

On Sat, Jun 11, 2011 at 8:36 AM, Jan Steffens  wrote:
> On Sat, Jun 11, 2011 at 9:43 AM, mwnn  wrote:
>> The following .fonts.conf file did the trick:
>> ...
> The slackware screenshot looks more like:
> ..

hehe, I must say I did not notice any significant difference aside
from font and background color.

Re: [arch-general] [arch-announce] Deprecation of net-tools

[Tom Gundersen]

Hi Rémy,

On Sat, Jun 11, 2011 at 4:56 PM, Rémy Oudompheng
 wrote:
> I will need testers for the various patches I merged from the bug
> tracker, notably IPv6. Any comments on the suggested implementation
> are welcome.

Great to hear that you are working on this! My two cents:

I noticed you made a change to the state dir. Maybe worth also moving
it from /var/run to /run?

To avoid hassle with changing network backend in the future, it might
be worth trying to avoid config variables that are passed to the
backend without parsing (don't know if this has been, or will be
added, just something that caused trouble in initscripts).

-t

Re: [arch-general] [arch-announce] Deprecation of net-tools

[Rémy Oudompheng]

On 2011/6/10 James Rayner  wrote:
> netcfg has an option that runs ip/iproute with any custom option
> (routes, IPs anything), the option is "IPCFG". It may be seen in the
> example ethernet-iproute[1].
>
> IFCFG is the obscure command you mention, unfortunately it's not too
> obscure, as this was how static IPs were set before iproute
> configuration was added. It was retained for backwards compatibility.
>
> The only reason net-tools was still a requirement was setting hostname.
> A change similar to initscripts [2] at line 121 of
> src/connections/ethernet [3] would suffice.
>
> After that it ought to be safe to make net-tools an optional dependency.
> Systems already using net-tools will keep functioning, and a notice
> could be placed in code that handles IFCFG to advise those users to
> migrate to the iproute configuration.
>

I will add some warning about IFCFG. I made the needed change for
hostname and the next release will set net-tools to be optional.

I will need testers for the various patches I merged from the bug
tracker, notably IPv6. Any comments on the suggested implementation
are welcome.

-- 
Rémy.

Re: [arch-general] Dejavu sans mono fonts rendering issue.

[Jan Steffens]

On Sat, Jun 11, 2011 at 9:43 AM, mwnn  wrote:
> The following .fonts.conf file did the trick:
> 
> 
> 
>  
>  
>   none
>  
>  
>  
>  
>   false
>  
>  
>  
>  
>   hintnone
>  
>  
>  
>  
>   true
>  
>  
> 

The slackware screenshot looks more like:



 
 
  rgb
 
 
 
 
  true
 
 
 
 
  hintslight
 
 
 
 
  true
 
 

Re: [arch-general] EveryDNS compulsory migration to Dyn

[Jan de Groot]

On Sat, 2011-06-11 at 10:16 +0800, Abdul Halim wrote:
> I can't help but notice that ArchLinux is using EveryDNS for its DNS server.
> And since I also use EveryDNS DNS server, what is the plan for
> ArchLinux domain administrator since EveryDNS users need to migrate to
> Dyn by 31-Aug-2011?
> Will the administrator use the paid service or something else?

We're already working on that issue. Don't know what will be decided,
but we'll migrate to a working solution before that date. Could be Dyn,
but could be some other host too. Money isn't such a big issue, we've
donated to EveryDNS before to get additional features also.

Re: [arch-general] On module blacklisting

[Heiko Baums]

Am Sat, 11 Jun 2011 12:16:54 +0300
schrieb cantabile :

> On 06/11/2011 11:55 AM, Philipp Überbacher wrote:
> > Another thing, is it still possible to have the rc.conf network
> > stuff as a one-liner or is this new format required? I just need to
> > switch between dhcp and a static address from time to time and a
> > one liner is more convenient to comment/uncomment.
> >
> 
> Sounds like a job for netcfg profiles. ;)

Or networkmanager. ;-)

Heiko

Re: [arch-general] On module blacklisting

[cantabile]

On 06/11/2011 11:55 AM, Philipp Überbacher wrote:

Another thing, is it still possible to have the rc.conf network stuff as
a one-liner or is this new format required? I just need to switch
between dhcp and a static address from time to time and a one liner is
more convenient to comment/uncomment.



Sounds like a job for netcfg profiles. ;)

--
cantabile

"Jayne is a girl's name." -- River

Re: [arch-general] On module blacklisting

[Dieter Plaetinck]

On Sat, 11 Jun 2011 10:55:35 +0200
Philipp Überbacher  wrote:

> Excerpts from Tom Gundersen's message of 2011-06-11 02:22:56 +0200:
> > Hi Magnus,
> > 
> > On Sat, Jun 11, 2011 at 2:11 AM, Magnus Therning  
> > wrote:
> > > 1. As I read it, it's only blacklisting that's affected, is that
> > >   correct?
> > 
> > Correct.
> > 
> > >   So MODULES in rc.conf can in the future only be used to load
> > >   modules at boot-up.
> > 
> > Correct.
> > 
> > > (Is there even a way to configure modprobe to
> > >   load modules on boot?)
> > 
> > No (that's why we need to keep this in rc.conf).
> 
> It was a lot nicer to have loading and blacklisting in one place though.
> I like Arch in part for the simplicity of its configuration and
> spreading out config files doesn't help.
> I also think that the Arch blacklisting semantics were better, but I'm
> not sure they actually worked as intended.
> 
> Another thing, is it still possible to have the rc.conf network stuff as
> a one-liner or is this new format required? I just need to switch
> between dhcp and a static address from time to time and a one liner is
> more convenient to comment/uncomment.
> 

it's bash you know.

you=can; define=variables; like=this

if you want everything on one line.

Re: [arch-general] On module blacklisting

[Philipp Überbacher]

Excerpts from Tom Gundersen's message of 2011-06-11 02:22:56 +0200:
> Hi Magnus,
> 
> On Sat, Jun 11, 2011 at 2:11 AM, Magnus Therning  wrote:
> > 1. As I read it, it's only blacklisting that's affected, is that
> >   correct?
> 
> Correct.
> 
> >   So MODULES in rc.conf can in the future only be used to load
> >   modules at boot-up.
> 
> Correct.
> 
> > (Is there even a way to configure modprobe to
> >   load modules on boot?)
> 
> No (that's why we need to keep this in rc.conf).

It was a lot nicer to have loading and blacklisting in one place though.
I like Arch in part for the simplicity of its configuration and
spreading out config files doesn't help.
I also think that the Arch blacklisting semantics were better, but I'm
not sure they actually worked as intended.

Another thing, is it still possible to have the rc.conf network stuff as
a one-liner or is this new format required? I just need to switch
between dhcp and a static address from time to time and a one liner is
more convenient to comment/uncomment.

Re: [arch-general] Dejavu sans mono fonts rendering issue.

[mwnn]

On Sat, Jun 11, 2011 at 12:26 PM, mwnn  wrote:
> On Sat, Jun 11, 2011 at 12:18 PM, Rémy Oudompheng
>  wrote:
>> On 2011/6/11 mwnn  wrote:
>>> Hi,
>>>
>>>   I am unable to configure fonts on my new arch linux system. The
>>> fonts from the old slackware installation are similar to
>>> http://i.imgur.com/UcwHS.png. The new arch linux fonts look like
>>> http://imageshack.us/photo/my-images/695/newemacs.jpg/
>>
>> Hello,
>>
>> You do not seem to have a question or a problem that people might try
>> to solve. Do you have any?
>>
>> Regards,
>> Rémy.
>>
>
> The Slackware fonts are much thicker than the one on Arch. Would like
> to know how I can configure the fonts on Arch to look similar to
> Slackware. I have read Archwiki's Fontconfig entry and tried setting
> various configurations in ~/.fonts.conf. BTW the issue appears only in
> Emacs  and GVIM. Firefox, for example, renders fonts correctly.
>
> P.S: I am using icewm as my window manager and xdm as my display manager.
>

The following .fonts.conf file did the trick:



 
  
   none
  
 
 
  
   false
  
 
 
  
   hintnone
  
 
 
  
   true