Makepkg can't pass checksum validation and package fails

I’ve found the problem.
Because the aur repo is cloned at a usb disk that format as ntfs on Windows, after recent updates of Manjaro, when automounted, it show a strange path as /run/media/aaa/D:\/, I think this caused the problem. Anyway to solve this?


The aur repo: AUR (en) - vscodium-bin

  1. checksum problem

sha256sums=('65e6b053e6d8be61763801312ded64a82cf835d77a6eabe1b9d7eb9e87b2e49b') reports checksum mismatch
sha256sums=('\65e6b053e6d8be61763801312ded64a82cf835d77a6eabe1b9d7eb9e87b2e49b') pass

$ makepkg -g 
==> Retrieving sources...
  -> Found vscodium-bin.desktop
  -> Found VSCodium-linux-x64-1.51.1.tar.gz
==> Generating checksums for source files...
sha256sums=('\65e6b053e6d8be61763801312ded64a82cf835d77a6eabe1b9d7eb9e87b2e49b')
sha256sums_x86_64=('\cb2ee41c1b1042d4ebfb5e644ec59ded3fe6ce77c15abcd67078fca52abec442')
  1. package problem
==> Starting package()...
cp: cannot stat '/run/media/aaa/D:\/aur/vscodium-bin/src/!(vscodium-bin.desktop|vscodium-bin-1.51.1.tar.gz)': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

Thanks

The problem is caused by thunar-voluman mount path.

Hello @followait,

  1. Seems the packager has not updated the checksum, you can workaround this by writing ('SKIP') instead of the checksum.

  2. It is really a bad behavior to have a path like with /package\/path/ Please avoid this. Because in scripts \ before a character means normally it will be used as normal character. Therefore after / will after \ will be normal character and not a “path boundary”.

  3. thunar uses the partition name for creatung a mountpoint. Therefore, if the partition is named D:\, then you should change that and remove \. D: should work fine.

Hope that helps.

1 Like

After testing in different cases, I’m sure the path causes the problem. The path is auto generated by xfce thunar-volman.

1 Like

:arrow_double_up: That should avoid this.

1 Like
  1. A usb disk formated as ntfs on Windows
  2. In Manjaro xfce, plug the usb disk, it is automounted as /run/media/aaa/D:\/
  3. If clone aur repo at the path, makepkg fails, for detailed error: Makepkg can’t pass checksum validation and package fails
  4. If clone aur repo at ~, makepkg succeeds
  5. If mounted the usb disk manually at /mnt, makepkg succeeds

step 4 & 5 proves that the problem is caused by the path (/run/media/aaa/D:\/)

Please, write the problems occuring calmly. If you just say things willy nilly nobody is going to be able to help you and you could also end up being flagged.
Now, If the problem is a language barrier feel free to write it down on google translate and explain there, with as much detail as possible, what is the problem you are having.

Rewrited

1 Like

Okay So, Are you reporting a bug in thunar-volman ?
Okay, It could be just the procedure to automount a usb drive, It couldn’t even be a thunar-volman “bug”.
Do you have any proof that it is thunar-volman that controls the automounting ?

Whats odd is that thunar-volman has been this version since May in Arch and Manjaro-Unstable.
(and the package comes directly from Arch)
And I dont know of any other such reports …

Yeah, I was searching and the only ones I find similar to his problem are from 2014 and 2008 too

I tried to turn off “Enable Volume Management” in thunar preference, but the usb disk still shows as “D:”, and after click, it is automounted as “/run/media/aaa/D:/”.
Who makes the path “/run/media/aaa/D:/”? I have a almost fresh installed Manjaro.

1 Like

Let’s work together and we’ll reach a solution. Have you tried reformatting this usb ?
Try using another USB Drive, with another format, and another with a ntfs format
(If you don’t have other USB drives, use this one if you can format it, if you can’t don’t destroy your data just to test it)

What this looks like is that the usb is with some sort of problem since linux doesn’t use D: as a Folder name

Formatted a usb disk as ntfs on Windows, plug it Manjaro, automounted as “/run/media/aaa/161A96BDDD690FB/”, makepkg works fine.

The usb disk got problems with makepkg is a one from a laptop that installed Windows, totally Windows style:

# fdisk -l /dev/sdb
...
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
...
Device       Start       End   Sectors   Size Type
/dev/sdb1     2048   1085439   1083392   529M Windows recovery environment
/dev/sdb2  1085440   1290239    204800   100M EFI System
/dev/sdb3  1290240   1323007     32768    16M Microsoft reserved
/dev/sdb4  1323008 500117503 498794496 237.8G Microsoft basic data



So in the end it was windoze still being terrible about filesystems and not the fault of thunar-volman.
You almost had me there for a moment :wink:

1 Like

So the problem isn’t ntfs. Ok that solved a lot of trouble.

Hm, did you mean this:
"The previous usb disk that has the problems with makepkg, is from a laptop and has installed windows on it, the partition table is very windows style: "?
If so then I have to ask if the drive is encrypted, probably not since you can mount manually.

No, no bitlocker

Okay, so does this disk had any problems ? Can you see the files in there when it’s automounted ?

no other problems