[SOLVED] Strange gparted situation

Altoid · 2021-03-14 22:08:40

Hello:

Running up to date Devuan Beowulf:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$

My box has five different drives, /dev/sda through /dev/sde and I have a strange thing happening with gparted (v. 0.32.0).

fdisk

[root@devuan ~]# fdisk -l
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk model: KINGSTON SV300S3
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: dos
Disk identifier: 0x0004a8f4

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1            2048  40974335  40972288 19.6G 83 Linux
/dev/sda2        40974336 217677823 176703488 84.3G  5 Extended
/dev/sda3       217677824 234440703  16762880    8G 82 Linux swap / Solaris
/dev/sda5        40976384  45072383   4096000    2G 83 Linux
/dev/sda6        45074432 217677823 172603392 82.3G 83 Linux

Partition table entries are not in disk order.

Disk /dev/sdb: 68.4 GiB, 73407488000 bytes, 143374000 sectors
Disk model: VPBA073C3ETS11 N
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: dos
Disk identifier: 0xbc66305b

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1        2048 143372287 143370240 68.4G 83 Linux

Disk /dev/sdc: 279.4 GiB, 300000000000 bytes, 585937500 sectors
Disk model: ST3300555SS     
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: dos
Disk identifier: 0x30830f4e

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdc1        2048 585936895 585934848 279.4G  5 Extended
/dev/sdc5        4096 585936895 585932800 279.4G 83 Linux

Disk /dev/sdd: 68.4 GiB, 73407488000 bytes, 143374000 sectors
Disk model: GNA073C3ESTT0Z N
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: dos
Disk identifier: 0xa88df1bd

Device     Boot     Start       End  Sectors  Size Id Type
/dev/sdd1  *         2048  39063551 39061504 18.6G 83 Linux
/dev/sdd2        39065598 127748095 88682498 42.3G  5 Extended
/dev/sdd3       127748096 143372287 15624192  7.5G 82 Linux swap / Solaris
/dev/sdd5        39065600  42969087  3903488  1.9G 83 Linux
/dev/sdd6        42971136 127748095 84776960 40.4G 83 Linux

Partition table entries are not in disk order.

Disk /dev/sde: 232.9 GiB, 250056000000 bytes, 488390625 sectors
Disk model: SEAGATE ST32500N
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: dos
Disk identifier: 0x85188518

Device     Boot Start       End   Sectors   Size Id Type
/dev/sde1        2048 488388607 488386560 232.9G 83 Linux
[root@devuan ~]#

blkid:

[root@devuan ~]# blkid
/dev/sda1: LABEL="devuan" UUID="d6841f29-e39b-4c87-9c52-3a9c3bafe2d3" TYPE="ext4" PARTUUID="0004a8f4-01"
/dev/sda3: LABEL="swap" UUID="fb103b4c-e143-4432-a3a0-4883d288bddd" TYPE="swap" PARTUUID="0004a8f4-03"
/dev/sda5: LABEL="log" UUID="c22304ec-0b30-428a-a6ac-500785614702" TYPE="ext4" PARTUUID="0004a8f4-05"
/dev/sda6: LABEL="home" UUID="807e1ce7-72b4-48a3-8f34-65947ea9fd70" TYPE="ext4" PARTUUID="0004a8f4-06"

/dev/sdb1: LABEL="stuff" UUID="49d1369c-ed70-4543-b0ee-ef65327e101b" TYPE="ext4" PARTUUID="bc66305b-01"

/dev/sdc5: LABEL="storage" UUID="bdf33361-5929-433e-ac7f-1a626aa6e844" TYPE="ext4" PARTUUID="30830f4e-05"
/dev/sdd1: UUID="7a33fda5-abda-451b-b6ef-c17553c78810" TYPE="ext4" PARTUUID="a88df1bd-01"
/dev/sdd3: UUID="a806d014-08c4-4d12-87d2-0bd2a2bb60b4" TYPE="swap" PARTUUID="a88df1bd-03"
/dev/sdd5: UUID="f6b70140-07ab-4ff5-b5c5-d05ca2feb03b" TYPE="ext4" PARTUUID="a88df1bd-05"
/dev/sdd6: UUID="8a8a4242-b88a-45cb-b099-59138f895c16" TYPE="ext4" PARTUUID="a88df1bd-06"
/dev/sde1: LABEL="Backup" UUID="ca8dbded-819d-4e2b-b017-0981a75ea718" TYPE="ext4" PARTUUID="85188518-01"
[root@devuan ~]#

The problem is that gparted shows me /dev/sdb as a iso9660 file system labeled MAGIC_BOOT_DISK_v2_0 with a size of 68.37GiB.

Alternatively, gnome-disk-utility 3.30.2 reports it correctly:

Size: 73 GB (73405562880 bytes)
Device: /dev/sdb1
UUID: 49d1369c-ed70-4543-b0ee-ef65327e101b
Partition Type: Linux
Contents: Ext4

And running parted from a terminal also reports it correctly:

groucho@devuan:~$ sudo parted
GNU Parted 3.2
(parted) print list
--- snip ---
Model: IBM-ESXS VPBA073C3ETS11 N (scsi)
Disk /dev/sdb: 73.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  73.4GB  73.4GB  primary  ext4
--- snip ---

I have at some time mounted an *.iso file by the same name as the one reported by gparted using AcetoneISO but it was some time ago and it is not mounted now.
If I mount /dev/sdb, it shows up correctly:

groucho@devuan:~$ mount
--- snip ---
/dev/sda1 on / type ext4 (rw,noatime)
--- snip ---
/dev/sda6 on /home type ext4 (rw,noatime)
/dev/sda5 on /var/log type ext4 (rw,noatime)
/dev/sde1 on /media/backups type ext4 (rw,noatime)
--- snip ---
/dev/sdb1 on /media/stuff type ext4 (rw,relatime)
groucho@devuan:~$

Anyone knows what is going on with gparted?
Scared the daylights out of me when I saw it.

Thanks in advance,

A.

ralph.ronnquist · 2021-03-15 01:15:15

Maybe there are some dangling links in some /dev/disk/by-* directory?

Altoid · 2021-03-15 01:53:28

Hello:

ralph.ronnquist wrote:

... some dangling links in some /dev/disk/by-* directory?

Indeed ...
There was one labeled MAGIC_BOOT_DISK_v2_0 in the /dev/disk/by-label/ folder, linked to /sdb.
And also another link in /dev/disk/by-uuid/ labeled 2006-02-09-19-22-00-00 and also linked to /sdb.

So I opened the folders as root and deleted them.
But after a reboot they were there again.

ie: I delete them, close Thunar and when I open the folders the links are there again.
Seems that they are regenerated instantly.

Thanks for your input.

Best,

A.

ralph.ronnquist · 2021-03-15 03:28:54

interesting.

I would have thought they would be made by udev but then it would be originating from /sys (or somwhere else?) unless something has blessed the system with some special udev rules; then likely in /etc/udev/rules.d rather than /lib/udev/rules.d.
Or possibly there's some residue from some past "journey" in /etc/fstan?

Altoid · 2021-03-15 11:42:52

Hello:

ralph.ronnquist wrote:

interesting.
... unless something has blessed the system with some special udev rules ...
... in /etc/udev/rules.d rather than /lib/udev/rules.d.

Way over my head.

ralph.ronnquist wrote:

... residue from some past "journey" in /etc/fstab? <- took the liberty of correcting fstan

My fstab (checked it just now) is clean, no residue.
Non relevant lines are properly commented.

# /swap partition in ssd
UUID=fb103b4c-e143-4432-a3a0-4883d288bddd  none  swap  defaults  0  0

# log partition in ssd
UUID=c22304ec-0b30-428a-a6ac-500785614702 /var/log ext4 defaults,noatime  0  2
#
# -------------------------------------------------------------------------------------
# backup repository in Seagate 300Gb SATA
# was LABEL=Backup /media/backups  ext4  defaults,noatime  0  2
UUID=ca8dbded-819d-4e2b-b017-0981a75ea718  /media/backups  ext4  defaults,noatime  0  2
#
# -------------------------------------------------------------------------------------
#
# not automatically mounted - root only
# storage repository in 300Gb SAS
# was LABEL=storage  /media/storage  ext4  defaults,auto  0  2
UUID=bdf33361-5929-433e-ac7f-1a626aa6e844 /media/storage ext4 nouser,noauto  0  2
#
# -------------------------------------------------------------------------------------
#
# not automatically mounted - root only
# storage repository in IBM 73Gb SAS  
# was LABEL=stuff  /media/stuff  ext4  defaults,auto  0  2
UUID=49d1369c-ed70-4543-b0ee-ef65327e101b /media/stuff ext4 nouser,noauto  0  2
#
# -------------------------------------------------------------------------------------
#
# added to be able to use USBView 2.0
# see https://slackbuilds.org/repository/14.2/system/usbview/?search=usbview
# in pclinuxos /etc/rc.d/rc.sysinit is supposed to mount it but for some reason doesn't
#
debugfs /sys/kernel/debug debugfs mode=755 0 0

Could it be the last line?

usbview 2.0 wrote:

14.2 > System > usbview (2.0)
USBView is a GTK program that displays the topography of the devices that are
plugged into the USB bus on a Linux machine. It also displays information on
each of the devices. This can be useful to determine if a device is working
properly or not.
For this program to be useful, you will need to mount the debug filesystem
(debugfs). Add this line to your /etc/fstab:
debugfs /sys/kernel/debug debugfs noauto 0 0
Now a simple `mount debugfs` will make the USB info available to USBView.
The debugfs root directory is accessible only to the root user by default.
You can grant access to the USB device info (as well as the rest of the
debugfs tree) with the "uid", "gid", and "mode" mount options. For example:
debugfs /sys/kernel/debug debugfs noauto,mode=755 0 0

Thanks for your input.

Cheers,

A.

fsmithred · 2021-03-15 15:16:42

I had a similar problem, and Ralph's advice helped, but I had to delete those links a few times.

There are three hard drives in this computer. Up until a few months ago, when I plugged in a usb, it would be named /dev/sdd. Then one day it changed to /dev/sde. I've seen this in the past after pulling out a usb without unmounting it, but that always clears with a reboot. This has persisted.

I looked in /dev/disk/* and there were two links to /dev/sdd. One was 'Generic usb something' and the other was 'pci-something' that corresponded to the usb controller slot. I deleted those links two or three times, and they kept coming back. Then I deleted /dev/sdd along with them. That seems to have done it.

Altoid · 2021-03-15 17:08:08

Hello:

fsmithred wrote:

... similar problem ...
... had to delete those links a few times.
... deleted /dev/sdd along with them.

Hmm ...
There is something strange going on here.

Because, just what is recreating these links the instant they are deleted?

I searched for the string with the last digits of the drive's UUID and found two files.
They were in /.local/share/gcfs-metadata.

There were also about 100 or so files of the same type, most dated 2018, 2019 and 2020.
So I got rid of them, to no avail.

The problem remains.

But hold on because the plot thickens considerably.

I then boot into my alternate (in construction) Beowulf 3.1.0 install to see if I can reach into the other installation's system files but I cannot see past /media/groucho/devuan/dev, even as root.

And here is the deal:

As I am writing this post from my alternate Boewulf installation and on a hunch decide to look further.
So I start gparted and what do I see?

I see /dev/sda (instead of /dev/sdb) with the very same filesystem (iso9660) and label (MAGIC_BOOT_DISK_V2_0) and UUID (2006-02-09-19-22-00-00) I see in my other Beowulf 3.1.0 installation.

Not only that, it turns out that (expectedly) /dev/disk/by-label/ has the same link, just to /sda instead of /sdb.
It is obviously the same drive.

What to do now?

Thanks in advance,

A.

Head_on_a_Stick · 2021-03-15 18:18:19

Altoid wrote:

just what is recreating these links the instant they are deleted?

They are created dynamically by udev.

Altoid wrote:

I then boot into my alternate (in construction) Beowulf 3.1.0 install to see if I can reach into the other installation's system files but I cannot see past /media/groucho/devuan/dev, even as root.

That's because udev isn't running in that system so /dev hasn't been populated.

Can we see

wipefs /dev/sdb{,1}

Modify the command if the problematic drive has been assigned a different letter.

Altoid · 2021-03-15 18:46:49

Hello:

Head_on_a_Stick wrote:

They are created dynamically by udev.

I see ...
So udev reads data and creates the links on the fly.
That's why the pop up the instant I delete them.

Head_on_a_Stick wrote:

Can we see
wipefs /dev/sdb{,1}

Of course:

groucho@devuan:~$ sudo wipefs /dev/sdb{,1}
DEVICE OFFSET TYPE    UUID                    LABEL
sdb    0x8001 iso9660 2006-02-09-19-22-00-00  MAGIC_BOOT_DISK_V2_0
sdb    0x1fe  dos                                          
sdb1   0x438  ext4    49d1369c-ed70-4543-b0ee-ef65327e101b stuff
groucho@devuan:~$

That's it!
udev is reading the data held in the drive itself and gparted (unlike gnome-disks and parted) uses it.

The important question would be: just how did that label get wrtitten into the drive?
It is an *.iso file I have used at one time or another.

Thanks for your input.

A.

Head_on_a_Stick · 2021-03-15 18:52:04

Altoid wrote:

It is an *.iso file I have used at one time or another.

Yes, probably.

Clear the magic string with

# wipefs -o 0x8001 /dev/sdb

Altoid · 2021-03-15 21:13:45

Hello:

Head_on_a_Stick wrote:

# wipefs -o 0x8001 /dev/sdb

Done.
Worked a charm. 8^D

gparted now reports as it should, like parted and gnome-disks do .
But then gparted does read from the drive itself, albeit data which is not correct and in doing so prevents it from being able to do anything on that drive.

Head_on_a_Stick wrote:

Altoid wrote:
It is an *.iso file I have used at one time or another.
Yes, probably.

Which brings me back to why this happened.
Any idea as to what may have caused it?

Thanks a lot for your help.

Cheers,

A.

Last edited by Altoid (2021-03-15 23:06:08)

Head_on_a_Stick · 2021-03-16 15:58:22

Altoid wrote:

Any idea as to what may have caused it?

I would presume that an ISO image was burned to the device at some point. The magic string laid down by that process can be very persistent.

Altoid · 2021-03-16 16:06:23

Hello:

Head_on_a_Stick wrote:

Altoid wrote:
Any idea as to what may have caused it?
... an ISO image was burned to the device at some point. The magic string laid down by that process can be very persistent.

Don't think so.

If you mean that I may have burnt an *.iso image to that HDD, I can tell you with certainty that it is not the case.
Either I mounted a that specific *.iso file with AcetoneISO, burnt it to a CD or DVD or wrote it to an SD card.

In any case, is there something that can be done so this does not happen again?

Thanks a lot for your input.

Cheers,

A.

Head_on_a_Stick · 2021-03-16 16:09:00

Altoid wrote:

is there something that can be done so this does not happen again?

Not without knowing what caused it in the first place.

MLEvD · 2021-04-11 10:53:47

oh my shock to find /etc/fstav totally blank

still embarrassed about /etc/default/pulse >_<

The officially official Devuan Forum!

#1 2021-03-14 22:08:40

[SOLVED] Strange gparted situation

#2 2021-03-15 01:15:15

Re: [SOLVED] Strange gparted situation

#3 2021-03-15 01:53:28

Re: [SOLVED] Strange gparted situation

#4 2021-03-15 03:28:54

Re: [SOLVED] Strange gparted situation

#5 2021-03-15 11:42:52

Re: [SOLVED] Strange gparted situation

#6 2021-03-15 15:16:42

Re: [SOLVED] Strange gparted situation

#7 2021-03-15 17:08:08

Re: [SOLVED] Strange gparted situation

#8 2021-03-15 18:18:19

Re: [SOLVED] Strange gparted situation

#9 2021-03-15 18:46:49

Re: [SOLVED] Strange gparted situation

#10 2021-03-15 18:52:04

Re: [SOLVED] Strange gparted situation

#11 2021-03-15 21:13:45

Re: [SOLVED] Strange gparted situation

#12 2021-03-16 15:58:22

Re: [SOLVED] Strange gparted situation

#13 2021-03-16 16:06:23

Re: [SOLVED] Strange gparted situation

#14 2021-03-16 16:09:00

Re: [SOLVED] Strange gparted situation

#15 2021-04-11 10:53:47

Re: [SOLVED] Strange gparted situation

Board footer