AUFSとか

正式名称は、wiki によるとAnotherUnionFSというのだそうな。

Docker とかにも使われているそうで、こんなわかりやすいページがあった。

Dockerイメージの差分管理についてまとめてみた

http://tanksuzuki.com/post/docker-image-filesystem/

Docker とかは、見聞きしたことはあるんだけども、実際に使ったことはなくどんなものなのかはよく知りません。

一言でいえば、

異なるファイルシステムのファイルやディレクトリを透過的に重ねて、ひとつのファイルツリーを構成できるファイルシステム

ということのようです。BerryBoot のファイルシステムはまさにこれのようですね。このカーネルをあげてchroot すれば最新に追随できそうな感じです。この週末はそんなことにチャレンジしてみるか、気分一新、工作に手を出すかですね。

ほんと、知らないことがたくさんがたくさんありますね。奥が深いというか、知れば知るほど、深みにはまるというか。

NFS でルートファイルシステムをブートさせる記事があったので、

raspberryPiをNFSで起動する

http://takuya-1st.hatenablog.jp/entry/2014/10/14/002617

Boot Raspberry Pi over NFS

http://www.whaleblubber.ca/boot-raspberry-pi-nfs/

とりあえず、これを週末に実験してみますか。

 

ちょっとづつこのあたりは、永続的に押さえていこうかと思います。RasPi をゲットしなければこういうことも、ずっと知らないままだったのかもしれないことを考えると、価値があったと思います。

BerryBoot の kernel で起動してるってこと?

ここのところ、Fedora21 – 22 ばっかりを触っていまして、オフィシャルのRaspbian からちょっと離れていました。

で、Raspbian の image も BerryBoot 用に変換しようと思い、見てみると BerryBoot でインストールするオフィシャルの Raspbian は、2015 年の2 月に作成されています。

 

ん? これはちょっと古いやつですかね?オフィシャルの最新は、リリースノートを見ると、

http://downloads.raspberrypi.org/raspbian/release_notes.txt
2015-05-05:
  * Updated UI changes
  * Updated firmware
  * Install raspberrypi-net-mods
  * Install avahi-daemon
  * Add user pi to new i2c and spi groups
  * Modified udev rules for i2c and spi devices
2015-02-16:
  * Newer firmware with various fixes
  * New Sonic Pi release
  * Pi2 compatible RPi.GPIO
  * Updated Wolfram Mathematica
2015-01-31:
  * Support for Pi2
  * Newer firmware
  * New Sonic Pi release
  * Updated Scratch
  * New Wolfram Mathematica release
  * Updated Epiphany

::

とやっているようです。なので、変換してiscsi boot に入れてみました。いろんなバージョンを入れ替えできるので、便利です。(と、このときは思っていまいたが、、、)

img 変換の手順はメモしたのを見ながら、やればあんなに苦労したのに、あっさり。手順書っていうのは大切ですね。

 

恒例のUnixBench は以下のようでした。

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: pi: GNU/Linux
   OS: GNU/Linux -- 3.18.10v7-aufs -- #1 SMP PREEMPT Wed Apr 1 00:07:44 CEST 2015
   Machine: armv7l (unknown)
   Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
   CPU 0: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   CPU 1: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   CPU 2: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   CPU 3: ARMv7 Processor rev 5 (v7l) (0.0 bogomips)
          
   20:41:56 up 7 min,  2 users,  load average: 0.61, 0.18, 0.07; runlevel 2

------------------------------------------------------------------------
Benchmark Run: 月  7月 20 2015 20:41:56 - 21:10:14
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        3316993.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      554.5 MWIPS (10.0 s, 7 samples)
Execl Throughput                                491.3 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         49985.5 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           13538.4 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        149986.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                              207549.3 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  37800.2 lps   (10.0 s, 7 samples)
Process Creation                               1425.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1298.1 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    332.3 lpm   (60.1 s, 2 samples)
System Call Overhead                         459612.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    3316993.9    284.2
Double-Precision Whetstone                       55.0        554.5    100.8
Execl Throughput                                 43.0        491.3    114.2
File Copy 1024 bufsize 2000 maxblocks          3960.0      49985.5    126.2
File Copy 256 bufsize 500 maxblocks            1655.0      13538.4     81.8
File Copy 4096 bufsize 8000 maxblocks          5800.0     149986.5    258.6
Pipe Throughput                               12440.0     207549.3    166.8
Pipe-based Context Switching                   4000.0      37800.2     94.5
Process Creation                                126.0       1425.8    113.2
Shell Scripts (1 concurrent)                     42.4       1298.1    306.1
Shell Scripts (8 concurrent)                      6.0        332.3    553.8
System Call Overhead                          15000.0     459612.1    306.4
                                                                   ========
System Benchmarks Index Score                                         174.7

------------------------------------------------------------------------
Benchmark Run: 月  7月 20 2015 21:10:14 - 21:39:00
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       12869914.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2212.6 MWIPS (10.0 s, 7 samples)
Execl Throughput                               1143.7 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         69133.5 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           18287.4 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        220513.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                              802846.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 139871.0 lps   (10.0 s, 7 samples)
Process Creation                               3197.1 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2636.1 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    347.5 lpm   (60.3 s, 2 samples)
System Call Overhead                        1719885.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   12869914.9   1102.8
Double-Precision Whetstone                       55.0       2212.6    402.3
Execl Throughput                                 43.0       1143.7    266.0
File Copy 1024 bufsize 2000 maxblocks          3960.0      69133.5    174.6
File Copy 256 bufsize 500 maxblocks            1655.0      18287.4    110.5
File Copy 4096 bufsize 8000 maxblocks          5800.0     220513.0    380.2
Pipe Throughput                               12440.0     802846.4    645.4
Pipe-based Context Switching                   4000.0     139871.0    349.7
Process Creation                                126.0       3197.1    253.7
Shell Scripts (1 concurrent)                     42.4       2636.1    621.7
Shell Scripts (8 concurrent)                      6.0        347.5    579.2
System Call Overhead                          15000.0    1719885.8   1146.6
                                                                   ========
System Benchmarks Index Score                                         406.7

 

まぁ、OS が変わったからといって劇的に変化があるわけじゃないんですが。

CPUのFREQは、

root@pi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

1000000★

root@pi:~# uname -a

Linux pi 3.18.10v7-aufs #1 SMP PREEMPT Wed Apr 1 00:07:44 CEST 2015 armv7l GNU/Linux

root@pi:~#

ん? 今気が付いたんですが、kernel が、BerryBoot のaufs のなんですが?

root@pi:/mnt# lsmod

Module                  Size  Used by

cfg80211              366024  0

rfkill                 14438  1 cfg80211

snd_bcm2835            17419  0

snd_pcm                68808  1 snd_bcm2835

snd_seq                49800  0

snd_seq_device          4906  1 snd_seq

snd_timer              16630  2 snd_pcm,snd_seq

snd                    47011  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device

evdev                   9303  2

joydev                  8397  0

uio_pdrv_genirq         2865  0

uio                     7319  1 uio_pdrv_genirq

iscsi_tcp               8496  2

libiscsi_tcp           11808  1 iscsi_tcp

libiscsi               33727  2 libiscsi_tcp,iscsi_tcp

root@pi:/mnt#

root@pi:/mnt#

root@pi:/mnt# cat /proc/modules

cfg80211 366024 0 – Live 0x7f095000

rfkill 14438 1 cfg80211, Live 0x7f08d000

snd_bcm2835 17419 0 – Live 0x7f084000

snd_pcm 68808 1 snd_bcm2835, Live 0x7f06b000

snd_seq 49800 0 – Live 0x7f058000

snd_seq_device 4906 1 snd_seq, Live 0x7f053000

snd_timer 16630 2 snd_pcm,snd_seq, Live 0x7f04a000

snd 47011 5 snd_bcm2835,snd_pcm,snd_seq,snd_seq_device,snd_timer, Live 0x7f037000

evdev 9303 2 – Live 0x7f02b000

joydev 8397 0 – Live 0x7f025000

uio_pdrv_genirq 2865 0 – Live 0x7f021000

uio 7319 1 uio_pdrv_genirq, Live 0x7f01c000

iscsi_tcp 8496 2 – Live 0x7f015000

libiscsi_tcp 11808 1 iscsi_tcp, Live 0x7f00e000

libiscsi 33727 2 iscsi_tcp,libiscsi_tcp, Live 0x7f000000

root@pi:/mnt#

uBoot で BerryBoot のiSCSIが有効になっているカーネルからchrootするときにこれって変えれるんだろうか?

FATフォーマットのconfig.txt は次のようになっています。

disable_overscan=1

start_x=1

gpu_mem=128

# Berryboot settings, do not change

initramfs berryboot.img

[pi2]

kernel=kernel_rpi2_aufs.img

arm_freq_min=900

arm_freq=1000

core_freq_min=450

core_freq=500

sdram_freq=500

over_voltage=2

[pi1]

kernel=kernel_rpi_aufs.img

cma_lwm=16

cma_hwm=32

cma_offline_start=16

起動しているカーネルは、kernel_rpi2_aufs.img っていうことですね。そのカーネルからルートファイルシステムにchroot する感じだと思うのですが、img 作るときに、/lib/modules/ 配下を入れていないので、こうなるんですかね?

kernel_rpi2_aufs.img の中がどうなっているのか気になりますね。そもそも、raspai がブートする仕組みっていうのがどうゆう流れになっているかを把握しないとだめですね。

Fedora22 LXDE を Pi2 で動かして納得

ログイン出来ない対処を、img ファイルを作成するときにroot の初期パスワードを埋めたものを作成し、ログインできました。

LXDE は軽くていいですね。Pi で動かすのは、このくらいの動きじゃないと使えないです。一番初めに入れたFedora22 Workstation は重過ぎて無謀でした。Pi には荷が重過ぎる感じ。

panel_と_lxsession_と_タスクマネージャ

とりあえず、野良ビルドのimg じゃなく、オフィシャルのイメージから作成して動作させる手順はわかったので、これから本来のPi いじりに励みます。まぁ、これもPiいじりですがね。

 

ちょっと自分にはまだ難しい分野ですが、BerryBoot の作りを参考に、組み込み用のKernel と GUI 画面を使った GPIO いじりの工作を今後考えていこうと思います。いろいろと覚えることがたくさんあるとは思いますが、少しづつ理解に励むようがんばりますか。

今回作り方の参考になったのは、SquashFS をルートファイルとして読み出して、それをなんらかの方法で、書き込みするルートファイルシステムを作り出している部分です。こんな実装方法があるとは夢にも思いませんでした。あと、モジュールもBerryboot が持っているのを使ってchroot している感じです。

 

BerryBoot を1からビルドしてみることで、また新たな発見があるかもしれません。LinuxOS を読み込まず(ramには展開していますが)GUI 画面を表示している良い参考例です。

ExtFSのマウント指定

osx に、Pragon ExtFS を入れている場合、マウントのタイプに指定するオプションは、以下のようです。

iSCSI デバイスをReadOnly でマウントしたかった時にタイプ指定が不明だったのでめも。ext2,3,4 の判別は Pragon ExtFS がやってくれる模様。

$ sudo mkdir /Volumes/berryboot
$ sudo mount -r -t ufsd_ExtFS /dev/disk3s1 /Volumes/berryboot

                           ^^^^^^^

osxreadonly

扱えるタイプは、以下。NTFS や ext2,3,4 は Paragon のに依存しています。osx 標準じゃありませんので。

$ ll /System/Library/Filesystems/
total 8
drwxr-xr-x  6 root  wheel  204 12 20  2014 AppleShare
drwxr-xr-x  7 root  wheel  238 12 20  2014 NetFSPlugins
drwxr-xr-x  4 root  wheel  136  5 30  2014 acfs.fs
lrwxr-xr-x  1 root  wheel   49 12 20  2014 afpfs.fs -> /System/Library/Filesystems/AppleShare/afpfs.kext
drwxr-xr-x  3 root  wheel  102  6  4  2014 cd9660.fs
drwxr-xr-x  3 root  wheel  102  6  4  2014 cddafs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 exfat.fs
drwxr-xr-x  5 root  wheel  170  8 25  2013 ftp.fs
drwxr-xr-x  5 root  wheel  170 12 20  2014 hfs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 msdos.fs
drwxr-xr-x  3 root  wheel  102  8 25  2013 nfs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 ntfs.fs
drwxr-xr-x  3 root  wheel  102  6  4  2014 smbfs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 udf.fs
drwxr-xr-x  3 root  wheel  102 11 12  2014 ufsd_ExtFS.fs
drwxr-xr-x  3 root  wheel  102  9  9  2013 ufsd_NTFS.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 webdav.fs

 

ちなみに、Finderがマウント解除するときに、/Volumes/以下に作ったディレクトリも削除してくれるようです。

Fedora22-LXDEのインストール後ログイン不可

以前、Fedora22 の minimam を SDCard に入れて動かしたとき、初期に出るウィザードがうまく動作していない挙動があって、SDCard の中を Linux マシンでマウントさせ shadow や sudo設定や、passwd 、ホームディレクトリとbash設定をしてやっとログインできたのを思い出しました。

 

詳細は追っていないので、どこに問題があるのかわかりませんが、挙動から初期ウィザードがうまく動作していない様子です。今回、Fedora22-LXDEを BerryBoot の img に変換したわけですが、うまくログインできたFedora22-Workstationの中と比べてみました。

 

以下は、iSCSI Boot しているディスクのトップディレクトリ以下の構造です。

▼Fedora22-Workstation インストール後の boot disk の中身
$ tree -L 4 –filelimit 30
.
├── data
│   └── Fedora22-Workstation-berryboot.img
│       ├── etc
│       │   ├── chrony.keys
│       │   ├── cups
│       │   ├── group
│       │   ├── group-
│       │   ├── gshadow
│       │   ├── gshadow-
│       │   ├── ld.so.cache
│       │   ├── locale.conf
│       │   ├── localtime -> ../usr/share/zoneinfo/Asia/Tokyo
│       │   ├── passwd
│       │   ├── passwd-
│       │   ├── pki
│       │   ├── resolv.conf
│       │   ├── shadow
│       │   ├── shadow-
│       │   └── udev
│       ├── home
│       │   └── pi
│       ├── tmp
│       │   └── tracker-extract-files.1000
│       └── var
│           ├── cache
│           ├── lib
│           ├── log
│           ├── spool
│           └── tmp
├── images
│   └── Fedora22-Workstation-berryboot.img
::

▼Fedora22-LXDE インストール後の boot disk の中身
$ tree -L 4 –filelimit 30
.
├── data
│   └── Fedora22-LXDE-berryboot.img
│       ├── etc
│       │   ├── chrony.conf
│       │   ├── chrony.keys
│       │   ├── hostname
│       │   ├── ld.so.cache
│       │   ├── pki
│       │   ├── resolv.conf
│       │   ├── ssh
│       │   ├── systemd
│       │   └── udev
│       ├── lib
│       │   ├── python2.7
│       │   └── systemd
│       ├── root
│       ├── tmp
│       │   ├── anaconda.log
│       │   ├── ifcfg.log
│       │   ├── packaging.log
│       │   ├── program.log
│       │   ├── sensitive-info.log
│       │   └── storage.log
│       └── var
│           ├── cache
│           ├── lib
│           ├── log
│           ├── spool
│           └── tmp
├── images
│   └── Fedora22-LXDE-berryboot.img
::

data ディレクトリ配下に、img にはないものが書き出されているようです。両者を比較してみますと、初期ウィザードで作られてもおかしくないファイルがごっそりありません。

試しに、必要なものをコピーして起動してみましが、元の状態に書き換わってしまいます。BerryBoot がルートファイルシステムにchroot するときか、それ以前かわかりませんが、何かチェックサムか何か見ているのでしょう。

 

さて、どうしますかね。シングルユーザモードで起動する方法も試してみましたが、BerryBoot.img の 中のinitを追わないと、kernel に渡す引数がどうなっているのかわかりません。前回、berryboot.img の中をのぞいてみた ではちょっと見ただけで処理を追ったわけじゃないので。

 

・・・・・・・・さて、方法は以下のような対処が考えられそうです。

1)berryboot.img の処理を追って、シングルユーザモードで起動させる方法があるか見極める。なければ、作る。

2)Fedora22 のimg を作る段階で、初期ユーザなどの設定を入れてしまう。

3)Fedora22 の minimam や LXDE などの配布イメージの初期ウィザードがなぜ動作しないか追う

 

3が正等な方法ですが、気力がわいてこないので、1か、2で対応しようと思っていますが、これも気力がわいてこない。一番お手軽なのは、2なので、やる気が沸いてくるまで、他のことを考えようかと思います。

 

ふぅ。いろいろありますね~。

BerryBoot 用のBoot img 作成でドはまり

かなり、ハマッてしまったのでポイントを後ほど、メモしておくことにします。

何にはまったかっていうと、Fedora21 ~ 22 の各種ARM 用のイメージファイルを BerryBoot の img にする手順がうまくいかなくて、以下のようになって、Kernel panic でBoot しないわけで。くじけそうになった最後にやっとできました。

 

オフィシャルの手順は、以下のように紹介されています。

Adding your own custom operating systems to the menu

$ sudo kpartx -av image_you_want_to_convert.img
add map loop0p1 (252:5): 0 117187 linear /dev/loop0 1
add map loop0p2 (252:6): 0 3493888 linear /dev/loop0 118784
$ sudo mount /dev/mapper/loop0p2 /mnt
$ sudo sed -i ‘s/^\/dev\/mmcblk/#/g’ /mnt/etc/fstab
$ sudo mksquashfs /mnt converted_image_for_berryboot.img -comp lzo -e lib/modules
$ sudo umount /mnt
$ sudo kpartx -d image_you_want_to_convert.img

実際にやってみると、まぁ、いろいろあるのはいつものこと。

ポイントは、ルートファイルシステム直下のシンボリックリンクを実態にして、逆側から張りなおすこと!そうしないと、以下のようになって、RAM ディスクの kernel から、動かす img の ファイルシステムがマウントできません。後ほど、手順をつけておきます。次やるとき、絶対忘れる自信があるので。

写真

とりあえず出来たので画像メモを貼り付け。

写真_2

で、各種初期設定をすればOK

写真_1

もうね、疲れました。が、ARM の IoT デバイスのノウハウが貯まったということで、少し前進。各ディストリビューションも ARM 用のオフィシャルイメージの準備もしてきているわけですし。野良イメージは怖いので、とりあえずはオフィシャルのを使えるようになったということで、満足。

Fedora_ARM さて、QKして気力、体力も復活したので、忘れないうちにメモしておきます。

オフィシャルの ARM イメージは上のリンクから辿って、以下のようなファイルが落とせます。ファイルサイズの大きい順では、

Size byte   M,GB  FineName
———-  —-  —————————————–
1194022996  1.1G  Fedora-Workstation-armhfp-22-3-sda.raw.xz
1129186356  1.1G  Fedora-KDE-armhfp-22-3-sda.raw.xz
837507064  799M  Fedora-Xfce-armhfp-22-3-sda.raw.xz
761534064  726M  Fedora-LXDE-armhfp-22-3-sda.raw.xz
552451864  527M  Fedora-SoaS-armhfp-22-3-sda.raw.xz
427291172  407M  Fedora-Server-armhfp-22-3-sda.raw.xz
301285980  287M  Fedora-Minimal-armhfp-22-3-sda.raw.xz

となります。

今までは、GUI環境などはまったく無視してきたので、どの環境がよいのかはわかりませんが、下2つはサーバ用途ですので、今回はFedora の代表的な顔である、Workstation を入れてみたいと思います。まぁ、最後は結局全部入れることになるわけですが。

 

さて、今回の手順は、BerryBoot の インストールできる状態のイメージの作成ということですが、今回は、さらに iscsi boot する環境でそれをテストしてみたいと思います。とは、言っても通常のSDカードやUSBデバイス(USBメモリやUSB HDD)に入れるのとそれほど変わりはありません。

前提条件をまとめますと以下のようになります。

今回の環境

・BerryBoot で、ISCSI Bootの SCSI デバイスにルートを入れる

・BerryBoot 用のimg があれば、インストールはBerryBoot のインスーラーがいれてくれる

・ARM 物理環境は、RasPi2 + 2GB SDCard (実際は250Mもあれば足ります)+ LAN (WiFi でもいけるようです)

・iSCSI のターゲットは、FreeNAS (この説明は除外)で、仮想環境で提供。本体はosx

・img 作成には、ubuntu 12 を使用

作業の流れは、以下のようになります。

1) FedoraのARMオフィシャルサイトより、イメージを取得

2) 圧縮されているので展開し、img の状態に。

3) img の中にあるルートパーティションをマウント

4) ルート直下のシンボリックリンクを修正

5) fstab をコメントアウト

6) lzo 圧縮した BerryBoot 用の img を作成

7) 後処理

手順 1

ubuntu上で、作業します。

オフィシャルサイトより、イメージをゲット。全部 root でやってますので、sudo は付けていません。

# wget https://download.fedoraproject.org/pub/fedora/linux/releases/22/Workstation/armhfp/Images/Fedora-Workstation-armhfp-22-3-sda.raw.xz

CHECKSUM

# sha256sum Fedora-Workstation-armhfp-22-3-sda.raw.xz

※sum を確認

手順 2

ファイルは何なのか確認。

# file Fedora-Workstation-armhfp-22-3-sda.raw.xz
Fedora-Workstation-armhfp-22-3-sda.raw.xz: XZ compressed data

XZ 圧縮なので、xzcat で展開して、img とします。

# xzcat -v Fedora-Workstation-armhfp-22-3-sda.raw.xz > Fedora-Workstation-armhfp-22-3-sda.img

速ければ、1分ちょいくらいです。

手順 3

img ファイルの中のルートファイルシステムをマウントします。kpartx だと簡単ですが、無い環境用に、手動でやる方法も書いておきます。kpartx -a で、イメージファイルの中のパーティションをブロックデバイスに割付ます。

# kpartx -av Fedora-Workstation-armhfp-22-3-sda.img
add map loop0p1 (252:0): 0 999424 linear /dev/loop0 2048
add map loop0p2 (252:1): 0 1000482 linear /dev/loop0 1001472
add map loop0p3 (252:2): 0 9765625 linear /dev/loop0 2001954★ここをマウント

# mkdir /mnt/fedora22
# mount /dev/mapper/loop0p3 /mnt/fedora22/

確認します。

# ll /mnt/fedora22/
合計 92
dr-xr-xr-x.  18 root root  4096  5月 22 04:00 ./
drwxr-xr-x    3 root root  4096  7月 19 09:39 ../
lrwxrwxrwx.   1 root root     7  8月 16  2014 bin -> usr/bin/
drwxrwxr-x.   2 root root  4096  5月 22 03:58 boot/
drwxr-xr-x.   4 root root  4096  5月 22 04:14 dev/
drwxr-xr-x. 126 root root 12288  5月 22 04:28 etc/
drwxr-xr-x.   2 root root  4096  8月 16  2014 home/
lrwxrwxrwx.   1 root root     7  8月 16  2014 lib -> usr/lib/
drwx——.   2 root root 16384  5月 22 03:58 lost+found/
drwxr-xr-x.   2 root root  4096  8月 16  2014 media/
drwxr-xr-x.   2 root root  4096  8月 16  2014 mnt/
drwxr-xr-x.   2 root root  4096  8月 16  2014 opt/
drwxrwxr-x.   2 root root  4096  5月 22 03:58 proc/
dr-xr-x—.   2 root root  4096  5月 22 04:28 root/
drwxr-xr-x.  32 root root  4096  5月 22 04:12 run/
lrwxrwxrwx.   1 root root     8  8月 16  2014 sbin -> usr/sbin/
drwxr-xr-x.   2 root root  4096  8月 16  2014 srv/
drwxrwxr-x.   2 root root  4096  5月 22 03:58 sys/
drwxrwxrwt.   7 root root  4096  5月 22 04:28 tmp/
drwxr-xr-x.  11 root root  4096  5月 22 04:00 usr/
drwxr-xr-x.  21 root root  4096  5月 22 04:12 var/

kpartx が無い場合は、以下で。

        ▼パーティションのサイズを調べて、個別にマウントさせる

parted Fedora-Xfce-armhfp-22-3-sda.img

    GNU Parted 2.3
    /nfs/Fedora-Xfce-armhfp-22-3-sda.img を使用
    GNU Parted へようこそ! コマンド一覧を見るには 'help' と入力してください。
    (parted) u★
    単位は?  [compact]? b★
    (parted) print★
    モデル:  (file)
    ディスク /nfs/Fedora-Xfce-armhfp-22-3-sda.img: 4743757824B
    セクタサイズ (論理/物理): 512B/512B
    パーティションテーブル: msdos

    番号  開始         終了         サイズ       タイプ   ファイルシステム  フラグ
     1    1048576B     512753663B   511705088B   primary  ext3
     2    512753664B   1025000447B  512246784B   primary  linux-swap(v1)
     3    1025000448B  4525000191B  3499999744B  primary  ext4
          ^^^^^^^^^^
    (parted) q★
    root@ubu:/nfs# 

    # mount -o loop,offset=1025000448 Fedora-Xfce-armhfp-22-3-sda.img /mnt/fedora22
                           ^^^^^^^^^^※ B は取ってね
    # df -h
    Filesystem              Size  Used Avail Use% Mounted on
    ::
    /dev/loop1              3.2G  2.3G  843M  74% /mnt/fedora22

手順 4

ルート直下のシンボリックリンクを修正します。理屈はよくわかっていませんが、逆から張りなおすことでとりあえずブートしています。lib と bin と sbin を消して、実体を移動させ、逆からシンボリックを張っています。