> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# توسيع قرص النظام في Ubuntu عند استخدام LVM
- URL: https://arabroot.io/articles/توسيع-قرص-النظام-lvm-في-ubuntu/
- Published: 2026-09-27T10:40:00.000Z
- Updated: 2026-10-04T20:06:05.000Z
- Description: هل قمت بزيادة حجم القرص من Proxmox أو من لوحة المزود، لكن النظام ما زال يعرض الحجم القديم؟ نشرح كيف توسع قرص النظام في Ubuntu خطوة بخطوة، دون إيقاف الخادم ودون فقدان البيانات.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, لينكس والسيرفرات, LVM

لنفرض أنك قمت بزيادة حجم قرص السيرفر من 40 إلى 80 غيغابايت في Proxmox أو من لوحة مزود الخادم الافتراضي VPS، ثم دخلت إلى السيرفر ونفذت الأمر `df -h /` لترى المساحة الجديدة، فسوف تجد أن الحجم القديم ما زال كما هو وكأنك لم تفعل شيئاً، والسبب أن المساحة الجديدة أصبحت موجودة فعلاً على القرص، ولكن الطبقات التي تقع فوقه داخل النظام لا تعرف عنها شيئاً حتى الآن، وبالتالي عليك أن توصلها إليها بنفسك طبقة بعد طبقة.

وهذه الحالة تتكرر كثيراً مع Ubuntu Server، حيث يستخدم التثبيت الموجه Guided Install فيه [LVM](https://manpages.ubuntu.com/manpages/noble/man8/lvm.8.html?ref=arabroot.io) بشكل افتراضي، وكثيراً ما يترك المجلد المنطقي Logical Volume الخاص بالنظام أصغر من القرص نفسه، لذلك سوف نوصل في هذا الدليل المساحة الجديدة إلى نظام الملفات Filesystem على Ubuntu 24.04 LTS والسيرفر يعمل، دون إعادة تشغيل ودون أن تفقد أي بيانات.

وسوف نناقش في هذا المقال ما يلي:

- لماذا لا يظهر الحجم الجديد، وما هي الطبقات التي تقع بين القرص ونظام الملفات.
- كيف تتعرف على أسماء الأجهزة في سيرفرك قبل أن تنفذ أي أمر، حتى لا تعمل على القرص الخطأ.
- توسيع القسم Partition بالأمر `growpart`، ثم المجلد الفعلي Physical Volume بالأمر `pvresize`، ثم المجلد المنطقي ونظام الملفات بالأمر `lvextend`.
- الحالة الأسهل التي تكون فيها المساحة موجودة أصلاً داخل المجموعة Volume Group، والتحقق من النجاح، وأشهر المشكلات وحلولها، وما تفعله إذا لم يكن نظامك مبنياً على LVM.

## المتطلبات

- سيرفر أو جهاز افتراضي VM يعمل بنظام Ubuntu Server 24.04 LTS، وقرص النظام فيه مبني على LVM، ونفس الخطوات تصلح مع 22.04 ومع أغلب توزيعات Linux.
- مستخدم يملك صلاحية `sudo`، وجلسة SSH أو طرفية مباشرة إلى السيرفر.
- أن تكون قد قمت بزيادة حجم القرص فعلاً من منصة الافتراضية Hypervisor أو من لوحة المزود، ففي Proxmox تفعل ذلك من [Hardware ثم Disk Action ثم Resize](https://pve.proxmox.com/wiki/Resize%5Fdisks?ref=arabroot.io) أو بالأمر `qm resize`، وإذا لم تنشئ الجهاز بعد فراجع دليل [إنشاء أول VM في Proxmox بعنوان IP ثابت](https://arabroot.io/articles/%D8%A5%D9%86%D8%B4%D8%A7%D8%A1-%D8%A3%D9%88%D9%84-vm-%D9%81%D9%8A-proxmox-%D8%A8%D8%B9%D9%86%D9%88%D8%A7%D9%86-ip-%D8%AB%D8%A7%D8%A8%D8%AA/).

## لماذا لا يظهر الحجم الجديد؟

بين القرص ونظام الملفات عدة طبقات، ولكل طبقة منها حجمها الخاص الذي لا يتغير إلا إذا غيرته أنت، وعندما تزيد حجم القرص من الخارج فأنت تغير الطبقة الأولى فقط، والجدول التالي يبين هذه الطبقات والأداة التي توسع كل واحدة منها:

| الطبقة                          | مثال                | أداة التوسيع                   |
| ------------------------------- | ------------------- | ------------------------------ |
| القرص (Disk)                    | /dev/sda            | Proxmox أو لوحة المزود         |
| القسم (Partition)               | /dev/sda3           | growpart                       |
| المجلد الفعلي (Physical Volume) | /dev/sda3           | pvresize                       |
| المجموعة (Volume Group)         | ubuntu-vg           | تكبر تلقائياً مع المجلد الفعلي |
| المجلد المنطقي (Logical Volume) | ubuntu-vg/ubuntu-lv | lvextend                       |
| نظام الملفات                    | ext4 أو XFS على /   | resize2fs أو xfs\_growfs       |

لذلك سوف نمر على هذه الطبقات بنفس الترتيب من الأسفل إلى الأعلى، والسبب أن كل طبقة لا ترى إلا ما أعطته لها الطبقة التي تحتها، فإذا تخطيت طبقة واحدة فلن تصل المساحة إلى أي طبقة فوقها.

## قبل أن تبدأ

### خذ Snapshot أو نسخة احتياطية

توسيع الأقسام عملية مألوفة وآمنة إذا نفذتها على الجهاز الصحيح، ولكن خطوة `growpart` تعيد كتابة جدول الأقسام Partition Table، وخطأ واحد في اسم القرص قد يكلفك النظام كله، لذلك خذ Snapshot للجهاز من Proxmox أو من لوحة المزود، أو نسخة احتياطية Backup حديثة، قبل أن تنفذ أي أمر في هذا الدليل، والسبب أن الرجوع من Snapshot يأخذ دقائق، أما إصلاح جدول أقسام تالف فقد يأخذ يومك كله إن نجح أصلاً.

### تعرف على أسماء الأجهزة في سيرفرك

لا تفترض أن القسم هو `sda3` وأن المجلد المنطقي هو `ubuntu-vg/ubuntu-lv` لمجرد أنها الأسماء التي تراها في الأمثلة، والسبب أن الأسماء تختلف بحسب نوع القرص، فهي `/dev/sda` لأقراص SCSI وSATA، و`/dev/vda` لأقراص VirtIO الشائعة عند المزودين، و`/dev/nvme0n1` لأقراص NVMe، ولاحظ أن الحرف `p` يسبق رقم القسم في NVMe، فيصبح القسم الثالث `/dev/nvme0n1p3`. ابدأ بالأمر [lsblk](https://manpages.ubuntu.com/manpages/noble/man8/lsblk.8.html?ref=arabroot.io) كما يلي:

```bash
df -hT /
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
```

والمخرج سوف يكون كما يلي:

```bash
Filesystem                        Type  Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv ext4   19G   15G  3.1G  83% /

NAME                      SIZE TYPE FSTYPE      MOUNTPOINTS
sda                        80G disk
├─sda1                      1M part
├─sda2                      2G part ext4        /boot
└─sda3                     38G part LVM2_member
  └─ubuntu--vg-ubuntu--lv  19G lvm  ext4        /
```

في المخرج أعلاه لاحظ التالي:

- القرص `sda` أصبح 80G، ولكن القسم `sda3` ما زال 38G، والمجلد المنطقي الذي يحمل `/` حجمه 19G فقط.
- العمود `FSTYPE` يخبرك بنوع نظام الملفات، سواءً كان `ext4` أو `xfs`، وهو الذي يحدد الأداة التي سوف تستخدمها لاحقاً.
- القسم الذي سوف توسعه هو القسم الذي تجد في عموده `FSTYPE` القيمة `LVM2_member` وتحته مباشرة جهاز من نوع `lvm`، وليس بالضرورة آخر رقم في القائمة.

إذن عليك أن تأخذ من هذا المخرج ثلاثة أشياء وتكتبها أمامك: اسم القرص، ورقم القسم الذي يحمل LVM، ونوع نظام الملفات. بعد ذلك اعرض طبقات LVM بالأوامر [pvs](https://manpages.ubuntu.com/manpages/noble/man8/pvs.8.html?ref=arabroot.io) و[vgs](https://manpages.ubuntu.com/manpages/noble/man8/vgs.8.html?ref=arabroot.io) و[lvs](https://manpages.ubuntu.com/manpages/noble/man8/lvs.8.html?ref=arabroot.io):

```bash
sudo pvs
sudo vgs
sudo lvs
```

```bash
  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda3  ubuntu-vg lvm2 a--  <38.00g 19.00g
  VG        #PV #LV #SN Attr   VSize   VFree
  ubuntu-vg   1   1   0 wz--n- <38.00g 19.00g
  LV        VG        Attr       LSize
  ubuntu-lv ubuntu-vg -wi-ao---- <19.00g
```

الأمر `pvs` يعرض القسم الذي يعمل كمجلد فعلي والمجموعة التي ينتمي إليها، والأمر `vgs` يعرض في العمود `VFree` المساحة الحرة Free Space غير المخصصة داخل المجموعة، أما `lvs` فيعرض اسم المجلد المنطقي وحجمه. وفي هذا المثال سوف تجد أن هناك 19G حرة أصلاً داخل المجموعة، وهذا ما يتركه التثبيت الموجه في Ubuntu عادة كما سيأتي، وفوقها نحو 40G جديدة على القرص لم يصل إليها القسم بعد.

💡

المسار الكامل للمجلد المنطقي هو `/dev/<VG>/<LV>`، أي `/dev/ubuntu-vg/ubuntu-lv` في هذا المثال، ويشير إليه أيضاً المسار `/dev/mapper/ubuntu--vg-ubuntu--lv` الذي يظهر في `df`، والسبب في الشرطة المزدوجة أن Device Mapper يضاعف الشرطة الموجودة داخل الأسماء، وفي النهاية فالمساران يشيران إلى نفس الجهاز.

## خطوات التوسيع

الأوامر التالية تستخدم أسماء المثال، أي القرص `/dev/sda` والقسم رقم 3 والمجلد `/dev/ubuntu-vg/ubuntu-lv`، لذلك ضع مكانها ما ظهر لك أنت في الخطوة السابقة، ولا تنسخ الأوامر كما هي قبل أن تقارن كل اسم فيها بمخرج `lsblk` على سيرفرك.

### تأكد من أن النظام يرى الحجم الجديد للقرص

إذا عرض `lsblk` الحجم الجديد للقرص فانتقل مباشرة إلى الخطوة التالية، والسبب أن النواة Kernel تلتقط التغيير تلقائياً في أغلب الحالات، و[وثائق Proxmox](https://pve.proxmox.com/wiki/Resize%5Fdisks?ref=arabroot.io) تذكر أن أقراص VirtIO تظهر بحجمها الجديد دون إعادة تشغيل. ولكن إذا بقي الحجم القديم على قرص SCSI أو SATA، فاطلب من النواة أن تعيد فحص القرص كما يلي:

```bash
echo 1 | sudo tee /sys/class/block/sda/device/rescan
sudo dmesg | tail -n 5
lsblk /dev/sda
```

وقد يتساءل البعض: لماذا نستخدم `tee` هنا بدلاً من الصيغة الأقصر `sudo echo 1 > …`؟ والإجابة أن هذه الصيغة تفشل، لأن ال Shell هو الذي ينفذ إعادة التوجيه بصلاحيات المستخدم العادي وليس بصلاحيات `sudo`، أما `tee` فيعمل هو نفسه بصلاحيات `sudo` ويكتب في الملف. بعد التنفيذ يجب أن ترى في `dmesg` سطراً من نوع `detected capacity change`، وإذا لم يتغير الحجم رغم ذلك فأعد تشغيل السيرفر في وقت مناسب.

### توسيع القسم بالأمر growpart

الأداة [growpart](https://manpages.ubuntu.com/manpages/noble/man1/growpart.1.html?ref=arabroot.io) جزء من الحزمة [cloud-guest-utils](https://packages.ubuntu.com/noble/cloud-guest-utils?ref=arabroot.io)، وسوف تجدها مثبتة غالباً على الصور السحابية Cloud Images، ووظيفتها أن تمد القسم حتى نهاية القرص أو حتى بداية القسم الذي يليه، ولاحظ أنها تزيد حجم القسم فقط ولا تستطيع أن تنقصه. ابدأ بتشغيلها مع الخيار `--dry-run` حتى ترى ما سوف تفعله دون أن تكتب شيئاً على القرص:

```bash
sudo apt update
sudo apt install -y cloud-guest-utils
sudo growpart --dry-run /dev/sda 3
```

لاحظ أن `growpart` يأخذ القرص ورقم القسم منفصلين بمسافة: `/dev/sda 3`، ومع NVMe `/dev/nvme0n1 3`. والمخرج يبدأ بسطر `CHANGE` ثم يعرض جدول الأقسام قبل التغيير وبعده، فتأكد من أن رقم البداية `start` للقسم لم يتغير وأن الحجم الجديد فقط هو الذي كبر، ولأن الخيار `--dry-run` لا يكتب أي شيء على القرص، فهذه هي اللحظة المناسبة لاكتشاف أي خطأ في اسم القرص أو رقم القسم. وإذا بدا المخرج صحيحاً فنفذ التوسيع ثم تحقق:

```bash
sudo growpart /dev/sda 3
lsblk /dev/sda
```

والمخرج سوف يكون كما يلي:

```bash
CHANGED: partition=3 start=4198400 old: size=79691776 end=83890175 new: size=163573727 end=167772126
```

### توسيع المجلد الفعلي بالأمر pvresize

الآن كبر القسم، ولكن LVM ما زال يرى المجلد الفعلي بحجمه القديم، وهنا يأتي دور الأمر [pvresize](https://manpages.ubuntu.com/manpages/noble/man8/pvresize.8.html?ref=arabroot.io) الذي يقرأ الحجم الجديد للقسم ويضيف الفرق إلى المجموعة، ويعمل والمجلدات المنطقية نشطة والنظام يعمل عليها:

```bash
sudo pvresize /dev/sda3
sudo vgs
```

والمخرج سوف يكون كما يلي:

```bash
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
  VG        #PV #LV #SN Attr   VSize   VFree
  ubuntu-vg   1   1   0 wz--n- <78.00g <59.00g
```

### توسيع المجلد المنطقي ونظام الملفات

أصبحت المساحة كلها حرة داخل المجموعة، وبقي أن تعطيها للمجلد المنطقي بالأمر [lvextend](https://manpages.ubuntu.com/manpages/noble/man8/lvextend.8.html?ref=arabroot.io)، حيث يضيف الخيار `-l +100%FREE` كل المساحة الحرة في المجموعة، ويوسع الخيار `-r` (أو `--resizefs`) نظام الملفات في نفس الخطوة عبر الأداة `fsadm`، وهو يعمل مع ext4 وXFS، وبالتالي لا تحتاج لتذكر أداة كل نظام ملفات:

```bash
sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
```

وإذا أردت أن تبقي جزءاً من المساحة لمجلد منطقي آخر أو لـ Snapshot من LVM، فحدد مقدار الزيادة بدلاً من ذلك، مثل `-L +20G`.

### توسيع نظام الملفات يدوياً

إذا وسعت المجلد المنطقي دون الخيار `-r`، فسوف يبقى نظام الملفات بحجمه القديم حتى توسعه بأداته، وتستطيع أن تفعل ذلك ونظام الملفات مركب Mounted والسيرفر يعمل، حيث توسع الأداة [resize2fs](https://manpages.ubuntu.com/manpages/noble/man8/resize2fs.8.html?ref=arabroot.io) نظام ext4 وهو مركب، أما الأداة [xfs\_growfs](https://manpages.ubuntu.com/manpages/noble/man8/xfs%5Fgrowfs.8.html?ref=arabroot.io) فلا توسع XFS أصلاً إلا وهو مركب.

مع ext4 مرر مسار المجلد المنطقي:

```bash
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
```

ومع XFS مرر نقطة التركيب Mount Point كما في صفحة الدليل الرسمية للأداة:

```bash
sudo xfs_growfs /
```

⚠️

لا تشغل `resize2fs` على نظام XFS، ولا `xfs_growfs` على ext4، وتحقق من النوع في العمود `FSTYPE` أو بالأمر `df -hT /` قبل التنفيذ. وتذكر أن التوسيع هنا في اتجاه واحد عملياً، والسبب أن XFS لا يدعم التصغير Shrink إلا في حدود ضيقة جداً في إصداراته الحديثة، وتصغير ext4 يتطلب فك تركيبه، لذلك لا تضف إلى المجلد المنطقي أكثر مما تحتاج إذا كنت تخطط لاستخدام المساحة في شيء آخر.

## إذا كانت المساحة الحرة موجودة في المجموعة أصلاً

لا تحتاج دائماً إلى المرور بكل الطبقات، فإذا لم تقم بزيادة حجم القرص ولكن `sudo vgs` يعرض مساحة في العمود `VFree`، فهذه حالة التثبيت الموجه الذي ترك جزءاً من المجموعة غير مخصص، ويكفيك أمر واحد:

```bash
sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
```

ولكن لماذا يترك Ubuntu هذه المساحة دون استخدام أصلاً؟ والإجابة أن المثبت يعمل افتراضياً بسياسة الحجم [sizing-policy: scaled](https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html?ref=arabroot.io#ai-sizing-policy)، والتي تعطي المجلد المنطقي للنظام نصف المجموعة فقط إذا كان حجمها بين 20 و200 GiB، و100 GiB فقط إذا زادت على ذلك، والهدف أن تبقى مساحة لل Snapshots ولأي توسعة لاحقة، لذلك افحص هذا أولاً على أي سيرفر جديد مثبت بـ Ubuntu Server، فقد تجد نصف القرص غير مستخدم دون أن تحتاج إلى تكبير شيء، ثم قرر بنفسك هل تعطيه كله للنظام أم تبقي جزءاً منه بالخيار `-L`.

## كيف تتأكد أن المساحة وصلت فعلاً

```bash
df -hT /
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sudo vgs
```

```bash
Filesystem                        Type  Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv ext4   77G   15G   58G  21% /
```

- يعرض `df -hT /` الحجم الجديد، وتكون قيمة `Size` قريبة من حجم المجلد المنطقي.
- يعرض `lsblk` القسم والمجلد المنطقي بالحجم المتوقع.
- تكون قيمة `VFree` صفراً، أو المقدار الذي قررت الاحتفاظ به.

بعد أن تتأكد أن السيرفر وخدماته تعمل بشكل طبيعي، احذف ال Snapshot الذي أخذته من Proxmox أو من لوحة المزود، والسبب أنه إذا بقي مدة طويلة فسوف يستهلك مساحة التخزين، وقد يبطئ القرص على بعض أنواع التخزين.

## مشكلات شائعة وحلولها

### رسالة NOCHANGE من growpart

الرسالة `NOCHANGE: partition 3 is size … it cannot be grown` تعني أن الأداة لم تجد أي مساحة بعد القسم، ولها ثلاثة أسباب شائعة: إما أن النظام لم ير الحجم الجديد للقرص بعد (راجع خطوة إعادة الفحص)، أو أن القسم موسع من قبل، أو أن بعده مباشرة قسماً آخر. وهناك رسالة قريبة منها تبدأ أيضاً بـ NOCHANGE وتقول إن القسم could only be grown by عدد صغير من القطاعات، ومعناها أن الزيادة المتاحة أقل من الحد الأدنى الذي تتجاهله الأداة، وهو 1 MiB في الإصدار 0.33 الموجود في Ubuntu 24.04.

### القسم ليس الأخير على القرص، أو بعده قسم Swap

الأداة `growpart` تمد القسم حتى بداية القسم التالي فقط ولا تستطيع تجاوزه، وسوف تجد هذا الترتيب أحياناً في الأنظمة القديمة أو في تثبيت يدوي وضع قسم Swap بعد قسم النظام الرئيسي Root Partition، والحل الأسلم هنا هو العمل والجهاز متوقف Offline كما [تشرحها وثائق Proxmox](https://pve.proxmox.com/wiki/Resize%5Fdisks?ref=arabroot.io)، أي أن تقلع الجهاز من أداة مثل GParted، وتنقل القسم المعترض أو تحذفه وتعيد إنشاءه، ثم توسع القسم المطلوب. وإذا كان القسم المعترض Swap فأوقفه أولاً بالأمر [swapoff](https://manpages.ubuntu.com/manpages/noble/man8/swapoff.8.html?ref=arabroot.io)، وحدث `/etc/fstab` إذا تغير معرفه UUID، والسبب أن السيرفر سوف ينتظر عند الإقلاع قسماً لم يعد موجوداً بنفس المعرف.

### تحذيرات GPT بعد زيادة حجم القرص

يحفظ جدول GPT نسخة احتياطية من ال Header الخاص به (Backup GPT Header) في آخر القرص، وبعد زيادة الحجم تبقى هذه النسخة في موضعها القديم، فترى في `fdisk` أو `parted` رسائل مثل `GPT PMBR size mismatch` أو `Not all of the space available … appears to be used`، وهذا متوقع ولا يعني أن هناك تلفاً، و`growpart` يصلحه عادة عندما يعيد كتابة الجدول. وإذا بقي التحذير فانقل هذه النسخة إلى آخر القرص بالأمر [sgdisk -e](https://manpages.ubuntu.com/manpages/noble/man8/sgdisk.8.html?ref=arabroot.io):

```bash
sudo sgdisk -e /dev/sda
```

### رسالة matches existing size أو Insufficient free space من lvextend

معناها أن المجموعة ليس فيها مساحة حرة، فإما أنك لم تنفذ `pvresize` بعد توسيع القسم، وإما أن المساحة أضيفت من قبل إلى المجلد المنطقي، وفي الحالة الثانية يكفيك أن توسع نظام الملفات بالأداة المناسبة لنوعه.

### الأمر growpart غير موجود

ثبت الحزمة `cloud-guest-utils` كما في خطوة التوسيع، وإذا لم يكن لديك اتصال بالإنترنت فاستخدم الأمر `resizepart` داخل `parted`، وهو نفس الأمر الذي تستخدمه [وثائق Proxmox](https://pve.proxmox.com/wiki/Resize%5Fdisks?ref=arabroot.io) في مثالها.

## إذا لم يكن النظام مبنياً على LVM

بعض المزودين يسلمون صوراً لا تستخدم LVM، فيكون `/` مركباً مباشرة على قسم مثل `/dev/vda1`، وتعرف ذلك من `lsblk` عندما لا تجد تحت القسم أي جهاز من نوع `lvm`، وفي هذه الحالة تسقط طبقتا LVM وتكفيك خطوتان:

```bash
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1
```

ومع XFS استبدل الأمر الثاني بـ `sudo xfs_growfs /`. ويجدر الإشارة هنا إلى أن كثيراً من الصور السحابية تجري هذا التوسيع تلقائياً عند الإقلاع Boot عبر cloud-init، لذلك افحص `df -h /` بعد إعادة التشغيل قبل أن تبدأ، فقد تجد أن العمل قد تم بالفعل. وإذا كنت ما زلت تبحث عن مزود مناسب، فراجع دليل [كيف تختار خادماً افتراضياً VPS](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%AE%D8%A7%D8%AF%D9%85%D8%A7-%D8%A7%D9%81%D8%AA%D8%B1%D8%A7%D8%B6%D9%8A%D8%A7-vps/).

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- زيادة حجم القرص من Proxmox أو من لوحة المزود تغير الطبقة الأولى فقط، وعليك أن توصل المساحة بنفسك إلى القسم ثم المجلد الفعلي ثم المجلد المنطقي ثم نظام الملفات.
- خذ Snapshot قبل أي أمر، وتعرف على اسم القرص ورقم القسم ونوع نظام الملفات من `lsblk`، وشغل `growpart` أولاً بالخيار `--dry-run` قبل التنفيذ.
- الأوامر الثلاثة `growpart` و`pvresize` و`lvextend -r` تعمل والسيرفر يعمل، ولا تحتاج إلى إعادة تشغيل.
- افحص `VFree` على كل سيرفر Ubuntu جديد، فالمثبت يترك عمداً جزءاً من المجموعة غير مخصص.

## سجل التحديثات

- أكتوبر 2026: كتابة الدليل.
- أكتوبر 2026: مراجعة تقنية للأوامر على lvm2 2.03.16 وcloud-guest-utils 0.33 في Ubuntu 24.04، وتصحيح مخرج `growpart` و`pvresize` وحد الزيادة الأدنى في `growpart`، وإضافة سبب المساحة الحرة التي يتركها مثبت Ubuntu.