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 <[email protected]> Date: Sat, May 24, 2014 at 8:16 AM Subject: Re: root low space To: Adam Stiles <[email protected]> Cc: amd64 Debian <[email protected]> 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 <[email protected]> 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 [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: > https://lists.debian.org/[email protected] > >
