LOG
This is a homebrew game, and it is not that easy to find on Google, so you can check it out here.
At first I tought that it crashes at [ 1.989495] Service.FS <Error> core\hle\service\fs\archive.cpp:Service::FS::File::SyncRequest:108: Reading from out of bounds offset=0x0 length=0x00000028 file_size=0x0 , but it still crashes after trying it with https://github.com/citra-emu/citra/pull/1634 .

FYI, cia to 3ds converted works fine. (it's no reason to close this issue)
Yep, it does.
The 3dsx has a header size of 0x20 and it's trying to open the RomFS.
[20:05:10] <Cruel`> subv, 0x20 is the size of the 3dsx header when it's missing the romfs entries (the old header size)
[20:05:22] <Cruel`> I think it's user error not making proper 3dsx
[20:05:41] <Cruel`> maybe using old 3dsxtool
I'm closing this as invalid.
Is this really invalid? Shouldn't we support 3dsx files with the old header format?
@yuriks The thing is that it's not really the old format, since it's trying to use the RomFS, it's a badly-generated 3dsx
Reopening since old format or not this is still our bug: If opening RomFS fails, we just log to the console and then happily use the nullptr file object to read. We should report and error so that the application knows it failed to open RomFS.
With #2561 merged, on current master the 3dsx version can boot now, but it hangs when loading

Could someone test if the CIA version still works fine or this is a regression? The CIA version still works fine
I will open a new issue later if I can't figure it out.
goes ingame now using the latest nightly with the 3dsx file
no sound fx
Most helpful comment
Reopening since old format or not this is still our bug: If opening RomFS fails, we just log to the console and then happily use the nullptr file object to read. We should report and error so that the application knows it failed to open RomFS.