[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: root low space



I forgot to add that, either from the linux console, or a terminal from startx, "fdisk -l" shows correctly

/dev/md0

/dev/md1, both with their

/dev/mapper/vg1-root

and all other /mapper/vg1

Also, all needed codes , resize2f lvreduce lvexternal are on the path. The only problem I still have is to first backup home and root on another computer along my network.
francesco
---------- Forwarded message ----------
From: Francesco Pietra <chiendarret@gmail.com>
Date: Sat, May 24, 2014 at 8:16 AM
Subject: Re: root low space
To: Adam Stiles <adam@priceengines.co.uk>
Cc: amd64 Debian <debian-amd64@lists.debian.org>



I first tried Parted Magic, as available from

http://partedmagic.linuxfreedom.com/download.htm

downloading the 2012_12-25_x86_64 version. Is that the same mentioned by Giacomo Mulas. Well, it recognizes immediately my boot partition /dev/md0 (ext2).

As to unallocated /dev/md1, the scan brought to light four file systems, two for what are my /usr and /opt and two with mixed stuff. I was unable to try to backup my /vg1-root as from

francesco@gig64:~$ df -h

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/vg1-root 922M 839M 35M 97% /

udev 10M 0 10M 0% /dev

tmpfs 1.6G 860K 1.6G 1% /run

tmpfs 5.0M 0 5.0M 0% /run/lock

tmpfs 3.2G 80K 3.2G 1% /run/shm

/dev/mapper/vg1-home 770G 271G 461G 37% /home

/dev/mapper/vg1-opt 9.1G 3.1G 5.6G 36% /opt

/dev/mapper/vg1-tmp 5.4G 12M 5.1G 1% /tmp

/dev/mapper/vg1-usr 55G 6.4G 46G 13% /usr

/dev/mapper/vg1-var 19G 2.5G 15G 15% /var

none 4.0K 0 4.0K 0% /sys/fs/cgroup

francesco@gig64:~$



root@gig64:/home/francesco# cat /etc/fstab

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# <file system> <mount point> <type> <options> <dump> <pass>

proc /proc proc defaults 0 0

/dev/mapper/vg1-root / ext3 errors=remount-ro 0 1

/dev/mapper/vg1-home /home ext3 defaults 0 2

/dev/mapper/vg1-opt /opt ext3 defaults 0 2

/dev/mapper/vg1-tmp /tmp ext3 defaults 0 2

/dev/mapper/vg1-usr /usr ext3 defaults 0 2

/dev/mapper/vg1-var /var ext3 defaults 0 2

/dev/mapper/vg1-swap none swap sw 0 0

/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0

root@gig64:/home/francesco#


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Then, I tried with systemrescuecd-x86-4.2.0

This too recognized immediately my /dev/md0 (ext2). However, a scan of the unallocated /dev/md1 (from gparted) resulted in "The disk scan by gpart did not find any recognizable file systems on this disk"

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I assume I have taken a wrong way, both with PartedMagic and SystemRescueCD.

Thanks for redirecting. I insist in trying to make room for vg1-root as a few months ago I succeeded in getting PCIExpress 3.0 for this ivybridge/GPU system, accelerating my MD simulations by some 15% with respect to PCIExpress 2.0. Unfortunately I did not take notice of how I did that.

thanks

francesco


On Fri, May 23, 2014 at 11:42 AM, Adam Stiles <adam@priceengines.co.uk> wrote:
On Friday 23 May 2014, Francesco Pietra wrote:
> In my case, described above, in order to be able to use
>
> # partclone.ext3 -c -d -s /dev/mapper/vg1-root  -o
> /home/francesco/vg1-root.img
>
> how to first umount vg1-root? I was unable to do that correctly, so that
> partclone failed because
>
> device (/dev/map//vg1-root) is mounted at  /
>
> thanks
>
> francesco
> (and sorry for such a low-level query)


I just had to deal with a similar situation -- I ran out of space on the root
file system while trying to do a dist-upgrade, leaving the package manager in a
slightly broken state.

Fortunately, I had another partition that I was able to shrink and so make
more room for / .

Just search online for "system rescue CD".  This is Gentoo-based, but don't
let that put you off.  It has an XFCE desktop, Midori web browser and -- what
you need --  gparted.

N.B.  I strongly recommend powering your computer through a UPS while
performing this operation!  If you are unfortunate enough to lose power while
in the middle of shrinking a partition, you probably will end up losing data.
All good disk tools always try at least to keep the block map correct, by
updating it piecemeal after copying each chunk of data; but when the power
fails, you don't know for a fact that any write operation that had been in
progress completed successfully.


--
AJS
Price Engines Ltd.  DDI: 01283 707058.


--
To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 201405231042.52484.adam@priceengines.co.uk" target="_blank">https://lists.debian.org/[🔎] 201405231042.52484.adam@priceengines.co.uk




Reply to: