I have a partitioned external drive and it is not mounted and more correctly via dolphin and mounting any of those partitions (e.g. /dev/sda2) in dolphin by clicking on the device item results in an error message:
Error mounting /dev/sda2 at /run/media/andreas/UDF-Externe-Festplatte: Command-line `mount -t "udf" -o "uhelper=udisks2,nodev,nosuid,uid=0,gid=0,iocharset=utf8" "/dev/sda2" "/run/media/andreas/UDF-Externe-Festplatte"' exited with non-zero exit status 32: mount: Falscher Dateisystemtyp (wrong system filtype), ungültige Optionen, der Superblock von /dev/sda2 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler
I figured out, that it has something to do with udev and its roles, and somehow it uses wrong device settings. But I cannot figure out where or how to change that.
Where can it be fixed?
Do I have to create a fstab entry instead?
Was the external drive perhaps misconfigured that lead to wrong settings?
I am not sure you see the difference between the two mounts.
The desktop mount does this with file system type udf.
You mount without telling which file system type. The software then tries an intelligent guess and apparently has a hit with ext4 (which you show it is).
Thus the question is why the desktop mount explicitly says it is udf.
Strange is that lsblk already says that sda is udf. That would rule out partitioning at all!
Nevertheless two partitions are reported.
Is there a history connected to this device e.g. had it a udf (or iso) image before?
Edit:
You say you partitioned it, but with what and how.
Yes, I experimented with udf for interconnecting between different OS, but abandoned this approach. Then I partitioned it into the parts I did for other reasons.
The question(s) remain
how can I force the system to mount any of the subpartitons, say sda2 correctly?
or can I fix the device itself, to provide the system with proper informations
or does the system, udev perhaps, store any configurations that cause this error in mounting it by using the wrong type.
The odd thing is, that 2 weeks ago I had no problems in mounting it in dolphin. Irregularly I did system updates and suddenly (since 1 week or so) something occurred that provokes this error in not mounting it using dolphin (guess work on part of the system based on device information)
As the system reports correctly that /dev/sda2 is ext4, I would expect the mounter to guess also the right type to mount, but it does not :-/ …
I asked which what and how you did partition. Lacking an answer I have to guess.
You probably tried to partition it with GPT partitioning. I assume because the disk itself still has a label, a type that says UDF and a UUID which tries to communicate the same.
Apparently the tool you used did not erase that information. I am not sure what should be there for a partitioned disk, but it is not there.
It now looks as if the type udf is projected upon the partitions by the udev/udisk/etc software and the real types there are not detected anymore.
Do you have already data on the partitions? I mean data that you can not restore from elsewhere?
Another thing that draws my attention that this is /dev/sda. Most of the time sda is the system disk of a system and other disks are enumerated as sdb, sdc, sdd, etc. I hope you are correct here, because doing actions on the wrong disk will be fatal.
When there is nothing of importance there, my advice would be to erase the first blocks of the disk, to be sure the UDF information is gone::
dd if=/dev/zero of=/dev/sda bs=4096 count=8
will erase more then enough.
Then partition it to your needs and create file systems on the partitions to your needs.
I did back up first the data using rsync to another device
I applied dd if=/dev/zero of=/dev/sda bs=4096 count=8
partitioned it using gparted as I need it
and it mounts again as expected in dolphin
Now it is copying back all the data. The reason it is listed as /dev/sda, I’m not sure, may be it is the sequence it is plugged in or was mounted/not mounted on shutdown and reboot, I don’t know but I also realized this somewhat odd order.
AFAIK the openSUSE documentaion about how to put an installation ISO on an USB stick also advices to erase the first few blocks when one wants to use that USB again as a partitioned device. I can however not find the URL to that doc now.
IMHO it is a failure of the partitioning software. But as you fail to explain what you used (after I at least two times asked for it :(), I can not say much about that.
I assume that the whole GPT thing is still rather new and that it will take some more time before everything has settled down and to find out what best practices are in handling it in all, sometimes special, situations.
I thought UDF would be great to use on different OS, but it failed because it is limited for long filenames especially in nested folders. Then I “erased” the device somehow (but I can’t recall), and for partitioning, I’m convinced I used gparted as well. So to recall the critical steps in between I would have to time-travel backwards …
I do not know if you have the enregy and time, but IMO this is worth two bug reports.
One against gparted for leaving nonsense information about former usage of the disk contrary to the new usage of it.
(But take care here, I never used gparted, thus I do not know if you did use it as it should be used. There could e.g. be a way to make clear that it is a brand new partition table and that old info is thus to be erased. And it could be that you ignored such a feature due to ignorance of it. OTOH, my idea is that a good system management tool, specially a GUI one, should try to avoid bad actions and warn the user).
The second against the desktop mount feature about taking data about the disk itself and then not taking into account the information about the partition and then use that wrong information in creating the mount command.
You may stress then that doing a normal mount does not have that problem. It mounts the ext4 file system on the partition even if it has to find out that it is ext4 by you not providing the -t ext4 option.
OK the second proposal makes sense to me, to report a bug. To understand it right and target the bug report correctly, is it true that the dolphin click redirects this action to the udev “framework”? Which then resulted in the wrong command based on the information the parent /sda has, but not on the actual requested device /sda2 and its information …
mount -t "udf" -o "uhelper=udisks2,nodev,nosuid,uid=0,gid=0,iocharset=utf8" "/dev/sda2" "/run/media/andreas/UDF-Externe-Festplatte"
Or have I missed some relevant things to report later on?
(BTW I also see that an update of udev is provided for my system, which I have not updated yet, perhaps I will check patch changes of udev first before reporting this bug in case it may be a duplicate one)
The kernel detects the hardware connection and signals udev.
udev tries to find out what sort of device it is (in our case it is mass-storage) and tells the kernel to create the appropriate device files and their symbolic links in /dev. There is also udisk, but I am not sure which part of the tasks is done by the one or the other.
After that the desktop is informed. That is again short for a more elaborate task which has to answer questions like: is there a desktop user, is there more then one desktop user, which one is in the seat, etc.
Now it depends on the desktop. KDE will show a pop-up informing the user that a mass storage device is freshly connected and “what do you want to do with it”, offering a few possibilities, one is of course “open with file manager”. The user can ignore that, or reopen that menu from the icon later, or even the file manager may show it and the user can go from there to use it. Usage means of course “mounting first”. The desktop then tries to find out what mount parameters to use. It has to define (and thus create) a mount point, for non-Linix file systems is has to provide the user=, group=, mask= (and more)) parameters to fake ownership, permission-bits and the like as good as possible for the situation. After that, using those parameters, it asks for the mount.
Now somewhere in that string of products we think something goes wrong in that the file system type of the partitioned disk (something that has no real meaning) is used instead of that of the partition. I do not think it is up to the reporter of the bug to analyze which one of udev, udisk, desktop is wrong. When you have the knowledge, of course that would be of help. But when you don’t, i good description (including the lsblk and error listings from your first post) should be OK. And as illustration, add the fact that erasing the first part of the disk and the partitioning again removed the false information and thus the problem.
I hope that, even when a solution is not coming up in short time, a discussion that will give us more information will come out of the bug report. So please post link to the report here if you make one.
And I have not much doubt that gdisk can create a blank GPT from which to work. Even fdisk has a command to do that. But why can’t it be done with gparted?
As said in other posts, I have no gparted experience because I prefer tools like gdisk and fdisk. Those “primitive” tools give you a good understanding about what you are doing, a higher level tool like gdisk does not. They are made for those who have less understanding and thus these high level GUI tools should not make errors.
Basically, with a low level tool, you make the errors. With a high level tool, it should prevent you from making those errors.
The problem is not that there are no ways to undo an iso on a disk and redo a GPT partition (we solved that by using dd and gparted and it can be done using gdisk), but the problem is that gparted can not do it by itself and thus people need help from you and me to solve this.
I am really curious if YaST > System > Partitioner does it correct.
And then there still is the wrong interpretation of the desktop mount.
