):
Next I added the new vm to virt-manager:
# virsh define /data/kvm/Imported/Fedora35-Wynnbet/Fedora35-Wynnbet.xml
It worked, I started the vm from virt-manager, logged in and used
virt-manager to create a new interface.
Now I have 2 issues:
1) I cannot get it to resize the VM with
Hi
Has anybody fiddled with luks encrypted partition - I say
fiddle as I do not think it supported - sizes?
To be specific - I'd need to grow such a partition.
Normally it would be simple thing - remove, create partition
+ keep luks headers - but have not means to lab-test it thus
asking here
Στις 7/12/20 1:24 π.μ., ο/η Jorge Fábregas έγραψε:
On 12/6/20 7:10 PM, Kostas Sfakiotakis wrote:
Insufficient free space: 2560 extents needed, but only 2559 available
It'll all depended on the extent size ; you can see you're short of just
one extent (which is probably 4MB or 8MB don't reme
On 12/6/20 7:10 PM, Kostas Sfakiotakis wrote:
> Insufficient free space: 2560 extents needed, but only 2559 available
It'll all depended on the extent size ; you can see you're short of just
one extent (which is probably 4MB or 8MB don't remember now). You can
specify the extension via extents
Στις 7/12/20 12:21 π.μ., ο/η Jorge Fábregas έγραψε:
On 12/6/20 6:18 PM, Kostas Sfakiotakis wrote:
One last question though , do i need to resize the filesystem of the
/var partition or will it be resized automatically ??
It will be resized automatically due to the "-r" switch we
On 12/6/20 2:11 PM, Kostas Sfakiotakis wrote:
Στις 7/12/20 12:00 π.μ., ο/η Samuel Sieb έγραψε:
On 12/6/20 1:53 PM, Jorge Fábregas wrote:
p.d. you could create a partition in /dev/sdb and flag it as LVM so
you'll end up with /dev/sdb1 but since you already were using the whole
device, that's wh
On 12/6/20 6:18 PM, Kostas Sfakiotakis wrote:
> One last question though , do i need to resize the filesystem of the
> /var partition or will it be resized automatically ??
It will be resized automatically due to the "-r" switch we're using with
lvextend. You can "
Στις 6/12/20 11:53 μ.μ., ο/η Jorge Fábregas έγραψε:
On 12/6/20 5:07 PM, Kostas Sfakiotakis wrote:
Now what's the safest way to enlarge / resize the /var partition with
the use of /dev/sdb space ???
Ok, assuming you're not interested in the information within OldData
volume-group th
Στις 7/12/20 12:00 π.μ., ο/η Samuel Sieb έγραψε:
On 12/6/20 1:53 PM, Jorge Fábregas wrote:
p.d. you could create a partition in /dev/sdb and flag it as LVM so
you'll end up with /dev/sdb1 but since you already were using the whole
device, that's what I used.
I recommend using a partition inst
On 12/6/20 1:53 PM, Jorge Fábregas wrote:
p.d. you could create a partition in /dev/sdb and flag it as LVM so
you'll end up with /dev/sdb1 but since you already were using the whole
device, that's what I used.
I recommend using a partition instead of the raw disk, it avoids some
potential issu
On 12/6/20 5:07 PM, Kostas Sfakiotakis wrote:
> Now what's the safest way to enlarge / resize the /var partition with
> the use of /dev/sdb space ???
Ok, assuming you're not interested in the information within OldData
volume-group that resides on sdb you can:
1) pvcreate -f
at am going to loss any data .
The drive is basically empty .
Now what's the safest way to enlarge / resize the /var partition with
the use of /dev/sdb space ???
Since it something that i haven't done before i would rather ask for
some advice / example before
t-FS with resize2fs. [1]
Shrinking the does only work on an unmounted FS, though. But that's not
what you're going to do.
[1] (from man resize2fs)
>The resize2fs program will resize ext2, ext3, or ext4 file systems.
> It can be used to enlarge or shrink an unmounted file s
Bonjour,
I need to extend my /home directory which is a logical volume.
I read that I can use lvextend without unmounting the /home partition.
But what about resize2fs that I must use after lvextend?
Just to be sure: my home partition is contained in physical volume which
is a raid array (md5), I
On Tue, Sep 18, 2018, 8:09 AM Patrick Dupre wrote:
> Hello,
>
> Did I made a mistake?
> This what did:
>
> umount -l /home
>
There is no need to umount when growing ext4. Only for shrinking must it be
unmounted.
XFS can only be grown,.no shrink. And growing can only be done while
mounted.
Btr
40 Dunkerque, France
===
> Sent: Tuesday, September 18, 2018 at 5:16 PM
> From: "Roger Heflin"
> To: "Community support for Fedora users"
> Subject: Re: resize
>
> Did you rerun the resize2fs after the reboot/lvmresize/fsc
:02 PM
> From: "Patrick Dupre"
> To: users@lists.fedoraproject.org
> Cc: users@lists.fedoraproject.org
> Subject: Re: resize
>
> I am not sure about the +100.
>
> However, I rebooted without mounting /home
> and I used lvm manager to do the resize.
>
> It
Le 18/09/2018 à 16:24, Patrick Dupre a écrit :
> I also get:
>
> Logical volume is not mounted but is in use. Please close all applications
> using this device (eg iscsi)
>
> How can I close all applications using the device ?
lsof | grep /home
--
François Patte
UFR de mathématiques et inform
Did you rerun the resize2fs after the reboot/lvmresize/fsck?
On Tue, Sep 18, 2018 at 10:03 AM Patrick Dupre wrote:
>
> I am not sure about the +100.
>
> However, I rebooted without mounting /home
> and I used lvm manager to do the resize.
>
> It seems OK, except that
> 1)
I am not sure about the +100.
However, I rebooted without mounting /home
and I used lvm manager to do the resize.
It seems OK, except that
1) it shows "none" for the file system (lvm manager)
2) the size shown by lvm manager is 35 Go
lvdisplay:
LV Path/dev/VolGrpUs
Schumann | | 59140 Dunkerque, France
> ===
>
>
> > Sent: Tuesday, September 18, 2018 at 4:03 PM
> > From: "Patrick Dupre"
> > To: fedora
> > Subject: resize
> >
>
On 9/18/18 9:03 AM, Patrick Dupre wrote:
New size given (2419 extents) not larger than existing size (15500 extents)
This is an important error message. It means the resize operation was not performed
due to the parameters you specified.
I think what you meant to run was with a '+
ue, France
===
> Sent: Tuesday, September 18, 2018 at 4:03 PM
> From: "Patrick Dupre"
> To: fedora
> Subject: resize
>
> Hello,
>
> Did I made a mistake?
> This what did:
>
> umount -l /home
>
>
Hello,
Did I made a mistake?
This what did:
umount -l /home
lvdisplay /dev/VolGrpUsr_DK0
[root@Homere ~]# vgdisplay VolGrpUsr_DK0
--- Volume group ---
VG Name VolGrpUsr_DK0
System ID
Formatlvm2
Metadata Areas1
Metadata Sequence No 9
anything. I tried other variants (other buttons, the Super
>> key) and none seem to do it.
>>
>
>
> I don't remember seeing this work with GNOME on Wayland. Just checked a
> few things, and noticed that Alt+Mouse3 resize doesn't work but
> Alt+Mouse1+Mouse2 (em
.
I don't remember seeing this work with GNOME on Wayland. Just checked a
few things, and noticed that Alt+Mouse3 resize doesn't work but
Alt+Mouse1+Mouse2 (emulated middle) does resize. Odd, right? Also,
GNOME Tweak Tool has an option under "Windows" titled "Resize wit
On 08/14/2017 06:50 AM, Matt Morgan wrote:
> Starting maybe a few days ago, holding Alt near the corner of a window
> and middle-clicking, which used to turn the cursor into a
> window-resizer, no longer does anything. I tried other variants (other
> buttons, the Super key) and none seem to do it.
Starting maybe a few days ago, holding Alt near the corner of a window and
middle-clicking, which used to turn the cursor into a window-resizer, no
longer does anything. I tried other variants (other buttons, the Super key)
and none seem to do it.
Any suggestions for how to get it back? This is F2
On 12/07/16 16:24, Chris Murphy wrote:
On Tue, Jul 12, 2016 at 5:35 AM, Morgan Read wrote:
Well, it seems to have reduced the volumes, but not the filesystems:
Volume
On Tue, Jul 12, 2016 at 5:35 AM, Morgan Read wrote:
> Yes, I have filed a bug here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1354681
I've reproduced the problem where ssm resize of a LUKS volume. It only
resizes the LUKS volume, not the underlying LV, and not the fs on the
LUKS
he same...
But what I'm seeing is *ONLY* the LUKS volume was reduced. The LV is
the same size as before.
ssm is apparently confused about the stack relationships. It's
treating the command literally for only the dmcrypt volume, not the
file system and not the LV. Off hand I'd say
it first.
But it does seem clear in your case the file system was not resized.
I would say this part is improper design and a valid bug to file:
[root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/home
WARNING: Reducing active and open logical volume to 192.73 GiB.
THIS M
On 11/07/16 21:35, Chris Murphy wrote:
On Sun, Jul 10, 2016 at 12:42 PM, Morgan Read wrote:
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
These
t does seem clear in your case the file system was not resized.
I would say this part is improper design and a valid bug to file:
[root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/home
WARNING: Reducing active and open logical volume to 192.73 GiB.
THIS MAY DESTROY YOUR
On Sun, Jul 10, 2016 at 12:42 PM, Morgan Read wrote:
> [root@morgansmachine ~]# ssm resize -s-3G
> /dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
> [root@morgansmachine ~]# ssm resize -s-3G
> /dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
These two commands should
ck bitmap while trying to resize
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
Please run 'e2fsck -fy
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316' to fix the
filesystem
after the aborted resize operation.
[root@localhost ~]# e2fsck -fy
/dev/mapper/luks-d313ea5e-fe14-4967
80 MB part/boot
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-d313ea5e-fe14-49
I found how to do this in 16 but can't seem to find it in 15 How do
I disable the resize hint box that pops up and tells you the size of the
console every time you resize it?
Thanks!
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
it's official:
Lately, I've been having a lot of Performance issues because of BTRFS
(Specially when running VM's) so I was wondering if theres a way to Shrink
an encrypted (Crypto-Luks) BTRFS partition in order to create a new Ext4 one
to store my VM's...
In case there's not, I'm interested in k
Linuxguy123 wrote:
> I'm moving /, /boot and swap from a conventional hard drive to an SSD.
>
> Both drives are 160 GB in size.
>
> I want to resize the /boot and swap partitions from 200 MB and 2 GB to
> 500 MB and 8 GB respectively. The first resize is because preupg
On 06/25/2010 08:58 PM, L wrote:
> On Sat, Jun 26, 2010 at 10:15 AM, Mikkel wrote:
>> On 06/25/2010 04:19 PM, Robert Arkiletian wrote:
>>> On Fri, Jun 25, 2010 at 12:58 PM, Mikkel wrote:
You may have to re-install Grub. When you change the size of the
/boot partation, you may change th
On Sat, Jun 26, 2010 at 10:15 AM, Mikkel wrote:
> On 06/25/2010 04:19 PM, Robert Arkiletian wrote:
>> On Fri, Jun 25, 2010 at 12:58 PM, Mikkel wrote:
>>> You may have to re-install Grub. When you change the size of the
>>> /boot partation, you may change the physical location of Grub's
>>> stage
On 06/25/2010 04:19 PM, Robert Arkiletian wrote:
> On Fri, Jun 25, 2010 at 12:58 PM, Mikkel wrote:
>> You may have to re-install Grub. When you change the size of the
>> /boot partation, you may change the physical location of Grub's
>> stage 1.5 loader that understands the file system. Grub stage
On Fri, Jun 25, 2010 at 12:58 PM, Mikkel wrote:
> On 06/25/2010 11:22 AM, Robert Arkiletian wrote:
>>
>> My initial question remains.
>>
>> Am I correct in assuming I only need to edit /etc/fstab and /etc/grub.conf
>> to boot from the new partitions?
>>
> You may have to re-install Grub. When you
On 06/25/2010 11:22 AM, Robert Arkiletian wrote:
>
> My initial question remains.
>
> Am I correct in assuming I only need to edit /etc/fstab and /etc/grub.conf
> to boot from the new partitions?
>
You may have to re-install Grub. When you change the size of the
/boot partation, you may change t
sn't know that)
> >>
> >> I want to resize my partitions bigger.
> >> Going to use Clonezilla to make an image of each partition and save it
> >> on another box.
> >>
> >> Then re-partition and format new bigger partitions.
> >>
On Thu, Jun 24, 2010 at 4:54 PM, Linuxguy123 wrote:
> On Thu, 2010-06-24 at 16:19 -0700, Robert Arkiletian wrote:
>> I have 1 drive /dev/sda (which is actually a hardware raid 10 array
>> but Fedora doesn't know that)
>>
>> I want to resize my partitions bigger.
&g
On Thu, 2010-06-24 at 17:10 -0700, JD wrote:
> If you dd partition A on drive 1 to partition B from drive 2, and the
> size of partition B is
> LARGER that partition A, then the size of the FILESYSTEM on partition B
> will be identical to size of partition A. In other words, the filesystem
> s
On 06/24/2010 04:12 PM, Patrick Bartek was caught red-handed while
writing::
> --- On Thu, 6/24/10, Linuxguy123 wrote:
>
>
>> I'm moving /, /boot and swap from a
>> conventional hard drive to an SSD.
>>
>> Both drives are 160 GB in size.
>>
>&
On Thu, 2010-06-24 at 16:19 -0700, Robert Arkiletian wrote:
> I have 1 drive /dev/sda (which is actually a hardware raid 10 array
> but Fedora doesn't know that)
>
> I want to resize my partitions bigger.
> Going to use Clonezilla to make an image of each partition and save
On Thu, 2010-06-24 at 16:12 -0700, Patrick Bartek wrote:
>
> In Linux, "everything's a file." ;-)
Sure.
> No, dd won't "resize" a partition, but you can use it to copy the
> filesystem from one partition to another of the same size or larger,
On Thu, 2010-06-24 at 15:33 -0700, Kam Leo wrote:
> On Thu, Jun 24, 2010 at 2:09 PM, Linuxguy123 wrote:
> > I found the easiest way to do this was to download a copy of Ubuntu 10.4
> > and use gparted. It has a function to copy a partition from the source
> > drive to the destination drive. Th
I have 1 drive /dev/sda (which is actually a hardware raid 10 array
but Fedora doesn't know that)
I want to resize my partitions bigger.
Going to use Clonezilla to make an image of each partition and save it
on another box.
Then re-partition and format new bigger partitions.
Then restore i
--- On Thu, 6/24/10, Linuxguy123 wrote:
> I'm moving /, /boot and swap from a
> conventional hard drive to an SSD.
>
> Both drives are 160 GB in size.
>
> I want to resize the /boot and swap partitions from 200 MB
> and 2 GB to
> 500 MB and 8 GB respectively.
On Thu, Jun 24, 2010 at 2:09 PM, Linuxguy123 wrote:
> On Thu, 2010-06-24 at 09:35 +0100, John Austin wrote:
>> On Thu, 2010-06-24 at 02:06 -0600, Linuxguy123 wrote:
>> > I'm moving /, /boot and swap from a conventional hard drive to an SSD.
>> >
>> > Both drives are 160 GB in size.
>> >
>> >
>> I
On Thu, 2010-06-24 at 09:35 +0100, John Austin wrote:
> On Thu, 2010-06-24 at 02:06 -0600, Linuxguy123 wrote:
> > I'm moving /, /boot and swap from a conventional hard drive to an SSD.
> >
> > Both drives are 160 GB in size.
> >
> >
> I have tried a couple of methods successfully, here are my "h
On Thu, 2010-06-24 at 02:06 -0600, Linuxguy123 wrote:
> I'm moving /, /boot and swap from a conventional hard drive to an SSD.
>
> Both drives are 160 GB in size.
>
> I want to resize the /boot and swap partitions from 200 MB and 2 GB to
> 500 MB and 8 GB respectively
I'm moving /, /boot and swap from a conventional hard drive to an SSD.
Both drives are 160 GB in size.
I want to resize the /boot and swap partitions from 200 MB and 2 GB to
500 MB and 8 GB respectively. The first resize is because preupgrade
now fails to run unless /boot is 500 MB or l
w size. Anything can be on a RAID block
> device, not just ext3. Something still needs to logically resize the
> ext3 filesystem.
Right. Partition expansion and filesystem expansion are two different
things.
>> Boot with some sort of rescue disk so you are not running from the disks.
>
arger, the ext3 filesystem needs to be grown, else it'll remain
at its logical size, with no benefit.
I don't think that mdadm --grow adjusts the ext3 metadata on the partition
to reflect its new size. Anything can be on a RAID block device, not just
ext3. Something still needs to logic
Sam Varshavchik wrote:
> The disk partitions are as follows:
>
> Device /dev/sda1 /boot 100 megabytes
> /dev/sda2 / 20 gigabytes
> /dev/sda3 swap - 6 gigs
> /dev/sda4 Extended partition
> /dev/sda5 /home -- remaining space, large
>
> The layout of /dev/sdb is the same, and each partition
rsion of parted seems to accept /dev/mdX as a parameter, and the
resize command is documented. So, I think what I need to do is:
1) Use parted to shrink the filesystem on /dev/mdX
2) Use mdadm --grow to reduce the size of the /dev/mdX array
3) Go back to parted, and use the "move" comman
version of parted seems to accept /dev/mdX as a parameter, and the
> resize command is documented. So, I think what I need to do is:
>
> 1) Use parted to shrink the filesystem on /dev/mdX
>
> 2) Use mdadm --grow to reduce the size of the /dev/mdX array
>
> 3) Go back to part
Bruno Wolff III writes:
On Sat, May 29, 2010 at 10:31:11 -0400,
Sam Varshavchik wrote:
I want to juggle these partitions around. It's not clear to me if
parted will handle RAID partitions. I think I should resize each
partition on each drive identically, and parted should end up
prod
On Sat, May 29, 2010 at 10:31:11 -0400,
Sam Varshavchik wrote:
>
> I want to juggle these partitions around. It's not clear to me if
> parted will handle RAID partitions. I think I should resize each
> partition on each drive identically, and parted should end up
> producin
. It's not clear to me if parted
will handle RAID partitions. I think I should resize each partition on each
drive identically, and parted should end up producing identical contents if
it's asked to resize two identical partitions to the same size, right? But
what about the mdr
Hi,
I was afraid someone was going to say that but i was hoping for a more safer method. I think i will take another backup of all my data 1st then do the below suggestion of deleting the /dev/sda2.
Thanks
Fred
On 02/27/2010 09:31 PM, Roberto Ragusa wrote:
Frederick Abrams wrote:
Frederick Abrams wrote:
> 1) Rebooted with Fedora 12 in Rescue mode
> 2) e2fsck /dev/mapper/vg_fa-lv_root
> 3) resize2fs /dev/mapper/vg_fa-lv_root 275G
> 4) lvresize -L 250G /dev/vg_fa-lv_root
Hmmm, 275G filesystem inside a 250G lv??? You should have done the reverse...
Danger.
> 5) pvresize --s
Hi All,
I need some help i have a 500GB disk which when i installed F12 i selected the entire HDD to be used by LVM.
I don't need so much HDD for the LVM and I want to shrink the LVM PV to say 300GB and use the rest to install windows to play my games.
I have done the below.
1) Rebooted wit
69 matches
Mail list logo
