.sfsの自動マウントについて

[phoo]

4.1.2ってブートマネージャでチェックを外しても
xxx_412.sfsと命名された.sfsファイルを勝手にマウントしちゃいませんか？

英語版、日本語ベータ、日本語RC、を試しましたが全部そうなってしまいます。
回避策として.sfsファイルをリネームしてから、
ブートマネージャで選択してマウントしています。

[jake]

411JPでもそういうことが起こりました。
逆に、読み込むように指定しても読み込まなかったりします。ちなみに、USBブートです。

[mika-j]

こんばんは。mika-jです。

自分の場合は、devx_412.sfsをアンマウントしようとしてできませんでした。
Puppyのバージョンは 4.12-jp-betaです。

現象としては以下の二点が考えられます。

1. ブートマネージャで「選択を無視してロード」のチェックを外し、
   ロード選択リストを空にしてもbasename_xxx.sfs形式の.sfsファイルがロードされてしまう。
2. ブートマネージャで「選択を無視してロード」にチェックを入れていると
   basename_xxx.sfs形式以外の.sfsファイルがロードされない。

この場合は以下の内容で説明が付きそうな気がします。
上記以外の現象はまた別問題かもしれないですが。



● 起動時の.sfsのロードはどのような仕組みで動いてるか
.sfsのロードはinitrd.gz内のinitスクリプトで行われます。
以下は、.sfsロード処理の冒頭部分です。

コード: 全て選択

  LINE
  ----
  1076  ######################SETUP UNIONFS LAYERED FILESYSTEM########################
  1077  echo -n "Setting up the layered filesystem..." > /dev/console #STEP FIVE
  1078  #are there any other sfs files to load at bottom layers?...
  1079  NEWUNIONRECORD=""
  1080  if [ "$PUPSAVE" != "" ];then
  1081   if [ "$SMNTPT" != "" -o $PUPMODE -eq 77 ];then #v3.97
  1082    SFSSDIR="$SMNTPT"
  1083    [ $PUPMODE -eq 77 ] && SFSSDIR="$DESTDIR" #v3.97
  1084    #find all the extra sfs files...
  1085    touch /tmp/LOGONEBASES
  1086    NPATTERN="_${PUPPYVERSION}¥¥.sfs"
  1087    ls -1 $SFSSDIR/*.sfs |
  1088    while read ONEEXTRA
  1089    do
  1090     ONEBASE="`basename $ONEEXTRA`"
  1091     [ "`echo "$ONEBASE" | grep -E '^z|^pup'`" != "" ] && continue
  1092     if [ "$EXTRASFSLIST" = "" ];then #in /etc/BOOTCONFIG
  1093      [ "`echo "$ONEBASE" | grep "$NPATTERN"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS
  1094     else
  1095      [ "`echo "$EXTRASFSLIST" | grep "$ONEBASE"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS
  1096     fi 
  1097    done

(左端は行番号です)

この後、initスクリプトは/tmp/EXTRASFSSに書かれている.sfsファイルを順次mountしていく処理が続いています。
特定の.sfsファイルがロードされるかどうかは、1087〜1098行あたりの処理になると思います。

コード: 全て選択

  LINE
  ----
  1087    ls -1 $SFSSDIR/*.sfs |
  1088    while read ONEEXTRA
  1089    do
  1090     ONEBASE="`basename $ONEEXTRA`"
  1091     [ "`echo "$ONEBASE" | grep -E '^z|^pup'`" != "" ] && continue
  1092     if [ "$EXTRASFSLIST" = "" ];then #in /etc/BOOTCONFIG
  1093      [ "`echo "$ONEBASE" | grep "$NPATTERN"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS
  1094     else
  1095      [ "`echo "$EXTRASFSLIST" | grep "$ONEBASE"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS
  1096     fi

ここの処理の概要は
$SFSSDIR/配下の拡張子.sfsのファイル名をひとつずつ取り出し、条件に従ってフィルタリングし、/tmp/EXTRASFSSに書き出す、
という事になるかと思います。

注目点は1092行目です。

コード: 全て選択

  1092     if [ "$EXTRASFSLIST" = "" ];then #in /etc/BOOTCONFIG

この条件が成立した場合は1093行目が実行されます。

コード: 全て選択

  1093      [ "`echo "$ONEBASE" | grep "$NPATTERN"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS

ここの意味は.sfsファイルのうち、$NPATTERNを含んでいるものを/tmp/EXTRASFSSに保存する、ということです。
$NPATTERNは何かというと、1086行目で設定しています。"_${PUPPYVERSION}¥¥.sfs"となっているので、
たとえば、basename_412.sfsの様に、アンダースコアとバージョン番号でベース名が終わっているもののみを/tmp/EXTRASFSSに追加します。
つまり、このルートに入った場合は、basename_412.sfsの様な.sfsファイルのみをmountします。

条件が成立しない場合は、1095行目が実行されます。

コード: 全て選択

  1095      [ "`echo "$EXTRASFSLIST" | grep "$ONEBASE"`" != "" ] && echo "${ONEEXTRA}" >> /tmp/EXTRASFSS

ここの意味は、取り出した、.sfsファイル名が$EXTRASFSLISTに含まれていた場合のみ、/tmp/EXTRASFSSに追加します。
この変数$EXTRASFSLISTにはbootmanagerスクリプトの登録リストの結果が入ってます。

以上をまとめると、変数$EXTRASFSLISTが空の場合はバージョン番号でベース名が終わっているもののみをmount
そうでない場合、$EXTRASFSLISTに含まれる.sfsをmountするという事になります。


● bootmanagerからinitへの情報の引継(BOOTCONFIG)

ここで、こんどは、$EXTRASFSLISTに注目してみましょう。

bootmanager→initへの情報の受渡しには、
/etc/rc.d/BOOTCONFIGが使われているようです。

bootmanagerはBOOTCONFIGへ情報を書き出し、initはBOOTCONIFGを実行する事で情報を取り込みます。
BOOTCONFIGを覗いてみると、以下の様な感じになっています。

コード: 全て選択

EXTRASFSLIST=''
PREVUNIONRECORD='pup_save-work.2fs pup_412JPbeta.sfs'
LASTUNIONRECORD='pup_save-work.2fs pup_412JPbeta.sfs'

上のBOOTCONFIGは今、システム以外の.sfsを置いていない状態でダンプしたものです。
もし、.sfsを置いて、bootmanagerで組み込むとEXTRASFSLISTの右辺に.sfsファイル名が記入されます。
そして、リブートすると、initが、BOOTCONFIGを実行し、
その結果、変数$EXTRASFSLISTにロードしたい.sfsが設定される、というわけです。




● bootmanagerの設定とBOOTCONIFGの内容

ここまでが、前振りです。bootmanagerでの設定パターン別にBOOTCONFIGのEXTRASFSLIST=の行がどうなるか
調べてみました。

1. 「選択を無視してロード」にチェックを入れた場合
   BOOTCONIFGから、EXTRASFSLIST=の行が削除されます。
2. 「選択を無視してロード」にチェックを入れず、リストを空にした場合
   上の例の様にEXTRASFSLIST=''となり空文字列の設定になります。
3. 「選択を無視してロード」にチェックを入れず、リストに.sfsファイルを指定した場合
   EXTRASFSLIST='hogehoge.sfs'の様になります。

● bootmanagerの設定と.sfsのmount

更に、ちょっと前に戻って、initの条件分岐と照らしあわせてみると以下の様になります。

1. 「選択を無視してロード」にチェックを入れた場合
   BOOTCONIFGから、EXTRASFSLIST=の行が削除されます。
   → [ "$EXTRASFSLIST" = "" ]は真となる。(そもそも、$EXTRASFSLISTは定義されない)
   → 従って、aaaaa_412.sfsの様な.sfsファイルのみを全てmountします。
2. 「選択を無視してロード」にチェックを入れず、リストを空にした場合
   上の例の様にEXTRASFSLIST=''となり空文字列の設定になります。
   → [ "$EXTRASFSLIST" = "" ]は真となる。
   → 従って、aaaaa_412.sfsの様な.sfsファイルのみを全てmountします。
3. 「選択を無視してロード」にチェックを入れず、リストに.sfsファイルを指定した場合
   EXTRASFSLIST='hogehoge.sfs'の様になります。
   → [ "$EXTRASFSLIST" = "" ]は偽となる。
   → 従って、$EXTRASFSLISTのうちmount可能なもの全てをmountします。

これが現状の仕組みかなと思います。
問題点(1)→パターン(b)
問題点(2)→パターン(a)
と言ったところでしょうか。

●対処方法

(1)の場合

initの条件分岐を$EXTRASFSLISTが空と等しい、ではなく、$EXTRASFSLISTが未定義の場合、とします。

コード: 全て選択

  1092     if [ "$EXTRASFSLIST" = "" ];then #in /etc/BOOTCONFIG

上のコードを以下のコードに修正します。

コード: 全て選択

  1092     if ! set | grep -q "^EXTRASFSLIST=" ;then #in /etc/BOOTCONFIG

これで、(b)の場合も分岐条件が偽になり何もmountされなくなります。

(2)の場合

面倒でも「選択を無視してロード」のチェックを外し、必要な.sfsファイルをリストに追加する。

すごい尻つぼみです。すみません。
参考になれば幸いです。

[YoN]

mika-jさん、こんにちは。

コード: 全て選択

1092     if [ "$EXTRASFSLIST" = "" ];then #in /etc/BOOTCONFIG

上のコードを以下のコードに修正します。

コード: 全て選択

1092     if ! set | grep -q "^EXTRASFSLIST=" ;then #in /etc/BOOTCONFIG

としたいのですが、方法がわかりません。

initrd.gz内のinitスクリプトを書き換える手順(方法)を教えて下さい。

本家から4.1.2用のUnleashedファイル群をダウンロードしました。

その中の puppy-unleased/boot/initrd-tree0 ディレクトリを initrd-tree とリネーム(コピー)して initrd-tree ディレクトリ内にある initファイルを編集しました。

そして initrd-tree ディレクトリに戻り、 makeinitrdgz.sh を実行して新しいinitrd.gz を作りましたが、ファイルが足りません。

次に412JPのISOファイルを作ったディレクトリにある initrd.gz を「gunzip initrd.gz」として見ましたがバイナリファイルのようで編集できません。

initrd.gzの中のinitファイルを編集する方法を教えて下さい。

[mika-j]

こんにちは、YoNさん。
mika-jです。

initrd.gz内のinitスクリプトを書き換える手順(方法)を教えて下さい。

たしかにそこのところを書き忘れていました。
すみませんでした。

Unleashedからビルドするのは、すごく正当なやりかたですが、
私はもっとテキトーにやっています。

1. 適当なディレクトリにinitrd.gzをブートディレクトリからコピーしてきます。
   どこでもいいのですが、私は好みで、ハードディスクに展開することにしています。

   コード: 全て選択

   # /mnt/sdd3
   # mkdir initrd-4.1.2
   # cd initrd-4.1.2
   # cp /mnt/home/initrd.gz .
   

2. initrd.gzを解凍する。

   コード: 全て選択

   # ungzip initrd.gz
   

3. ディレクトリを掘って、そこへinitrd内のイメージを展開する。

   コード: 全て選択

   # mkdir test
   # cd test
   # cat ../initrd | cpio -id
   

4. 好みのエディタで、initスクリプトを編集します。

   コード: 全て選択

   # e3em init
   

5. initrd.gzを再度まとめあげます。

   コード: 全て選択

   # find . | cpio -o -H newc | gzip > /mnt/home/initrd-test01.gz
   

   ※ここは、一個上に上がって処理する法が好ましいかもしれません。

   コード: 全て選択

   # cd ..
   # (cd test; find . | cpio -o -H newc ) | gzip > /mnt/home/initrd-test01.gz
   

6. 最後に、お使いのgrubなりextlinux.sysなりの設定を、
   新しいinitrd-test01.gzへ向けます。

こんな感じでどうでしょう。完全我流なので、これで正確なのかわかりませんが、
とりあえず、自分ところではこれで、動いているので、御了承ください。

もっと詳しい正しいやり方がフォーラムのどこかに書いてあったと
記憶しているのですが、捜し出せませんでした。すみません。

[YoN]

mika-jさん、ありがとうございます。

私もウェブ上で検索してようやくビズアイユさんの2008年9月14日の日記でみつけました。

http://sasurahi.seesaa.net/archives/200809-1.html

しかも、「起動デバイスもutf8で」というタイトルです。
起動時にマウントされたデバイスは、iocharsetを指定できず日本語名のファイルが文字化けする問題も、多少改善するようです。(まだ試していませんが)

initrd.gzの展開方法

コード: 全て選択

zcat initrd.gz | cpio -i -d

再圧縮方法

コード: 全て選択

find . | cpio -o -H newc | gzip -9 > ../initrd.gz

これで以下のように修正したintrd.gzを入れた4.1.2のISOを作ってみたいと思います。

コード: 全て選択

1092     if [ "$EXTRASFSLIST" = "" ];then #in /etc/BOOTCONFIG

上のコードを以下のコードに修正します。

コード: 全て選択

1092     if ! set | grep -q "^EXTRASFSLIST=" ;then #in /etc/BOOTCONFIG

しかし本家フォーラムでは問題になっていないようで、不思議です。
英語に堪能な方が、この修正を本家フォーラムに投稿していただければうれしいです。

mika-jさん、ビズアイユさん、ありがとうございます。

[みのむし]

＞initrd.gzを解凍する。
＞# ungzip initrd.gz

私の環境では ungzip が入っていなかったので

# gzip -d initrd.gz

[mika-j]

すいません。タイポ(タイプミス)です。
unzipじゃなくて、gunzipでした。
もちろん、gzip -d でもいいと思います。

今、ちょっと調べたら、

コード: 全て選択

# file `which gunzip`
/bin/gunzip: symbolic link to `gzip'

gunzipはgzipへのシンボリックリンクでした。
gunzipとしてリンクされると、-dオプションと同じことになるのかなぁ。

まぁ、余談です。