Tools disk는 특별한 암호로 보호된 읽기 전용 mode로 출하된다. 푸는데는 두가지 방법이 있는데, 하나는 DOS나 Windows에서 "reclaime.exe"를 사용하여 lock을 푸는 것이고, 또 하나는 Bob Willmot의 jaztools program을 사용하는 것이다.( 5장을 참조)
# jaztool /dev/sda rw
(위에서 /dev/sda는 알맞는 SCSI device에 맞게 고친다) Password를 물어보면,
APlaceForYourStuff
느낌으로는, Jaz firmware와 관련된 듯 하다. 이런 문제를 가진 모든 사람은 drive의 Revistion을 Bob Willmot에게 알려주기 바란다. Jaz revistion은 아래와 같은 /etc/dmesg의 출력에서 다음 부분에 나와 있다.
scsi0: Target 4, channel A, now synchronous at 10.0MHz, offset 15.
Vendor: iomega Model: jaz 1GB Rev: G.60
Type: Direct-Access ANSI SCSI revision: 02
이런 현상은 일반적인 Linux 사용자에게는 일어나지 않을 듯한 어떤 특정 상황에서만 발생한다. Jaz drive의 partition이 mount되었을 때, file system이 아직 mount되어 있는 중에 driver의 spin이 멈추고, 아직도 idle일 때 block device를 읽으려고 시도하는 경우이다.
Linux가 partition을 재건(?)하기 위해 MBR을 다시 읽으려고 하지만, 어떤 이유에서 때때로 이 시도가 실패하고 device를 명백한 busy상태로 방치하는 듯 하다. Kernel의 MBR 읽기와 process device read는 불가능할 것인데, 이는 lockout 또는 busy state에 기인하는 듯 하다. 이 상태에서 Linux는(?) Jaz drive가 아직도 읽기 상태에 있는 것으로 생각하지만, 사실은 I/O는 일어나지 않는 것이다. Bob Willmot의 경우, 이런 현상은 대부분 block device가 MBR을 읽을 때 발생한다고 한다.
Jaz drive의 SCSI ID는 0 6사이의 어떤 값으로도 지정할 수 있다.
다른 SCSI hard drive와 함께 연결되어 있을 경우, 대부분의 BIOS는 최저 SCSI ID 값을 가진 disk로부터 boot하려고 할 것이다. 어떤 것은 Jaz와 같은 이동식 drive인지 detect하고 무시해버린다.
IDE hard drive와 공존할 경우에는, 거의 모든 BIOS가 첫번째 IDE HDD로부터 boot하려고 할 것이다. 어떤 BIOS는 첫번째 IDE drive를 설정 해제하는 것을 허용하고 첫번째 SCSI drive를 boot device로 지정할 것이다.(BIOS 0x80) 다른 BIOS들의 경우, 아마 모든 IDE drive를 설정 해제해야 할 것이다. 또 다른 BIOS들의 경우, 물리적으로 IDE drive를 떼어 내든지 IDE interface를 disable해야 할 것이다.
Partition 4는 Macintosh의 기본 partition이다.
Mac에서는, 첫 partition이 boot 정보를 위한 공간으로 예약되어 있고, 두 번째는 system정보, 세 번째는 resource fork, 그리고 4번째가 data fork이다.
어쨌든, PC와 대부분의 다른 system에서 4번째 partition을 쓸 수 있는 반면, Mac은 다른 partition은 전혀 사용할 수 없다. Iomega는 미리 format하는 모든 media를 출시할 때 partition 4를 사용하여 PC와 Mac모두에서 커다란 호환성 문제를 예방하고 있다.
/etc/fstab file에 한줄을 추가하기만 하면 된다. 예를 들어, 항상 DOS disk를 drive안에 넣고 boot한다면
# /dev/sda4 /jaz msdos defaults 0 0
라고 fstab 안에 기록해 준다.(역자 주 : Iomega에서는 4번 partition을 사용하므로 /dev/sda4라고 하는 것으로 생각됨) 각자의 상황에 따라 다르겠지만, 초기화 script는 fstab에 기록된 각 partition에 대해 fsck를 실행시키려 할 것이다. 만일, disk를 boot할 때 drive 안에 넣는 것을 잊는거나 잘못된 disk 를 넣어둔다면(역자 주: 다른 type으로 format된 disk 등) 문제를 일으킬 수 있다.
이 문제를 피하기 위해, /etc/rc.d/rc.local에 Jaz를 mount하기 위한 별도의 mount 명령을 추가할 수도 있다. 이렇게 함으로써 drive에 catridge가 없는 상황에서 표준 "mount -a" 명령에 의해 발생될 문제를 피할 수 있다.
Kernel이 partition table을 읽으려 할 때 (결국) operation time out이 발생할 것이다.
Disk를 바꿀 때는 fsck를 사용하여 새 disk의 partition 구조를 확인하는 것이 좋다.
어떤 SCSI host adapter의 BIOS는 system boot 중에 disk의 partition table을 읽으려고 할 것이다. 이것을 방지할 수 없다면, (당신의 의지와는 상관 없이) 아마 반드시 drive에 disk를 넣은 채로 boot하여야 할 것이다.
(BIOS에서 허용한다고 가정했을 경우.)
Jaz drive/cartridge는 훌륭한 응급 복구용 disk가 될 수 있다. 또한 새로운 Linux system을 사용할 수 있다거나 Jaz를 갖춘 다른 사람의 machine에서 Linux를 쓸 수 있다면 재미있을 것이다.
Jaz drive가 system의 유일한 drive라면, 원하는 대로 설치 procedure를 진행할 수 있을 것이다. 그러나, 현재 작동하는 system으로부터 self-bootable한 system을 Jaz cartridge에 "건설"하는 것도 가능하다.
첫번째 system definition 전에 아래의 내용을 /jaz/etc/lilo.conf file에 추가시킨다. ("1"을 root partition number로 바꾸고 "sda"를 적당한 Jaz device 이름으로 바꾼다)
drive = /dev/sda1 bios = 0x80
Jaz MBR을 설치할 준비가 되었다면, /jaz tree가 마치 /에 있는 것처럼 작동시키기 위해 lilo를 -r option으로 실행시킨다. 이 명령은 다음과 같다.
# lilo -r /jaz
보통, lilo는 boot시 boot device의 BIOS device number를 찾기 위한 탐색을 실시한다. 추가된 2줄이 이 작업을 한다.
lilo와 kernel로부터 여러 error message가 나타날 것이다. lilo는 이 경우가 아니면 문제되지 않을 문제점에 대해 경고할 것이다. Kernel은 lilo가 무언가 알아내기(역자 주:discover) 위해 device를 찾는 probe에 의해 촉발되는 /dev/hdc와 관련된 문제를 제시할 것이다. 이런 message는 무시해도 된다.
"쓰기"가 발생하는지 Jaz drive light를 주시할 것. 이 때, Jaz drive는 반드시 bootable해야 한다.