[solved] FSTYPE on partition incorrect

mouseman · 2015-12-12 10:35:21

There's something confusing in my partitions which I would like to fix before I do something stupid, like, remove it .

$ sudo gdisk -l /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme0n1: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9C85E274-7C7B-451B-AA3B-FAD6E4B40E09
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624         2099199   512.0 MiB   8300  Linux filesystem
   3         2099200        85985279   40.0 GiB    8300  Linux filesystem
   4        85985280       169871359   40.0 GiB    8300  Linux filesystem
   5       169871360       170133503   128.0 MiB   0C01  Microsoft reserved ...
   6       170133504       378664959   99.4 GiB    0700  Basic data partition
   7       378664960       379586559   450.0 MiB   2700  
   8       379586560       476055551   46.0 GiB    8300  
   9       476055552       492832767   8.0 GiB     8200  Linux swap
  10       492832768       500118158   3.5 GiB     BF01  Linux filesystem

$ sudo lsblk -f
NAME         FSTYPE     LABEL                      UUID                                 MOUNTPOINT
<snip>
nvme0n1      zfs_member data                       5897426250624265780                  
├─nvme0n1p1  vfat       EFI                        D2F7-7011                            /boot
├─nvme0n1p2  ext4       BUGUS-BOOT                 a5f85918-1ad6-49c3-93e0-c4214ad8ac4a 
├─nvme0n1p3  ext4       ARCH-ROOT                  f74b4957-ef1e-46ed-9e00-b8da99477e1b /
├─nvme0n1p4  ext4       DEBIAN-ROOT                78e7fcdc-116c-40f8-8f0d-edcce3acb605 
├─nvme0n1p5  ext4       FEDORA-ROOT                55e86e2d-b746-4d3b-ab28-f98882e1fb8f 
├─nvme0n1p6  ntfs       data                       5E2A8E1B2A8DF077                     
├─nvme0n1p7  ntfs       data                       1A7C2D747C2D4BB7                     
├─nvme0n1p8  zfs_member data                       5897426250624265780                  
├─nvme0n1p9  swap       data                       8c077c59-2bcd-4539-bd6c-f0fb7f50272f [SWAP]
└─nvme0n1p10 zfs_member data                       5897426250624265780

As you can see in the partition dump is that p5 is actually partition type 0C01 with the name "Microsoft reserved ...". The lsblk output shows it as FSTYPE ext4 with LABEL FEDORA-ROOT.

I can reset the label, e2label outputs no error but it is not setting a new label, but even then will it still show as ext4 which it isn't. Usually the MSR partition shows as raw or unformatted.

Can I change that to what it is supposed to be (raw or unformatted), without braking the system?

Cheers!

Last edited by mouseman (2016-01-02 09:36:21)

WorMzy · 2015-12-12 11:57:34

Take a look at wipefs, which can remove the ext4 signature (without touching the data).

mouseman · 2015-12-12 12:13:03

Yeah, I was hoping for a way less prone to user mistakes . From what I gather I'd have to use an offset and limit types. Problem is I can't really find any detailed info or examples that help in my case and I can't afford to make a mistake. If this is the only way then I'll leave it like it is. Bummer I can't set the label either, because in a few months time I have probably forgotten about this and that label could save my ass.

respiranto · 2015-12-12 13:20:26

There is a difference between LABEL and PARTLABEL, see the output of `blkid'.
gdisk only cares about the partitions' labels, while lsblk apparently shows the filesystems' labels.
Similarly gdisk shows the partitions' types, while lsblk shows the actually installed filesystems.

So it should be no problem to simply change the partlabel using gdisk and, if you want, also the partition type, which linux does not care about, by the way.

EDIT:

mouseman wrote:

but even then will it still show as ext4 which it isn't.

If that is true, disregard what I said above.

Last edited by respiranto (2015-12-12 13:24:12)

mouseman · 2015-12-12 14:03:02

Thanks, but I know that, I think you're missing the point .

partlabel is actually linked to the code shown by gdisk -l, set with 't' from gdisk menu. I should not change that as it is set for p5 by the windows installer.

So no, I don't want to change the partition type. I simply wanted to change the label shown by lsblk (which is the same as the LABEL shown by blkid btw) and the ext4 designation since it's not actually ext4. I think the previous p5 in the partition table was ext4 and the new partition simply inherited it when Windows installer created it.

The way lsblk now lists the partition is confusing as it looks like it's one of the removed distributions. In a few months time I might get bored and not pay attention, thinking I'd forgot to clean up today and remove it in my boredom. A proper label and removing the ext4 would most likely prevent that . Wipefs can help with the latter, but I think its too prone to errors because I don't know how that works exactly (with the offset and type limits).

Edit: didn't see your edit until I posted and refreshed the page .

Last edited by mouseman (2015-12-12 14:09:56)

respiranto · 2015-12-12 15:10:40

wipefs(8):

EXAMPLES
       wipefs --all --backup /dev/sdb
              Erases all signatures from the device /dev/sdb and creates  a
              signature backup file ~/wipefs-sdb-<offset>.bak for each sig‐
              nature.

       dd if=~/wipefs-sdb-0x00000438.bak  of=/dev/sdb  seek=$((0x00000438))
       bs=1 conv=notrunc
              Restores  an  ext2  signature from the backup file  ~/wipefs-
              sdb-0x00000438.bak.

If you still don't trust this, you could consider backing up the whole partition.

mouseman · 2015-12-12 16:17:12

I appreciate you're trying to help but I'm not going to use wipefs for the simple fact that I don't know exactly how to do it and I have no way to verify the command outcome. I don't want to have to restore or go through disaster recovery right now.

So, using wipefs is out of the question for this.

I was hoping for a more simpler way but there's no immediate problem, just that it's confusing me that's all.

tom.ty89 · 2015-12-20 00:03:50

Just tested with mkfs.ext4 -L test /dev/sda3 and then e2label /dev/sda3 '' on a spare empty partition. works fine here to set/clear the LABEL.

If you want it to be an empty partition without any filesystem (or data) on it, then you just zero it out with shred or dd. If all you want is no longer see "ext4" in lsblk -f, wipefs is exactly what you want.

There's simply nothing to worry about. Even if Windows actually had ever stored anything there it would had been destroyed already anyway, since the "ext4" in lsblk -f means that there IS an ext4 filesystem on the partition. The only thing to worry is whether you actually stores anything in the filesystem, which you can try to mount it and check before wiping.

Last edited by tom.ty89 (2015-12-20 00:21:26)

Arch Linux

#1 2015-12-12 10:35:21

[solved] FSTYPE on partition incorrect

#2 2015-12-12 11:57:34

Re: [solved] FSTYPE on partition incorrect

#3 2015-12-12 12:13:03

Re: [solved] FSTYPE on partition incorrect

#4 2015-12-12 13:20:26

Re: [solved] FSTYPE on partition incorrect

#5 2015-12-12 14:03:02

Re: [solved] FSTYPE on partition incorrect

#6 2015-12-12 15:10:40

Re: [solved] FSTYPE on partition incorrect

#7 2015-12-12 16:17:12

Re: [solved] FSTYPE on partition incorrect

#8 2015-12-20 00:03:50

Re: [solved] FSTYPE on partition incorrect

Board footer