大澤です 報告した操作をしても必ず panic するというわけではないので確信は持てませんが、 数回試してみた範囲では同じオプションで直接マウントした場合には panic していません。
件のドライブには副業で使っているファイルを含む数万のファイルがありますし、 送れるようなイメージを作るには大きいので、 小さめの USB ドライブに落ちる環境を作ってみます。 少々お待ちを。 大澤 On Sat, 25 Nov 2023 19:49:32 +0900, Hiroki Sato <h...@allbsd.org> wrote: > > [1 <text/plain; iso-2022-jp (7bit)>] > 佐藤です。 > > Hisao Osawa <osawa.hi...@tbd.t-com.ne.jp> wrote > in <20231125185015.6pilrfaun7etl6pilr5...@m-msa-com01.srv.mmtr.basmail.jp>: > > os> 大澤です > os> > os> やや原因がわかってきました。 > os> 必ずというわけではありませんが、autofsを使ってFAT32ドライブにアクセスする > os> のがいけないようです。 > os> > os> dosdisk -fstype=msdosfs,rw,-L=ja_JP.eucJP,-D=CP932,-l,-m=0777 :/dev/nvd0p5 > os> としておいて、たとえば、 > os> > cp abc.txt /mnt/dosdisk/<フォルダ名>/^D > os> といった具合に ^D や TAB で補完を行うとかなり高い確率で panic します。 > os> > os> じゃあ対象となっている FAT32 ドライブに不整合があるのかというと、 > os> Windowsを起動してCheckdiskを行ってもエラー無しで修了するので、 > os> そういうわけでもなさそうです。 > os> > os> backtrace を見ると、iconv_convchr_case で trap が呼び出されているので、 > os> このあたりですかね。 > os> だとすると autofs を使わずに、mount_msdosfs で直に mount しても > os> 同じことになりそうなので、 > os> いわゆる2バイト文字を使わないのがさしあたりの回避方法ということに > os> なってしまいますが。 > > 2 つ教えてください。 > > 1. autofs を使わず、同じオプション設定で単純にマウントしても再現するのでしょうか? > それとも、autofs を使った時だけ発生するのでしょうか? > > 2. 差し支えなければ、マウントしている FAT32 領域のディレクトリエントリの一覧か、 > ドライブのイメージファイルを送ってもらえませんか? > > msdosfs が使っている kiconv のバグを踏んでいるのだと想像しています。 > いずれにしても、2 の情報があれば修正を入れることができると思いますので、 > ファイル・ディレクトリを消して、症状が再現できる最小限のものだけを含んだ > FAT32 イメージを作って送っていただけると大変助かります。 > > -- Hiroki > [2 <application/pgp-signature (7bit)>] > No public key for DBB07DC66F1F737F created at 2023-11-25T19:49:32+0900 using > ECDSA
