Having trouble???....check your SWAP!

[djsroknrol]

NEWSFLASH: Hardy doesn't always mount your swap for usage during an install....I wondered why the command:

Code:

free -m

showed no swap usage...neither did:

Code:

top

Craziest thing I've ever experienced in Ubu. That little fix cleared up my VMware problems and all my FF3 troubles.

My advice to anyone who is experiencing lockups and freezes...check your swap file and save yourself a small headache 

[machiner]

Just because you have a swap partition doesn't mean that it will be used, though.

machiner@lapbox{~}:free -m
             total       used       free     shared    buffers     cached
Mem:          3042       3028         14          0        725       1911
-/+ buffers/cache:        391       2651
Swap:         2863          0       2863

I only even made a swap partition for uswsusp.  uswsusp enforces a swap partition at install and I use s2ram to put my laptop to sleep.  So, I want that program installed.


There is a swap partition mount in my fstab file

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sda1       /               ext3    errors=remount-ro 0       1
/dev/sda4       /home           ext3    defaults        0       2
/dev/sda3       /vault          ext3    defaults        0       2
/dev/sda2       none            swap    sw              0       0
/dev/hda        /media/cdrom0   udf,iso9660 user,noauto     0       0

If you run mount all by its lonesome, as root, you'll get somethign like the following:

lapbox:/etc# mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda4 on /home type ext3 (rw)
/dev/sda3 on /vault type ext3 (rw)
/dev/hda on /media/cdrom0 type udf (ro,noexec,nosuid,nodev,user=machiner)

As you will see, my swap partition (dev/sda2) does not appear to be mounted. Moreover, you will see that /dev/sda2 has no mount point.

From http://linux.die.net/man/8/mount :

"The programs mount and umount maintain a list of currently mounted file systems in the file /etc/mtab. If no arguments are given to mount, this list is printed."

Of course, you could just cat /etc/mtab, too.


EDITed 'cause I forgot a sentence.  D'oh.

[djsroknrol]

Yo B-man..Hardy's clean install set it up, but for the first time, Ubuntu dropped the ball on my rig. Install didn't set it up properly in fstab. It was SO DAMN BAD, I couldn't format a VM drive for installation, nor could I run more than 4 windows at a time without a lockup.

I looked at my VideoRam in Xorg.conf, thinking that my POS shared GPU was stealing my RAM..nope; not there. I thought that I pooched my VMware install, so I played program ping-pong...taking it on and off...upgrading and downgrading...no joy either. Last night, after reading a thread on UF about posting free -m's, I decided to look at mine, and low and behold, no damn swap running 

I fixed it like so, one line at a time:

Code:

sudo fdisk -l
cat /etc/fstab
sudo blkid
free -m

That's how I noticed the UUID for the swap was wrong....I sure didn't write the fstab, so I have no-one else to blame but Ubu's install program. If you're running 512MB RAM or less, it's going to swap, and mine was there but wasn't using it.

[machiner]

Pfft -- I shoulda known you were too squared-away to fall for my "weeding".  lol.  Cool that it's fixed but running free -m isn't going to rewrite a corrupted fstab.  free merely reports, as does blkid.

I'm confused.

[djsroknrol]

Sorry for the confusion there bud....Actually, I ran free -m twice. The first time was when I discovered no swap when I knew I had made one. Then I ran fdisk -l to verify that indeed I had made one. After that, I studied the fstab....I couldn't see anything out of the ordinary and thought that the UUID might be the problem. And finally, sudo blkid proved that the UUID was written wrong (HTF is that possible??...I'm still pondering that one).

A quick Gedit session fixed it easy peasy....
 

[machiner]

Right on.

But

lapbox:/home/machiner# blkidr
/dev/sda1: UUID="a962da96-8d11-48b6-ab7e-b4807d0f1aeb" TYPE="ext3"
/dev/sda2: TYPE="swap"
/dev/sda3: LABEL="vault" UUID="17cf0585-a021-4a0a-8c8b-eb97c6d77e7e" TYPE="ext3"
/dev/sda4: LABEL="home" UUID="afe0cea9-dc9b-42fc-8f84-7fabf09a046c" TYPE="ext3"

I still don't see what's been fixed.  Or, how.  Help a dumb bastard out.

What I get you saying is that you never had a swap in the first place and all this talk of mounting is just pent up sexual frustration.   

Afterwards, when you noticed memory issues - you made a swap partition.  Moreover, UUID references never really came into play in the first place - you're just a twisted bastard and your thought process is fully engaged in the moth principal.

Am I right?  Because you know fully well that it takes one to know one.

Otherwise, I'm just going back to bed so I can wake up with my brain this time.


lol.

[Resa]

I don't know if this is a difference between Lenny (that is if you are still running Debian, machiner) and Ubuntu. But I can understand how djs found and fixed the issue.

Here is my result of sudo blkid

Code:

/dev/sda1: UUID="90d86d87-67d5-402b-8b95-b57f87f555b4" TYPE="ext3"
/dev/sda2: TYPE="swap" UUID="cd2b176c-fb1d-4bb1-ab26-6a6474d1d1ea"
/dev/sda3: UUID="3f5faa4a-870e-4213-9c25-1c55518fed28" TYPE="ext3"
/dev/sda4: UUID="376e2177-4467-4bb4-9c51-54d7f48c5343" TYPE="ext3"

What I noticed is that you do not have a UUID mentioned after your swap partition where I have.
If I compare this with the result of cat /etc/fstab

Code:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=90d86d87-67d5-402b-8b95-b57f87f555b4 /               ext3    relatime,errors=remount-ro 0       1
# /dev/sda3
UUID=3f5faa4a-870e-4213-9c25-1c55518fed28 /home           ext3    relatime        0       2
# /dev/sda4
UUID=376e2177-4467-4bb4-9c51-54d7f48c5343 /var            ext3    relatime        0       2
# /dev/sda2
UUID=cd2b176c-fb1d-4bb1-ab26-6a6474d1d1ea none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0

I can compare the UUID on both results.

From what I understand from djs is that he encountered a difference between the UUID indicated on the first and the second command. So with an editor (he chose gedit) he corrected the /etc/fstab file to make them the same.
Resulting in a swap that can actually be used.

BTW I do know that a swap may not be used, but running only a VM on my laptop (2 Gb memory) already results in usage of swap

Code:

             total       used       free     shared    buffers     cached
Mem:          2025       1973         52          0         26       1627
-/+ buffers/cache:        319       1706
Swap:         3890         27       3863

[djsroknrol]

Resa's got it...I couldn't post any code to show what was wrong, as it was already fixed by me...so you get the idea. Running 98% usage, I couldn't get VMware server to do anything...and all my lockups went bye-bye 

[Resa]

Out of curiosity and because of this post I do -- when and if I remember -- this for the various installations I have.
Today I noticed what djs was talking about. On my Arch installation I ran free -m to find there was 0 space available (see below).

Code:

             total       used       free     shared    buffers     cached
Mem:           249        232         16          0          9         82
-/+ buffers/cache:        140        108
Swap:            0          0          0

This is odd since I always use swap so I checked the content of /etc/fstab, which looks like this

Code:

#
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
none                   /dev/pts      devpts    defaults            0      0
none                   /dev/shm      tmpfs     defaults            0      0


/dev/cdrom /media/cdrom   auto    ro,user,noauto,unhide   0      0
/dev/cdrom1 /media/cdrom1   auto    ro,user,noauto,unhide   0      0
/dev/dvd /media/dvd   auto    ro,user,noauto,unhide   0      0
UUID=01e19e8b-e8bc-4924-a0e1-fb8c821d9eda swap swap defaults 0 0
UUID=d2d6e048-b166-4af5-9ce8-c26c84a289b3 / ext3 defaults 0 1

So it is mentioned in my fstab file, so I checked /etc/mtab

Code:

/dev/sda5 / ext3 rw 0 0
none /dev ramfs rw 0 0
none /proc proc rw 0 0
none /sys sysfs rw 0 0
none /dev/pts devpts rw 0 0
none /dev/shm tmpfs rw 0 0

No swap assigned! Running sudo blkid made clear why

Code:

/dev/sda1: LABEL="Dreamlinux" UUID="2e7ecc0b-93c1-44c1-8df0-1f0ca3b24a7c" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda2: UUID="b4e073c8-4df9-4429-a23b-2baa9d8e7634" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda4: TYPE="swap" LABEL="linux-swap" UUID="b2864cf6-b38e-4194-bf68-328ec3d5cb98"
/dev/sda5: UUID="d2d6e048-b166-4af5-9ce8-c26c84a289b3" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda6: UUID="9b40c033-2f7f-472f-bb8a-e1141f9db7fd" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda7: UUID="4457ae23-23e8-46ce-8591-a3cda776b1cc" SEC_TYPE="ext2" TYPE="ext3"

The UUID in the /etc/fstab file (01e19e8b-e8bc-4924-a0e1-fb8c821d9eda) and the one shown with the blkid command (b2864cf6-b38e-4194-bf68-328ec3d5cb98) do not match!

Nothing nano can not fix, but it shows it CAN happen ... the main question is why?
Are UUIDs not issued once in a lifetime? Can these change over time?
Is it maybe better to simply use /dev/sda4 instead of the UUID in the /etc/fstab file?

UPDATE: The result of free -m AFTER a modified /etc/fstab

Code:

             total       used       free     shared    buffers     cached
Mem:           249        127        122          0          7         62
-/+ buffers/cache:         57        192
Swap:          776          0        776

This is more like I expected.   

[richs-lxh]

free -m on my Arch install:

Code:

free -m
             total       used       free     shared    buffers     cached
Mem:           503        296        206          0          5         74
-/+ buffers/cache:        216        286
Swap:            0          0          0

sudo blkid for swap:

Code:

7d43140c-0b78-473b-b43f-0930df8d452c

sudo nano /etc/fstab for swap:

Code:

e39abfb0-1181-4f62-bbea-d1643eae6223

  

The same as Resa, I added the new uuid to the /etc/fstab listing for swap.

[djsroknrol]

See what I mean guys?....it also happened to me in DL as well...could it be a Gnome thing?

[richs-lxh]

Yup, there it is.

I just rebooted and....

Code:

free -m
             total       used       free     shared    buffers     cached
Mem:           503        152        350          0          6         81
-/+ buffers/cache:         64        439
Swap:         1498          0       1498

So who is going to post on the Arch forums to let them know?

Rich

[Resa]

So who is going to post on the Arch forums to let them know?

Well ... I am not a member there (yet) 

[richs-lxh]

So who is going to post on the Arch forums to let them know?

Well ... I am not a member there (yet) 

Ok, I posted just in case.
http://bbs.archlinux.org/viewtopic.php?pid=444995#p444995

We don't want our fellow Arch users experiencing any slow-down.

Rich

[richs-lxh]

Update:

I found a bug report posted about Ubuntu not updating the uuid in fstab after partitions were resized.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/253303

Now, my bet is that as we are all distro junkies, each of us has probably deleted/edited/resized a partition or two.

So it appears that this affects Arch and Ubuntu only if partitions are changed. This reinforces my view that the uuid system of listing partitions and drives is a step backwards, as opposed the the traditional /dev/hda1 method.

We are having problems with Grub install on our Dreamlinux installer because of it, and now Swap partitions are being interfered with.

Rich

[silverhat]

Because I like to play & test new Distros(re-formatting partitions is very often) so that I prefer the way using /dev/sd... than using UUID 

[richs-lxh]

Well, at the moment you are all cool with Dreamlinux then

Ubuntu and Arch use the uuid system and quite frankly it sucks. But there ya go, progress is progress, and it appears that devs are only thinking of single-distro setups, not multi-partition, multi-distro setups.

Well, thanks to Bob and Resa we now know what can happen if a uuid partition is changed in any way.

Rich

[djsroknrol]

I did do a new partition when I cleaned house. But don't be so in a hurry to say that someone is safe with DL....

Have a look at this:

http://dreamlinuxforums.org/index.php/topic,3553.0.html

I need to check my other distros...and off I go....

[richs-lxh]

I did do a new partition when I cleaned house. But don't be so in a hurry to say that someone is safe with DL....

Have a look at this:

http://dreamlinuxforums.org/index.php/topic,3553.0.html

I need to check my other distros...and off I go....

Nope!! Dreamlinux Rocks!. 

Code:

free -m
             total       used       free     shared    buffers     cached
Mem:           502        458         44          0         24        218
-/+ buffers/cache:        215        287
Swap:         1498          0       1498

All hunky-dory on Dreamlinux. Oh ye of little faith! 

Rich

[Ghoti]

This is just to confirm that I experienced the same thing with Arch on my two multi-distro boxes. One that runs Arch and DL3.5r4 and the other one runs Arch and Ubuntulite.

Ghoti

[Tags:]

Linux Hardcore Forum > All Linux Distro Support > Ubuntu Linux Support > Topic: Having trouble???....check your SWAP!