Unknown filesystem after fdisk partitioning
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
0
down vote
favorite
I just resized my primary partition according to the answer given in StackExchange. I used the method with fdisk
. I deleted the partition and then recreated it and as suggested in the post.
After this I rebooted my PC to update the partions table.
Then the grub>
prompt greeted me since it couldnt find the needed linux partition. Trying to look up the data of my partition in grub using ls (hd0,gpt6) /
reported that grub doesnt know the given file system.
And now I used a live Linux to try and figure out what caused the problem and how to fix it without loosing the data on this partition.
Looking at this partition in gparted is see that gparted is unable to identify the filesystem as well. When I run blkid
this partition doesnt even show up. But when I run fdisk
from the Live Linux it correctly identifies this partion as beeing a Linux Filesystem.
fdisk:
Command (m for help): p
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D98C1DC3-A8A5-4707-AAA8-2AC8C2A7CDBD
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 534527 532480 260M EFI System
/dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
/dev/nvme0n1p3 567296 306978815 306411520 146.1G Microsoft basic data
/dev/nvme0n1p4 474914816 478550015 3635200 1.8G Windows recovery environment
/dev/nvme0n1p5 478550016 500107263 21557248 10.3G Microsoft basic data
/dev/nvme0n1p6 306978816 474914815 167936000 80.1G Linux filesystem *
Partition table entries are not in disk order.
.* this partition is of interest
The partition was formatted as ext4
and I extended it by changing the partitions starting point (this is the only thing I see beeing diffrent to the answer I followed).
dual-boot partitioning gparted ext4 fdisk
add a comment |Â
up vote
0
down vote
favorite
I just resized my primary partition according to the answer given in StackExchange. I used the method with fdisk
. I deleted the partition and then recreated it and as suggested in the post.
After this I rebooted my PC to update the partions table.
Then the grub>
prompt greeted me since it couldnt find the needed linux partition. Trying to look up the data of my partition in grub using ls (hd0,gpt6) /
reported that grub doesnt know the given file system.
And now I used a live Linux to try and figure out what caused the problem and how to fix it without loosing the data on this partition.
Looking at this partition in gparted is see that gparted is unable to identify the filesystem as well. When I run blkid
this partition doesnt even show up. But when I run fdisk
from the Live Linux it correctly identifies this partion as beeing a Linux Filesystem.
fdisk:
Command (m for help): p
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D98C1DC3-A8A5-4707-AAA8-2AC8C2A7CDBD
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 534527 532480 260M EFI System
/dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
/dev/nvme0n1p3 567296 306978815 306411520 146.1G Microsoft basic data
/dev/nvme0n1p4 474914816 478550015 3635200 1.8G Windows recovery environment
/dev/nvme0n1p5 478550016 500107263 21557248 10.3G Microsoft basic data
/dev/nvme0n1p6 306978816 474914815 167936000 80.1G Linux filesystem *
Partition table entries are not in disk order.
.* this partition is of interest
The partition was formatted as ext4
and I extended it by changing the partitions starting point (this is the only thing I see beeing diffrent to the answer I followed).
dual-boot partitioning gparted ext4 fdisk
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I just resized my primary partition according to the answer given in StackExchange. I used the method with fdisk
. I deleted the partition and then recreated it and as suggested in the post.
After this I rebooted my PC to update the partions table.
Then the grub>
prompt greeted me since it couldnt find the needed linux partition. Trying to look up the data of my partition in grub using ls (hd0,gpt6) /
reported that grub doesnt know the given file system.
And now I used a live Linux to try and figure out what caused the problem and how to fix it without loosing the data on this partition.
Looking at this partition in gparted is see that gparted is unable to identify the filesystem as well. When I run blkid
this partition doesnt even show up. But when I run fdisk
from the Live Linux it correctly identifies this partion as beeing a Linux Filesystem.
fdisk:
Command (m for help): p
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D98C1DC3-A8A5-4707-AAA8-2AC8C2A7CDBD
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 534527 532480 260M EFI System
/dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
/dev/nvme0n1p3 567296 306978815 306411520 146.1G Microsoft basic data
/dev/nvme0n1p4 474914816 478550015 3635200 1.8G Windows recovery environment
/dev/nvme0n1p5 478550016 500107263 21557248 10.3G Microsoft basic data
/dev/nvme0n1p6 306978816 474914815 167936000 80.1G Linux filesystem *
Partition table entries are not in disk order.
.* this partition is of interest
The partition was formatted as ext4
and I extended it by changing the partitions starting point (this is the only thing I see beeing diffrent to the answer I followed).
dual-boot partitioning gparted ext4 fdisk
I just resized my primary partition according to the answer given in StackExchange. I used the method with fdisk
. I deleted the partition and then recreated it and as suggested in the post.
After this I rebooted my PC to update the partions table.
Then the grub>
prompt greeted me since it couldnt find the needed linux partition. Trying to look up the data of my partition in grub using ls (hd0,gpt6) /
reported that grub doesnt know the given file system.
And now I used a live Linux to try and figure out what caused the problem and how to fix it without loosing the data on this partition.
Looking at this partition in gparted is see that gparted is unable to identify the filesystem as well. When I run blkid
this partition doesnt even show up. But when I run fdisk
from the Live Linux it correctly identifies this partion as beeing a Linux Filesystem.
fdisk:
Command (m for help): p
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D98C1DC3-A8A5-4707-AAA8-2AC8C2A7CDBD
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 534527 532480 260M EFI System
/dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
/dev/nvme0n1p3 567296 306978815 306411520 146.1G Microsoft basic data
/dev/nvme0n1p4 474914816 478550015 3635200 1.8G Windows recovery environment
/dev/nvme0n1p5 478550016 500107263 21557248 10.3G Microsoft basic data
/dev/nvme0n1p6 306978816 474914815 167936000 80.1G Linux filesystem *
Partition table entries are not in disk order.
.* this partition is of interest
The partition was formatted as ext4
and I extended it by changing the partitions starting point (this is the only thing I see beeing diffrent to the answer I followed).
dual-boot partitioning gparted ext4 fdisk
dual-boot partitioning gparted ext4 fdisk
asked Feb 21 at 19:07
Veladus
1
1
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
Changing the starting point of a partition, is effectively the same as removing or dding pages to the beginning of a book, leaving the reader (here the OS) without chance to know where the book originally started.
Restore the starting point to its original values, then check and mount the file system. If you don't remember the value for the starting point, yuo can try to scan the partition with Testdisk or photorec from a live session to see what they are able to recover - some dat might be lost though.
And next time only expand partitions in the back end (right end in gparted) NEVER from the starting point. If free space is before the partition, you will have to move the partition left into the free space in gparted, and the expand partition to the right.
And NEVER move / or /boot partition without checking up on the extra steps needed to regenerate boot-/grub-configuration.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Changing the starting point of a partition, is effectively the same as removing or dding pages to the beginning of a book, leaving the reader (here the OS) without chance to know where the book originally started.
Restore the starting point to its original values, then check and mount the file system. If you don't remember the value for the starting point, yuo can try to scan the partition with Testdisk or photorec from a live session to see what they are able to recover - some dat might be lost though.
And next time only expand partitions in the back end (right end in gparted) NEVER from the starting point. If free space is before the partition, you will have to move the partition left into the free space in gparted, and the expand partition to the right.
And NEVER move / or /boot partition without checking up on the extra steps needed to regenerate boot-/grub-configuration.
add a comment |Â
up vote
0
down vote
Changing the starting point of a partition, is effectively the same as removing or dding pages to the beginning of a book, leaving the reader (here the OS) without chance to know where the book originally started.
Restore the starting point to its original values, then check and mount the file system. If you don't remember the value for the starting point, yuo can try to scan the partition with Testdisk or photorec from a live session to see what they are able to recover - some dat might be lost though.
And next time only expand partitions in the back end (right end in gparted) NEVER from the starting point. If free space is before the partition, you will have to move the partition left into the free space in gparted, and the expand partition to the right.
And NEVER move / or /boot partition without checking up on the extra steps needed to regenerate boot-/grub-configuration.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Changing the starting point of a partition, is effectively the same as removing or dding pages to the beginning of a book, leaving the reader (here the OS) without chance to know where the book originally started.
Restore the starting point to its original values, then check and mount the file system. If you don't remember the value for the starting point, yuo can try to scan the partition with Testdisk or photorec from a live session to see what they are able to recover - some dat might be lost though.
And next time only expand partitions in the back end (right end in gparted) NEVER from the starting point. If free space is before the partition, you will have to move the partition left into the free space in gparted, and the expand partition to the right.
And NEVER move / or /boot partition without checking up on the extra steps needed to regenerate boot-/grub-configuration.
Changing the starting point of a partition, is effectively the same as removing or dding pages to the beginning of a book, leaving the reader (here the OS) without chance to know where the book originally started.
Restore the starting point to its original values, then check and mount the file system. If you don't remember the value for the starting point, yuo can try to scan the partition with Testdisk or photorec from a live session to see what they are able to recover - some dat might be lost though.
And next time only expand partitions in the back end (right end in gparted) NEVER from the starting point. If free space is before the partition, you will have to move the partition left into the free space in gparted, and the expand partition to the right.
And NEVER move / or /boot partition without checking up on the extra steps needed to regenerate boot-/grub-configuration.
answered Feb 21 at 20:14
Soren A
3,0681724
3,0681724
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1008485%2funknown-filesystem-after-fdisk-partitioning%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password