| 이름: onion | [수정] 2013-03-30 13:22:41 |
흠.. 그렇지않아도 좀 미묘하기는한게....
저는
1. ufs 추출
2. floppy image랑 결합해서 iso 이미지 생성
이후 hexeditor 에서 생성된 iso image 안에서 JUSERCD 라는 부분이 안찾아지더군요.
아마도 iso로 만드는 과정에서 뭐가 바뀌나.. 싶기도한데....
역시 front porch 를 찾는부분이 저는 좀 명확하지 않은거같습니다.
흐음.. 뭐가 잘못된걸까요?
ps. 일단 openstep은 vbox에 깔아버렸네요... FDD 이미지 작업할라꼬...
아무래도 EIDE driver는 beta driver쪽이 더 안정적인거같아
FDD image를 새로 만들어볼까 하고 있습니다. 그런데 dos처럼 뭔가 새로 만들지 않아도 될려나 모르겠네요..... dos는 format /s 등으로 boot loader영역에 뭔가 심는거같은데.. 그냥 파일복사만으로는 안되지 않나요?
|
1. 추출된 ufs 파일에서 0x2000 정도로 가보면 그런 비슷한 문자열을 찾으실 수 있을겁니다. 그 앞 0x2000 만큼은 전부 0x00 으로 채워져 있어서 그 문자열이 있는 부분으로 찾지 않을 수 없더라구요.
2. 부팅 플로피는 일단 ufs 로 포맷하고 MBR 에 /usr/standalone/i386/ 인가 안에 보면 Mac OS X 처럼 필요한 부트 레코드 이미지들이 있어서 boot1 인가를 쓰시면 될겁니다.
|
1. ufs 파일에서는 찾았습니다. 문제는 iso 에서 관련된 부분을 검색하면 나오는게 없던데.... front porch 는 iso에서 찾아야 하는게 아닌가요?
2. ufs 포맷까지는 대략 예상이 되는데.. 뭐.. 해보면 알겠죠뭐..(쿨럭)
일단 iso를 뜯는 과정부터 똑바로 봐야할거같네요.
|
그러고보니...... openstep 원본 iso랑 추출한 ufs는 용량이 같아야 하지 않나요?...
|
1. 생성한 iso 이미지에 그 문자열이 있는게 정상입니다. 그리고 front porch 값도 생성된 iso 에서 찾는거지요. utf 파일 자체에서라면 언제든 0x00 이 되어버리겠죠. 보니까 iso 이미지라해도 첫 부분에 디스크라벨을 기록하는거고 오픈스텝이 거기서 front porch 값을 가지고 루트 파티션의 위치를 찾아 마운트 하는 것으로 생각이 됩니다.
2. ufs 파은 원본 iso 에서 2048 바이트를 80번 넘긴 곳에서부터 읽어 들이기 때문에 용량이 많이 작아져야지요.
|
1. 생성된 iso 이미지에 문자열이 없는데요..... 아하하하하하하하...(젠장)
물론 lbl 파일 적용하기 전입니다.
mkisofs는 linux에서 했고 테러옹 알려주신 문자열 그대로 진행했습니다.
2.
-rw-r--r-- 1 root root 541845504 3월 30 02:20 os42j.iso
-rw-r--r-- 1 root root 541681664 3월 30 02:03 OPENSTEP42JCD.ufs
-rw-r--r-- 1 root root 545005568 3월 30 02:07 test.iso
이정도의 용량차이가 있는데 맞나요?
|
용량은 제 파일들이랑 동일하네요. 그리고 참고로md5 체크섬입니다.
MD5 (test.iso) = dc13487e174ca522726ecffa72f923ab
|
# md5sum test.iso
ed7fd3e24519f11e291f41ab7e0b20ee test.iso
........................
.....................................
응? 뭔가 알고리즘이 틀린걸까요? 저랑은 md5가 틀린데요?
|
사용한 오픈스텝 이미지는 양파옹이 올리셨던 rar 에 있던 놈이구요. 다음은 md5 체크섬과 사용한 mkisofs 버전입니다.
MD5 (os42j.iso) = 2f437613d3dce6e85a13f5603da14d95
MD5 (OPENSTEP42CD.ufs) = 982061ebb30d12ee2f024bf98e1566b0
mkisofs 3.00 (--) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2010 J?rg Schilling
|
흠.. 원본 iso랑 ufs의 md5 값은 같습니다.
...............
...................
만들어진 iso의 md5가 틀린데.. lbl 먹이기전의 iso 의 md5 값을 혹시 알 수 없을까요?
|
아직 lbl 파일 기록하지 전의 파일을 가지고 있었는데.... :D
MD5 (test_nooverlay.iso) = 75e82cbc5f7262b219e6da1aa2b52413
|
흠..... 확실히 mkisofs 의 option이 뭔가 틀린건가...
lbl 안먹인상태의 md5가 틀리네요.....
(대체 뭔가 문제인건지..-.-)
mkisofs 는 mac os X 에서 하신건가요?
|
네 OSX 에서 했습니다. MacPort 로 설치했구요
|
흠.. mac port 밖에 답이 없는걸려나요.....
뾰족한 방법이 보이는게 아니네요... 흐음
|
Front porch 값은 달라질 수는 있겠지만, iso9660 데이터 이미지로 ufs 파일을 굽는다면 당연히 그 문자열이 보여야 정상이지요
|
흠.. 문자열이 안보여요........-.-;
curses-hexedit 라는놈을 linux 에서 쓰고있는데
해당되는 문자열을 찾을수가 없음다.....
mkisofs(cdrtools) 버전도 같은데 왜 차이가 있는걸까요...T.T
ps. ufs를 파일로 추가하게되는게 맞는거죠?
|
파일로 추가 하기 때문에 이미지를 마운트해서 원래 추출한 파일과 비교해보세요
|
아하! 그건 한번 해봐야겠네요.
해보고나서 말씀드리겠습니다 쿠헬헬
|
제가 굳이 필요는 없는데도 Joliet 이랑 RockRidge 옵션을 줬었는데 그거 옵션 빼신거라면 md5 값이 달라져야겠지만, 그거 때문에 내용이 달라진다는건 말이 안되죠...
|
아.. 열받네요.. 이전에 쓰던 hex editor가 검색이 똑바로 안됐었던거.........
우씨.. 일단 bless 라는 hex editor 를 쓰니깐 잘되네요...
뭐여 이거...-.-;
이제부터 다시 작업에 돌입해봐야겠음다.....흠...
ufs 추출파일의 08 시작점에 해당되는 새로 만들어진 iso 파일내에서 시작되는 offiset 이
002e2800C
정도되는거같은데... 그럼 이걸 기준으로 front porch 를 구하면 되는건가요?
|
제 경우에는 0x2E0800 이었습니다. 그래서 2048 (0x800) 으로 나눈 0x5C1 이 되었지요.
ufs 파일이 시작하는 위치로 계산해야 됩니다.
그 문자열이 나오는 곳으로 부터 0x00 만 반복되기 전 위치에서 다시 0x2000 을 위로 올라간 위치가 맞는 것 같습니다.
추출한 ufs 파일이 0x2000 만큼의 0x00 이 있고 그 다음부터 다른 코드가 나오기 시작 금방 그 검색하는 문자열이 나오거든요.
|
그런데 "ufs 추출파일의 08 시작점에 해당되는" 이란건 무슨 의미인지 제가 이해를 못했습니다;;
|
아.. UFS 파일에 보면 JUSERCD 부분이 포함된 데이터가
"08 00 00 00 0C 00 00 00 10 00 00 00 8C 00 00 00 40 FF FF FF E0 33 6E 1F CB 00 04 08 00 00 03 E6 73 00 00 00 41 00 00 20 00 00 00 08 00 00 00 00 04 00 00 00 0A 00 00 00 00 00 00 00 05 FF FF E0 00 FF FF F8 00 00 00 00 0D 00 00 00 0B 00 00 4E 20 00 00 02 00 00 00 00 02 00 00 00 00 00 00 08 00 FF FF FE 00 00 00 00 09 00 00 08 00 00 00 00 40 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8C 00 00 08 00 00 00 08 00 00 00 00 20 00 00 00 40 00 00 08 00 00 00 00 81 00 00 00 02 00 00 07 C0 00 00 10 00 00 00 16 82 00 00 06 C1 00 01 8B E3 00 00 00 0E 00 01 00 00 2F 4A 55 53 45 52 43 44 2D 72 6F 61 73 74 63 64 2E 31 38 36 38"
으로 시작되지 않슴까.. 여기서 08 을 말한거에요.
말이 좀 이상해서 죄송합니다...-.-;
|
아 그런거군요. 죄송하실꺼까지야;;;
거기서부터 위로 0x2000 바이트 올라가셔야 합니다.
|
...................허걱? 왜 올라가야하죠?
일단 번역 교정하면서 보고있는데 이제 i386 section입니다.
(m68k도 해놓으면 누군가는 쓰실거같아서 해놨...-.-)
이유는... 좀 찾아보고 모르면 질문드리겠습니다...-.-;
ps. 올라가야한다는건 iso 파일내에서 올려서 봐야한다는거죠?
|
ufs 파일 시스템 자체가 저기서 위로 0x2000 바이트가 더 있으니까요. 근데 전부 0x00 로 채워져 있어서 iso 이미지내에서 파일의 시작 위치를 찾으려면 iso9660 트리 구조 파싱해서 파일 위치 찾아내거나 아니면 헥스에디터로 찾거나 하는건데...헥스에디터로 찾으려면 0x00 0x00 0x00 .... 0x00 0x08 을 다 쳐서 검색하기는 힘들잖아요 -ㅁ- 총 0x2001 바이트라는건데...
만약 iso9660 파일 트리에서 원하는 파일의 iso 이미지 상의 위치를 출력해주는 유틸이 있다면 수고가 많이 덜텐데, 그런게 있을까요?
|
누군가가 만들면 있을지도 모르기는 하겠습니다만.......
하하하....-.-;
어차피 애초에 ufs 파일 자체가 저 point 를 기준으로 0x2000 정도의 용량이 앞쪽에 있으니 그걸 계산해서 ufs 의 pointer를 잡으라는 말씀이시군요.
뭔얘긴지 이제 조금 이해가 갔습니당....
대략 지금은..... FDD image 생성중이네요 :D
캬아.. 이거 다 맹글어놓고 이 이미지로 설치할 수 있었음 좋겠음다 :D
그걸로 설치가이드 만들면 좀 짱일거같아욤.. 그죠?
|
아항.. 어떻게 boot disk를 만드나했는데....
대략 감이 오네요.
disk의 -b 가 msdos의 format /s 같은거네요 오호...
|
실기기에 시디로만 부팅해서 설치할 수 있으면 참 편할듯 합니다. 일단 플로피 디스켓을 살까 고민하던 차에 현재는 보류 중입니다. 그런데 설치 도중 문제가 생기니 대략 낭패.. 베타에 있는 드라이버를 사용하지 않아서 문제가 생긴거라면 천만다행?일테지만, 아니라면 난관입니다...
|
흠 저는 원인은 모르겠습니다만.. 일단 버철박스에셔 iso를 mount 하지 못하고 있습니다. lbl을 dd로 쓰기전까지는 말짱한데 그 이후가 개판이네요?.................
.....................
아쓰.......-.-;
일단 r/w 로 iso를 구워서 해보려고 r/w erase 중입니다.
허우.. 웬지 안될거같은 불안함이...-.-;
|
흐음.... 일단
1. linux에서 iso를 만들때에도 conv=notrunc 는 붙어야 하는듯 합니다.
2. 뭘 잘못했는지는 모르겠습니다만.. 일단 cdrom 으로 부탕도 되고 driver도 로딩은 되는데 ufs에 있는 root를 못읽어들이는거같습니다.
"Read attempt with no valid label"
이라고 나오면서 ufs root 를 mount 못하는거같네요.
허허.. 뭔가 문제일까요 ㅋㄷㅋㄷ
|
어라..............
....................
OPENSTEP42CD.Block00.ElTorito.lbl
이 파일에서 front porch 랑 checksum만 바꿔주니 되네요...............
..............................
..................................
아무래도 m68k 의 label 작업도 필요한 요소중에 하나인거같습니다.
일단 booting 중이니까 설치가 끝나면 report 하도록 하겠습니다.
더이상 제실력으로 OPENSTEP 에서는 할 삽질이 없을거같았는데...
어허........
많네유..(쿨럭)
PS, 흐음............. 저도 BaseSystem.bom 에서 걸리네요. 뭐가 문제인걸까요? ㅋㅋㅋ
|
흠.. 영문판 iso 로는 설치에 성공했습니다.
........................
....................................
.......................................................
응? 왜 일본어판만 안되는걸까요?...-.-;
lbl 파일에 뭔가 차이가 있는걸까요?
|
흠 J 버전의 iso를 만들어서 성공했습니다.....
OPENSTEP 4.2 J 에서 추출한 disklabel 로 하니깐 에러없이 잘되네요........
(하하하하)
문제는 제가 EIDE driver 를 beta에 있는걸로 추출해서 넣었더니
.................
....................
실제 ufs image 에 있는 driver 가 EIDE 예전 driver 라서
처음 재부팅후 별도로 driver 를 넣어달라는 요청이 나옵니다...........
...............
....................
아놔...-.-;
ufs image를 뜯어야 하는걸까요.. 쓰으읍
|
대단하십니다. lbl 에 특별히 차이가 있을거란 생각은 안했었는데....
제 생각에는 iso 이미지에 드라이버들 별도로 다시 넣어두면 될거 같은데요. 어짜피 용량도 남고... 플로피 디스크 이미지랑 lbl 파일 좀 공유 부탁드립니다. 저도 테스트해보고 실기에도 설치해보게요 :) ufs 이미지도 사실 그냥 디스크에 쓰면 바로 인식이 가능할테니 수정판도 불가능하진 않습니다만.. 그럼 이미지 자체를 공유해야 하는 나름? 번거로움이 생기죠.
|
흠.. 좀 애매하기는 합니다... 일단 Linux에서 UFS를 mount 하면 readonly라서.. 오늘저녁에 이런저런 삽질을 좀 해볼 요량이기는 합니다만...
일단 원본 fdd 의 EIDE driver 그리고 cdrom에 들어있는 EIDE driver, beta 의 EIDE driver. 세가지가 다 틀려서 말이죠..
좀 해봐야할거같습니다.
ps. lbl에서 틀린건 LABEL 입니다.
|
이미 설치되어 있는 오픈스텝에다가 ufs 파일을 raw 하드디스크로 물려서 오픈스텝에서 read/write 로 마운트 가능할 것 같은데요.
lbl 에서 레이블만이 다른건 아니던데요. 미묘하게 몇 바이트들이 다르더라구요. 어느 부분에서 추출하셨나요? 그리고 전 이상하게 일어 버전 iso 에서 lbl 추출한 것으론 마운트를 하지 못하고 있습니다. OTL ... 뭐지....
|
ufs 파일을 바로 raw로 물리는건.. 잘 모르겠습니다.
일단 생각하는건 ufs 파일을 vbox내의 linux 에서 읽은다음 파일을 읽어서 dd로 민다음 해당되는 drive를 openstep 에서 mouint 해볼까... 하고 있습니다...@.@;
그게... mount가 안되는경우는 저는 label dd write 하는 부분만 잘 pass 하면 별 이상은 없는거같던데요..@.@;
|
흠..... 맘대로 안되네요.. 뭔가 방법이 따로 있는건가...-.-;
|
흠... dd로 미니깐.. 답이 없네요...아하하하...
(뭘 어떻게 해야될려나..-.-)
|
플로피 이미지 만든것 마냥 vmdk 파일 작성해서 그걸 슬레이브로 잡아서 오픈스텝 부팅하면 되지 않을까요
|
흠...... 아마도 그런레벨은 아닐거같고....
자료를 좀 찾아보니..(당연한거기는한데)
openstep의 UFS를 openstep만큼 잘 다루는 os가 있었죠..
mac os X라고......
일단 시도는 좀 해볼 요량입니다...-.-;
|
흠.............. 택도 없네요....
linux에서 read only 로만 mount가 됩니다...
어헐....
아무래도 file system header의 문제같기는한데....
지금시점에서는 방법을 못찾겄네요...T.T
|
흠.. 대략 성공은 한건데...................
driver 부분이 마음에 걸리네요....
실기기 에서 실험을 해보는것도 가능은 한데.....
일단 웬지는 모르겠는데 기본 openstep driver로는 ATAPI쪽에 문제가 있는거같아서
이이상 삽질을 강행해야하는건가.. 하는 생각이 드네요...-.-;
대략 내일쯤 내용좀 정리하고 올려놓도록 하겠습니다...-.-;
|
1. linux에서 ufs를 readonly로 Mount한다. 내용을 tar 파일로 묶는다
2. openstep에서 540M 정도의 파일을 raw로 별도 drive-vmdk 로 mount 시킨다
3. vmdk를 openstep에서 foramat한다.
4. vmdk로 인식된 drive에 tar 파일 압축을 푼다. 이후 EIDE driver를 교체
5. vmdk-raw 를 linux에서 ufs 로 mount 시도한다.
6. 정상적으로 read-only 로 mount가 된다면 이 이미지를 이용해서 다시 iso를 만들고 설치테스트를 진행한다
정도로.. 진행하려고 합니다. 지금은 4번 과정 진핸중이네요...
결론이 잘 나왔으면 좋겠네요.
이놈덕분에 2일은 족히 날아간듯...-.-;
|
ufs 자체를 오픈스텝에서 마운트하면 좀더 간편할듯 한데 vmdk 외에는 버철박스에선 답이 없는 것 같고 속도도 느려 좀 불편한데 실기 보유하고 계시지 않던가요..전 어제 오늘은 일이 있고 낼은 출근..
|
ufs 파일 자체를 vmdk를 이용해서 openstep에 넣어도 ufs로 인식을 못하고 format을 합니다.
그래서 format 하고나서 linux에서 해당되는 file을 Mount하면 인식이 되길래
기대를 가져봤는데..... front porch 도 해줬는데 안돼요.
root mount를 못함...
슬슬.. 정리하고 삽질 접어야겠네요 ㅋㅋㅋ
|
충분히 하셨다고 생각됩니다. 드라이버 파일들 iso 이미지에 ufs 파일들과 같이 넣어두면 바로 마운트되서 설치 가능할테지요? 그리고 번역은 수정할 부분들이 있지만, 어떤식으로 작업하는 것이 편할지 모르겠네요;;
|
대략.... 내용은 만들었고.. 이제 새 글 올리는일만 남았네요...
언능하고 끝내버려야겠.........(쿨럭)
아......... 정리도 끝냈습니다. 새 글로 하나 올렸고
wiki의 link도 같이 넣어놨습니다.
테러옹.. 모처럼 좋은삽질 알려주셔서 감사합니다 :D
|
|
