AIX 문제 해결 - 깨진 파일셋 지우는 방법 broken fileset

안녕하세요?

뜻밖의 행운입니다.

 

lppchk -v 로 파일셋을 확인하다

생태가 broken 이 파일셋들이 가끔 있습니다.

이런것들이 remove나 clean 으로 사라지거나 지워지면 좋은데

가끔은 지워지지 않고 초기화도 안되는 것들이 있습니다.

특히 그 파일셋을 다시 강제로 설치 하려고 해도 Error 메시지만 뿌리면서

도저히 어떻게 안되는 악성으로 깨진 파일셋이

그럴때 최후의 수단으로 쓰는것이 바로 지금부터 알아볼 방법입니다.

ODM에서 지워버리기

 

예전에 ODM에 대해서 살짝 다룬적이 있었는데

lppchk, lslpp 들도 ODM에서 소프트웨어 정보를 가지고 오는 것입니다.

즉 ODM에서 지워버리면 lppchk 에서도 lslpp에서도 그 깨진 파일셋 자체가 나오지 않게 됩니다.

ODM을 수정 하는 작업이니

명령어를 치시기 전에 오타가 없는지 한번 더 살피시기 바랍니다. 

1. 현재 정보 백업

 

혹시나 잘못 되었을 때를 대비하여 당연히 백업을 해야 합니다.

/usr/lib/instl/saveodm 으로 현재 정보를 백업합니다.

full path로 입력해야 할 것입니다.

/usr/lib/instl 을 path를 보통 기본 path로 지정을 않기에

VPD 정보가 저장되었다는 메시지를 확인했다면 지금부터 본격 작업입니다. 

2. 깨진 파일셋 확인

 

 

지금부터 Java6_64.samples.demo 가 깨진 파일셋이고

지워지지도 않고 초기화도 안되고 

위에 덮어 쓰기도 되지 않는다고 가정하겠습니다.

네 아주 나쁜 Java6_64.samples.demo  입니다.

 

 

이제 이것을 ODM에서 지울것인데

/usr/lib/objrepos 에서 Java6_64.samples.demo 관련 정보를 지우고

/etc/objrepos 에서 Java6_64.samples.demo 관련 정보를 지우면 끝입니다.

3. /usr/lib/objrepos 에서 지우기

 

export ODMDIR=/usr/lib/objrepos 를 cli 창에 먼저 입력합니다.

그리고

odmget -q name=<lslpp로 확인한 파일셋 이름> lpp 을 cli 창에 입력합니다.

 

여기서 나온 결과값 중 가장 중요한것은 

lpp_id = 812 입니다.

메모해 둡니다.

그리고 지금부터 본격적으로 파일을 삭제합니다.

odmdelete -q name=Java6_64.samples.demo -o lpp

위 명령어에서 name=파일셋이름 을 주시면 됩니다. 

입력하실 때 가급적 오타내지 마시고 한번 더 확인하고 확실할 때 명령어 입력하시기 바랍니다.

그냥 그런 이름 없다 그런 파일셋 없다는 식으 에러가 뜨면 상관없으나

재수없게 지워져서 안될 비슷한 이름이 지워지면 힘든 미래가 우리 앞에 다가 옵니다.

odmdelete -q lpp_name=Java6_64.samples.demo -o product

lpp_name=파일셋이름 주시면 됩니다.

-o lpp가 아니라 -o product 임을 주의 하시기 바랍니다.

odmdelete -q lpp_id=812 -o history

odmdelete -q lpp_id=812 -o inventory

lpp_id=(odmget -q 에서 확인한 lpp id 숫자) 를 주시면 됩니다.

당부 또 당부 드립니다.

id는 3번 4번 확인하세요 파일셋 이름은 오타가 나도 비슷한 다른 파일이 있을 경우가 낮은데

id는 숫자키 옆에거 하나 잘못 입력해서 날리면...

정말 이것을 지울것이냐 yes/no 질문도 하지 않고 날아갑니다.

다시 한번 더 눈을 크게 뜨고 확인하시고 id를 입력하세요

각 명령어 입력후에 몇개의 오브젝트가 날아갔다고 결과가 나옵니다.

3. /etc/objrepos 에서 지우기

 

export ODMDIR=/etc/objrepos 를 cli 창에 먼저 입력합니다.

odmget -q name=<lslpp로 확인한 파일셋 이름> 로 다시 한번 확인 합니다.

/usr/lib/objrepos 때와 lpp_id 똑같겠지 라고 생각하고 확인 없이 그대로 지우시면

절~대~ 안됩니다.

lpp_id 확인 하셨으면 나머지는 바로 윗 단계와 동일합니다.

odmdelete -q name=<파일셋 이름> -o lpp

odmdelete -q lpp_name=<파일셋 이름> -o product

odmdelete -q lpp_id=<odmget 으로 확인했던 파일셋 lpp id> -o history

odmdelete -q lpp_id=<odmget 으로 확인했던 파일셋 lpp id> -o inventory

4. 지워졌는지 확인

 

깨진 파일셋으로 가정했던 

Java6_64.samples.demo가 이제 더이상 보이지가 않습니다.

lppchk -v 로도 당연히 보이지 않습니다.

한가지 그냥 몰라도 좋고 알면 더 좋은 것으로

에서state 부분이 있는데 여기서 숫자 7이 의미하는 것은

broken입니다.

각 숫자가 의미하는 뜻은 아래와 같습니다.

1.Available

2.Applying

3.Applied

4.Committing

5.Committed

6.Rejecting

7.Broken

8.Deinstalling

9.Deinstalled

10.Apply_hold

11.Commit_hold

음 위에서 lslpp 로 봤을 때 committed 였는데 그럼 5가 정상 아닌가요?

라는 의문을 가지신분 ^^

맞습니다. 원래 5였는데 뜻밖의 행운이 7로 수정 했던겁니다.

5. 문제 발생시 원상복구

처음 작업할 때 철두 철미한 우리는 saveodms로 백업을 했습니다.

복구 간답합니다.

restodms 로 복구 하면 됩니다.

lslpp -l 로 다시 확인해보니 Java6_64.samples.demo 가 다시 보입니다. ^^