You cannot specify 1 as the first sector of a partition for a GPT partitioned disk.
for more information.
The reason of first usable LBA being 34 is simple. LBA 0 is Protective MBR, LBA 1 is GPT Header and the required space for partition entries ...
As far I can see Windows 10 has created an invalid GPT structure which neither the Linux kernel, not gdisk can recognize. Here's how you can try solving the issue.
Boot into Windows, run under the administrator cmd:
wmic partition get BlockSize, Name, Index, StartingOffset, Size
Write down/save all the partitions and offsets of the disk you're interested in....
If you are OK using the GUI, instead of a CLI or API:
While the filesystem is mounted:
Use the "disks" app (on Ubuntu).
Click on the encrypted device in the list of devices on the left.
Under Volumes, click on the Ext 4 partition.
Click the settings icon.
Click on "Edit Filesystem Label" (likely says "Edit Filesystem ...").
An easy way is to use the lsblk command.
# list all block devices without paritions
# to exclude any particular type of block device like optical drives
lsblk --nodeps --exclude 11
A full list of block device ids can be found at https://www.kernel.org/doc/Documentation/admin-guide/devices.txt
for b in /sys/block/*; do readlink -f $b; done
for b in /sys/block/*; do echo $(cat $b/uevent); done
/sys/class/block/* if you also want the partitions.
grep -srl DEVTYPE=disk /sys/devices
grep -srl DEVTYPE=partition /sys/devices
Step 1 - You have to use Ubuntu Live USB.
Step 2 - Boot from Live USB and open GParted.
Step 3 - Select the drive from which you want to free up space.
Step 4 - Adjust the cursor on GParted, to free up the space needed.
Step 5 - If there is any partition like home or swap, above the unallocated space, select the partition and move it to the right using ...
you wont find any more space in /dev/sda2 because you didn't extend it or create another new partition with the new space .
you should create new /dev/sda3 with the 350GB by the following commands :
n create new
p primary partition
//then change the partition type to lvm using this :
t to change type
8e is for lvm ...
blkid determines the type of the device's content based on the content metadata. In your case, /dev/mmcblk0p32 is actually formatted as an ext2 file system.
On the other hand, the file system type in /proc/mounts has the same semantics of mount's -t option: the type from the kernel's point of view (i.e. the driver to use).
The ext4 file system driver can, ...
You must extend the volume group before you extend the logical volume, because the logical volume is contained in the volume group.
To perform these operations, you must have the filesystems unmounted. The easiest way to have them unmounted and still be able to work on the system is to run a live linux operating system.
Usually this live system would be on a ...
You cannot. This usage is specifically disallowed. The disk metadata exists in too many separate places (on disk, in kernel data structures, in gparted). Keeping them all synchronized is too hard for software to do. Boot from a Live USB.
To format the partitions contained in the disk image, you can first create block device files for the partitions. With the device files in place you can use mkfs as you normally would. When you're finished, then you can remove the device files.
Create and list the block device files: kpartx -av sd.img
Format each partition. Ex. mkfs.fat /dev/mapper/loop0p1
This option doesn't make any sense if you don't specify a device to work on. In a perfect world blkid -O 18446744073709551615 should just print something like,"-O offset requires an argument" and exit but it doesn't. You may file a bug report here https://bugz.fedoraproject.org/util-linux
From the man page:
-O, --offset offset
Probe at the ...
First off, it looks like you are mounting the partitions from the live image, which will not persist once you reboot into the installed system. As others have mentioned, you need to add an entry to your /etc/fstab (see fstab) in order to have the "home" partition auto mounted to /home.
When you log in as a non-root user, if your working directory ...
Your large disk partition /dev/nvme0n1p3 appears to contain a LUKS encrypted container /dev/mapper/nvme0n1p3_crypt.
At a guess this in turn contains a Volume Group called ubuntu-vg, and you can confirm this with pvs. The reason for this guess is that you have shown us two Logical Volumes, named root and swap belonging to a VG called ubuntu-vg.
What's strange ...
You've seemingly destroyed your partition. Boot into Windows, try running chkdsk. Before running chkdsk I'd recommend making a full byte to byte copy of the disk because chkdsk may make data restoration impossible.
You should probably avoid resizing NTFS partitions using Linux utilities in the future: either use Windows Disk Manager or tools like Acronis ...
You have the fdisk code in another answer. But note that you don't have to use fdisk. There are other partitioning tools, and one in particular might be useful here.
On Rod Smith's gdisk the Microsoft Basic Data partition type is shorthand code 0700 in the tool. gdisk shorthand codes are in hexadecimal, and are 16-bit integers rather than the underlying (...