Recommended memory size for F19?

[Joachim Backes]

Dear developers,

I was running F18 on an old notebook with 512 MB memory (not
extendable). Now, I upgraded this box to F19 with yum. The upgrade was
done, but now, the box is no more operable because it is continuously
swapping.

Question: which minimal memory size is recommended for F19?

Kind regards

Joachim Backes
-- 

Fedora release 18 (Spherical Cow): Kernel-3.8.6-203.fc18.x86_64

Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
https://www-user.rhrk.uni-kl.de/~backes

[Kevin Fenzi]

On Wed, 10 Apr 2013 13:26:48 +0200
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt; wrote:

>  Dear developers,
>  
>  I was running F18 on an old notebook with 512 MB memory (not
>  extendable). Now, I upgraded this box to F19 with yum. The upgrade was
>  done, but now, the box is no more operable because it is continuously
>  swapping.
>  
>  Question: which minimal memory size is recommended for F19? 
We don't know yet, as f19 hasn't been released. ;) 

There's still debugging options enabled on the kernel, but I wouldn't
think that would cause 'continuously swapping'. Can you use top/ps/etc
to identify which thing is using up memory?

You could also try booting with 'slub_debug=-' or using a rawhide no
debug kernel: 
http://fedoraproject.org/wiki/RawhideKernelNodebug

kevin

[Adam Williamson]

On 10/04/13 08:53 AM, Kevin Fenzi wrote:
>  On Wed, 10 Apr 2013 13:26:48 +0200
>  Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt; wrote:
>
> > Dear developers,
> >
> > I was running F18 on an old notebook with 512 MB memory (not
> > extendable). Now, I upgraded this box to F19 with yum. The upgrade was
> > done, but now, the box is no more operable because it is continuously
> > swapping.
> >
> > Question: which minimal memory size is recommended for F19?
>
>  We don't know yet, as f19 hasn't been released. ;)
>
>  There's still debugging options enabled on the kernel, but I wouldn't
>  think that would cause 'continuously swapping'. 
I think debug kernels actually do result in substantially increased 
memory usage, for some reason. Certainly, Alphas always seem to need 
more RAM for a successful install than Betas and Finals.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Fedora 19 Alpha RC2 UEFI Fail

[Brian Fagioli]

Fails at Grub. Missing file. En.mo.gz

Brian Fagioli
Linuxtester(a)yandex.com

-- 
Sent from Yandex.Mail for mobile: http://m.ya.ru/ymail

Fedora 19 Alpha RC2 UEFI Fail

[John Reiser]

>  Fails at Grub. Missing file. En.mo.gz 
That message probably is just informative, and not the cause of
failing to boot.  The same message occurs in many successful
boots of current release Fedora 18.

Right now the suspected culprit of failing to boot Fedora 19
is somewhere in passing control of the active video graphics
from one stage to the next.

--

Fedora 19 Alpha RC2 UEFI Fail

[Brian Fagioli]

When I installed it on the same machine without UEFI, it booted fine. Running it now.

10.04.13, 20:47, "John Reiser" <jreiser(a)bitwagon.com&gt;&quot;:
>  
>  > Fails at Grub. Missing file. En.mo.gz
>  
>  That message probably is just informative, and not the cause of
>  failing to boot.  The same message occurs in many successful
>  boots of current release Fedora 18.
>  
>  Right now the suspected culprit of failing to boot Fedora 19
>  is somewhere in passing control of the active video graphics
>  from one stage to the next.
>  
>  -- 
>  
>  
>  -- 
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Sent from Yandex.Mail for mobile: http://m.ya.ru/ymail

Fedora 19 Alpha RC2 UEFI Fail

[Adam Williamson]

On 10/04/13 05:50 PM, Brian Fagioli wrote:
>  When I installed it on the same machine without UEFI, it booted fine.
> Running it now.
>
>  10.04.13, 20:47, "John Reiser" <jreiser(a)bitwagon.com&gt;&quot;:
> >
> >> Fails at Grub. Missing file. En.mo.gz
> >
> > That message probably is just informative, and not the cause of
> > failing to boot.  The same message occurs in many successful
> > boots of current release Fedora 18.
> >
> > Right now the suspected culprit of failing to boot Fedora 19
> > is somewhere in passing control of the active video graphics
> > from one stage to the next. 
It seems that every tester who doesn't hit the 'ENOSPC' issue and gets a 
successful install hits this issue where grub fails to display instead. 
So far the only bootable UEFI install I've heard of is one tflink did 
where he set grub up to use a serial console.

The bug report for this problem is 
https://bugzilla.redhat.com/show_bug.cgi?id=949761 , we're poking at it 
there. One thing the devs would like people to try is:

<pjones>: adamw: get them to try putting "GRUB_TERMINAL_OUTPUT=console" 
in /etc/default/grub and re-running grub2-mkconfig

you could do that from ctrl-alt-f2 after install is complete but before 
rebooting, or you could do it from rescue mode or a live image on the 
installed system. The theory is that by disabling grub's graphical mode 
we'll work around whatever the problem is, and hence prove that the 
problem is with the graphical mode.

If anyone actually got an entirely successful UEFI install with Alpha 
RC1 or RC2 - it installed without errors, and the installed system 
boots, showing you a graphical grub screen - that would be useful info 
to add to the bug; right now I'm working on the assumption that this is 
a complete showstopper for all UEFI installs.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[John Reiser]

>  I was running F18 on an old notebook ... 
>  Question: which minimal memory size is recommended for F19? 
For graphical desktop, the installer currently warns if less than 768MB.
Many users probably will be uncomfortable with less than 1GB.

Things you can try:  Append " cgroup_disable=memory " to the kernel boot
command line.  This saves somewhere around 1% (10MB out of 1GB), but every MB counts.

Append " selinux=0 " to the kernel boot command line.  This saved me 140MB
(difference in "grep MemFree /proc/meminfo" after booting to single user),
which is gigantic.  When I decided to restore SELinux, the next boot
took about 4 minutes to relabel all files.

Stop and disable unwanted services.  For example:
   systemctl stop sendmail.service
   systemctl disable sendmail.service

--

[Ralf Corsepius]

On 04/10/2013 06:23 PM, John Reiser wrote:
> > I was running F18 on an old notebook ...
>
> > Question: which minimal memory size is recommended for F19?
>
>  For graphical desktop, the installer currently warns if less than 768MB. 
Are these the installation memory requirements or the run-time requirements?

  I am asking because running F18 seems perfectly possible on with 
512MB, but running the installer wasn't.

>  Many users probably will be uncomfortable with less than 1GB.
>
>  Things you can try:  Append " cgroup_disable=memory " to the kernel boot
>  command line.  This saves somewhere around 1% (10MB out of 1GB), but every MB counts.
>
>  Append " selinux=0 " to the kernel boot command line.  This saved me 140MB
>  (difference in "grep MemFree /proc/meminfo" after booting to single user),
>  which is gigantic.  When I decided to restore SELinux, the next boot
>  took about 4 minutes to relabel all files.
>
>  Stop and disable unwanted services.  For example:
>      systemctl stop sendmail.service
>      systemctl disable sendmail.service 
Disable /tmp on tmpfs?

Ralf

[Richard W.M. Jones]

On Wed, Apr 10, 2013 at 06:55:59PM +0200, Ralf Corsepius wrote:
>  Disable /tmp on tmpfs? 
I have suggested this should be done automatically in RAM-limited
situations (primarily for VMs):

https://bugzilla.redhat.com/show_bug.cgi?id=858265

Well, ideally it would never have been done in the first place, but we
are where we are.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Nicolas Mailhot]

Le Mer 10 avril 2013 22:52, Richard W.M. Jones a écrit :
>  On Wed, Apr 10, 2013 at 06:55:59PM +0200, Ralf Corsepius wrote:
> > Disable /tmp on tmpfs?
>
>  I have suggested this should be done automatically in RAM-limited
>  situations (primarily for VMs):
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=858265
>
>  Well, ideally it would never have been done in the first place, but we
>  are where we are. 
Ideally it should never have been done without some automated way to grow
swap via files in /var/tmp when the tmpfs gets saturated (and possibly
shrink it back when the pressure ceases). That's the only way to get the
benefits of a ramdisk without hitting mem limits at unexpected moments.

Regards,

-- 
Nicolas Mailhot

[Richard W.M. Jones]

On Thu, Apr 11, 2013 at 01:51:16PM +0200, Nicolas Mailhot wrote:
>  
>  Le Mer 10 avril 2013 22:52, Richard W.M. Jones a écrit :
>  > On Wed, Apr 10, 2013 at 06:55:59PM +0200, Ralf Corsepius wrote:
>  >> Disable /tmp on tmpfs?
>  >
>  > I have suggested this should be done automatically in RAM-limited
>  > situations (primarily for VMs):
>  >
>  > https://bugzilla.redhat.com/show_bug.cgi?id=858265
>  >
>  > Well, ideally it would never have been done in the first place, but we
>  > are where we are.
>  
>  Ideally it should never have been done without some automated way to grow
>  swap via files in /var/tmp when the tmpfs gets saturated (and possibly
>  shrink it back when the pressure ceases). That's the only way to get the
>  benefits of a ramdisk without hitting mem limits at unexpected moments. 
This would be quite complex.

/tmp on disk already has the property that it uses memory (ie. the
buffer cache) when available and transparently spills to disk when it
is not.

tmpfs gets away with ignoring fsync, so in some synthentic benchmarks
it appears faster.  You could imagine an ext4 attribute that could be
added to /tmp to make it too ignore sync/fsync/journal.

In fact ext4 already has the *opposite* attribute -- to force updates
to a particular file or directory to be synchronous.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Nicolas Mailhot]

Le Jeu 11 avril 2013 14:07, Richard W.M. Jones a écrit :
>  On Thu, Apr 11, 2013 at 01:51:16PM +0200, Nicolas Mailhot wrote:
> >
> > Le Mer 10 avril 2013 22:52, Richard W.M. Jones a écrit :
> > > On Wed, Apr 10, 2013 at 06:55:59PM +0200, Ralf Corsepius wrote:
> > >> Disable /tmp on tmpfs?
> > >
> > > I have suggested this should be done automatically in RAM-limited
> > > situations (primarily for VMs):
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=858265
> > >
> > > Well, ideally it would never have been done in the first place, but we
> > > are where we are.
> >
> > Ideally it should never have been done without some automated way to
> > grow
> > swap via files in /var/tmp when the tmpfs gets saturated (and possibly
> > shrink it back when the pressure ceases). That's the only way to get the
> > benefits of a ramdisk without hitting mem limits at unexpected moments.
>
>  This would be quite complex. 
I don't contest this, but it is still less complex than expecting all the
unix software that has been written in the last decades to stop using /tmp
for big files because it is suddenly limited by memory limits.

I don't mind systemd exploring new concepts (and in fact I like it) but it
is not reasonable to push those new concepts in a state which is known to
break existing software. The tmpfs change has only been implemented
halfway.

-- 
Nicolas Mailhot

[Kevin Kofler]

Nicolas Mailhot wrote:
>  I don't contest this, but it is still less complex than expecting
> all the
>  unix software that has been written in the last decades to stop using /tmp
>  for big files because it is suddenly limited by memory limits.
>  
>  I don't mind systemd exploring new concepts (and in fact I like it) but it
>  is not reasonable to push those new concepts in a state which is known to
>  break existing software. The tmpfs change has only been implemented
>  halfway. 
+1, /tmp on tmpfs is a totally broken feature and should never have been 
approved. It needs to be reverted ASAP (IMHO, even in an F18 update).

        Kevin Kofler

[John Reiser]

And obviously, you *must* have some swap space if you are trying
to run with low RAM.  Even as small as 100MB of swap space will help.

--

[Nico Kadel-Garcia]

I run it virtualized right now with 1 Gig of RAM and default
configurations, which is not roomy with all the new eye candy and Gnome 3
environment but it's workable. Ripping out NetworkManager kicking and
screaming, and all the different "PackageKit" toolkits is helpful to
reducing the bloat down to a lean environment that can do actual software
building and testing. Running a lighter window manager is a *huge*
performance win: the excessive eye candy for the new Gnome is very resource
expensive. Of course, I tend to prefer running Emacs in individual
terminals without X, to reduce screen clutter and separate my multiple
tasks. So your tastes may vary.

For seriously lightweight window managers, I've been using "vtwm" for
years, still published by the Penguin Liberation Front and listed at
http://rpm.pbone.net/index.php3/stat/4/idpl/13029794/dir/mandriva_2010/co....
The Penguin Liberation Front has been a very useful resource, for years, of
components whose licenses are confusing or problematic: the old "xv" and
"twm" programs, "libdvdcss" for ripping DVD's, MPEG libraries, and
Pine and
daemontools before they had their licensing revised. I understand why those
components can't always be included in a completely open distribution with
US based resources and primary maintainers like Fedora. But man, they're
useful if you can accept the licensing personally or you're in a country
with sane laws about DRM.


On Wed, Apr 10, 2013 at 7:26 AM, Joachim Backes <
joachim.backes(a)rhrk.uni-kl.de&gt; wrote:

>  Dear developers,
>
>  I was running F18 on an old notebook with 512 MB memory (not
>  extendable). Now, I upgraded this box to F19 with yum. The upgrade was
>  done, but now, the box is no more operable because it is continuously
>  swapping.
>
>  Question: which minimal memory size is recommended for F19?
>
>  Kind regards
>
>  Joachim Backes
>  --
>
>  Fedora release 18 (Spherical Cow): Kernel-3.8.6-203.fc18.x86_64
>
>  Joachim Backes <joachim.backes(a)rhrk.uni-kl.de&gt;
>  https://www-user.rhrk.uni-kl.de/~backes
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Kevin Kofler]

Nico Kadel-Garcia wrote:
>  For seriously lightweight window managers, I've been using
> "vtwm" for
>  years, still published by the Penguin Liberation Front and listed at
>
> http://rpm.pbone.net/index.php3/stat/4/idpl/13029794/dir/mandriva_2010/co....
Be warned that PLF packages are NOT intended for Fedora.

>  The Penguin Liberation Front has been a very useful resource, for
> years,
>  of components whose licenses are confusing or problematic: the old "xv"
>  and "twm" programs, "libdvdcss" for ripping DVD's, MPEG
> libraries, and
>  Pine and daemontools before they had their licensing revised. I understand
>  why those components can't always be included in a completely open
>  distribution with US based resources and primary maintainers like Fedora.
>  But man, they're useful if you can accept the licensing personally or
>  you're in a country with sane laws about DRM. 
For Fedora, there is RPM Fusion which provides such packages (and a separate
repository for libdvdcss at rpm.livna.org).

        Kevin Kofler

[Nico Kadel-Garcia]

On Apr 13, 2013, at 18:37, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  Nico Kadel-Garcia wrote:
> > For seriously lightweight window managers, I've been using "vtwm" for
> > years, still published by the Penguin Liberation Front and listed at
> >
> http://rpm.pbone.net/index.php3/stat/4/idpl/13029794/dir/mandriva_2010/co....
>  
>  Be warned that PLF packages are NOT intended for Fedora. 
Completely true: they often require some editing of dependency names for Fedora and RHEL.


>  
> > The Penguin Liberation Front has been a very useful resource, for years,
> > of components whose licenses are confusing or problematic: the old "xv"
> > and "twm" programs, "libdvdcss" for ripping DVD's, MPEG
> libraries, and
> > Pine and daemontools before they had their licensing revised. I understand
> > why those components can't always be included in a completely open
> > distribution with US based resources and primary maintainers like Fedora.
> > But man, they're useful if you can accept the licensing personally or
> > you're in a country with sane laws about DRM.
>  
>  For Fedora, there is RPM Fusion which provides such packages (and a separate
>  repository for libdvdcss at rpm.livna.org).
>  
>         Kevin Kofler 
Unfortunately, rpm.livna.org spends its whole front page saying it's all at RPMfusion,
except one package which they *very, very, carefully* do not name or even list an actual
directory URL to review.

A bit of digging shows that the correct URL to see the *content* is
http://rpm.livna.org/repo/, and you're right, it's libdvdcss. I'm glad
it's available. The DRM craziness around that package is insane, and I'm glad when
I can do the work in a country that does not have such onerous restrictions.