---

(sorry about my wierd X-post, but I'm deadmeat (fail the semester at least)
if I don't resolve this problem)
(FUT: Linux.redhat )

System setup:
Red Hat 7.2
MySQL 4
Apache /w PHP
Qmail / Courrier - mail


---- ENG ----
It had to happen in the middle of a project (wich we have to turn in, in
less then a week)

Our Linux server won't boot up, the last 3 liniens we see is :
Freeing unused kernel memory
INIT: version 2.70 booting
INIT /etc/inittab[61]: duplicate ID field "SV"

The problem 'might' be the result of an unautorized shutdown (power failur)
or after a MySQL install

We've tried seaching for a solution on google and alot of pages explained
that duplicate ID is bad (mmkay) but non offered a solution to the problem.
We hopes and prays that someone might be able to resolve the problem, sins a
reinstall would set us back about a week.

Please help, any help.


---- DK ----

Det skulle jo lige ske midt i et projekt (som skal afleveres om mindre end
en uge).

Vores Linux server kan ikke boote op.
De 3 sidste linier den når er:
Freeing unused kernel memory
INIT: version 2.70 booting
INIT /etc/inittab[61]: duplicate ID field "SV"

Problemet 'kan' måske være kommet efter en uautoriceret nedlukning
(strømsvigt) eller efter MySQL install

Vi har læst mig til på google at det er ret skidt, men hvordan løser man
det??
Vi håber virkelig der er nogen der kan hjælpe, for afleveringen truer og det
vil sætte os over en uge tilbage hvis vi skal til at starte forfra.

Alt hjælp er brugbart. Hvordan får vi den op i en minimumskonsol (savner sq
næste fejlsikker tilstand)
Links, refs og andet.

---

On Fri, 30 May 2003 14:04:42 +0200, Mikael Jensen wrote:

> Vores Linux server kan ikke boote op. De 3 sidste linier den når
> er: Freeing unused kernel memory INIT: version 2.70 booting INIT
> /etc/inittab[61]: duplicate ID field "SV"

Boot med en cd (Knoppix, f.ex., eller en hvilken som helst cd der
giver adgang til en kommandolinie - f.ex. Debians første cd og sikkert
de fleste andre installerings-cd'er), mount disken, og ret i
/etc/inittab?

> Vi har læst mig til på google at det er ret skidt, men hvordan løser
> man det?? Vi håber virkelig der er nogen der kan hjælpe, for
> afleveringen truer og det vil sætte os over en uge tilbage hvis vi
> skal til at starte forfra.

I har vel jeres backup?


Mvh.

Adam

P.S. Jeg har fjernet de andre grupper fra krydspostningen, der er
ingen grund til at skyde med spredhagl.

--
"Från och med nu, så är 'så snart Adam Sjøgren
som möjligt' 53 timmar!" asjo@koldfront.dk

---

If I boot on the redhat CD we can get a recovery console, but sins Linux
isn't my strong side, I have no ideer what to do with it.

And i seem to have a problem with resiving from linux.redhat so new FUT is
alt.linux.redhat

> System setup:
> Red Hat 7.2
> MySQL 4
> Apache /w PHP
> Qmail / Courrier - mail
>
> It had to happen in the middle of a project (wich we have to turn in, in
> less then a week)
>
> Our Linux server won't boot up, the last 3 liniens we see is :
> Freeing unused kernel memory
> INIT: version 2.70 booting
> INIT /etc/inittab[61]: duplicate ID field "SV"
>
> The problem 'might' be the result of an unautorized shutdown (power
failur)
> or after a MySQL install
>
> We've tried seaching for a solution on google and alot of pages explained
> that duplicate ID is bad (mmkay) but non offered a solution to the
problem.
> We hopes and prays that someone might be able to resolve the problem, sins
a
> reinstall would set us back about a week.
>
> Please help, any help.

---

"Mikael Jensen" <Mikael@tecmail.dyndns.dk> wrote in message news:<3ed7573e$0$32444$edfadb0f@dread16.news.tele.dk>...
> If I boot on the redhat CD we can get a recovery console, but sins Linux
> isn't my strong side, I have no ideer what to do with it.
>
> And i seem to have a problem with resiving from linux.redhat so new FUT is
> alt.linux.redhat
>
> > System setup:
> > Red Hat 7.2
> > MySQL 4
> > Apache /w PHP
> > Qmail / Courrier - mail
> >
> > It had to happen in the middle of a project (wich we have to turn in, in
> > less then a week)
> >
> > Our Linux server won't boot up, the last 3 liniens we see is :
> > Freeing unused kernel memory
> > INIT: version 2.70 booting
> > INIT /etc/inittab[61]: duplicate ID field "SV"
> >
> > The problem 'might' be the result of an unautorized shutdown (power
> failur)
> > or after a MySQL install
> >
> > We've tried seaching for a solution on google and alot of pages explained
> > that duplicate ID is bad (mmkay) but non offered a solution to the
> problem.
> > We hopes and prays that someone might be able to resolve the problem, sins
> a
> > reinstall would set us back about a week.
> >
> > Please help, any help.


I would say that you should check /etc/inittab and look for "SV" and
replace it with something unique. It could by an install that did not
check current inittab entries before entering new data ino the
inittab.

---

Den Fri, 30 May 2003 14:04:42 +0200 skrev Mikael Jensen:
>
>Vores Linux server kan ikke boote op.
>De 3 sidste linier den når er:
>Freeing unused kernel memory
>INIT: version 2.70 booting
>INIT /etc/inittab[61]: duplicate ID field "SV"

Der er to linjer med id "SV" i /etc/inittab. Id'et er det første felt
på hver linie, fx:

W0:123:respawn:/sbin/agetty -L 9600 ttyW0 wy50

Her er "W0" id'et.

>Alt hjælp er brugbart. Hvordan får vi den op i en minimumskonsol (savner sq
>næste fejlsikker tilstand)
>Links, refs og andet.

LILO Boot: linux init=/bin/sh
$ mount -n / -o remout,rw
$ vi /etc/inittab
/W0
n

Hvis de to linier er ens, trykker du herefter: ddZZ
er linierne forskellige, trykker du rQZZ
(dd = slet linie, r = replace, ZZ = gem og afslut - Q er bare et
tilfældig valgt bogstav, i håb om at QV ikke er i brug).

Derefter skriver du:

sync
sync

når maskienen holder op med at arbejde på diskene, slukker du, og tænder
igen.

Mvh
Kent
--
Journalist: En der har forstand på at skrive artikler, men typisk
ikke på det artiklerne handler om.

---

Kent Friis wrote:

>> INIT /etc/inittab[61]: duplicate ID field "SV"
>
> Der er to linjer med id "SV" i /etc/inittab. Id'et er det første felt
> på hver linie, fx:
>
> W0:123:respawn:/sbin/agetty -L 9600 ttyW0 wy50
>
> Her er "W0" id'et.
>
>> Alt hjælp er brugbart. Hvordan får vi den op i en minimumskonsol (savner sq
>> næste fejlsikker tilstand)
>> Links, refs og andet.
>
> LILO Boot: linux init=/bin/sh
> $ mount -n / -o remout,rw
^^^^^^

Og det er selfølgeligt 'remount', hvis han ikke skal have problemer ...

> $ vi /etc/inittab
> /W0

Eller '/SV', hvis man skal finde den *han* skal bruge

> n
>
> Hvis de to linier er ens, trykker du herefter: ddZZ
> er linierne forskellige, trykker du rQZZ
> (dd = slet linie, r = replace, ZZ = gem og afslut - Q er bare et
> tilfældig valgt bogstav, i håb om at QV ikke er i brug).
>
> Derefter skriver du:
>
> sync
> sync
>
> når maskienen holder op med at arbejde på diskene, slukker du, og tænder
> igen.

Plejer man ikke for god ordens skyld at lave en 'mount -o remount,ro /',
efterfulgt af en 'reboot'? Selv i tilfælde af slemme crashes anbefales
det at remounte read-only før man genstarter. Dette klares så med Magic
SysRq. Det er forresten en driver der altid burde være installeret på
maskiner som man "leger" med ...

--
PeKaJe

It is when I struggle to be brief that I become obscure.
-- Quintus Horatius Flaccus (Horace)

---

Den 30 May 2003 16:51:27 GMT skrev Peter Jensen:
>Kent Friis wrote:
>
>>> INIT /etc/inittab[61]: duplicate ID field "SV"
>>
>> Der er to linjer med id "SV" i /etc/inittab. Id'et er det første felt
>> på hver linie, fx:
>>
>> W0:123:respawn:/sbin/agetty -L 9600 ttyW0 wy50
>>
>> Her er "W0" id'et.
>>
>>> Alt hjælp er brugbart. Hvordan får vi den op i en minimumskonsol (savner sq
>>> næste fejlsikker tilstand)
>>> Links, refs og andet.
>>
>> LILO Boot: linux init=/bin/sh
>> $ mount -n / -o remout,rw
> ^^^^^^
>
>Og det er selfølgeligt 'remount', hvis han ikke skal have problemer ...

Keyboard error, press F1 to continue

>> $ vi /etc/inittab
>> /W0
>
>Eller '/SV', hvis man skal finde den *han* skal bruge

Doh...

>Plejer man ikke for god ordens skyld at lave en 'mount -o remount,ro /',
>efterfulgt af en 'reboot'?

Jeg har før haft problemer med at mounte tilbage til readonly, sync
sikrer at alt er skrevet til disken, men sætter den ikke til clean,
så næste boot kører en forced fsck, der ikke må finde nogen fejl.

Hvis den gør det alligevel, overså man enten "og vent til diskene holder
op med at arbejde", eller filsystemet var allerede smadret.

Mvh
Kent
--
F0 0F C7 C8 - Intel Pentium bug

---

Kent Friis wrote:

>> Plejer man ikke for god ordens skyld at lave en 'mount -o remount,ro
>> /', efterfulgt af en 'reboot'?
>
> Jeg har før haft problemer med at mounte tilbage til readonly,

Nu du lige nævner det, så har jeg da egentligt også haft det problem. Og
så alligevel. Hvis alt der ikke er relevant bliver unmounted, så kan man
vist godt remounte read only. En efterfølgende 'mount' vil dog stadig
vise den som mounted rw, men fsck brokker sig ikke. Jeg vil tro at mount
ikke kan skrive til /etc/mtab efter en remount. Jeg er dog ikke sikker.

> sync sikrer at alt er skrevet til disken, men sætter den ikke til
> clean, så næste boot kører en forced fsck, der ikke må finde nogen
> fejl.

Tjo ... Det er vel en måde at gøre det på. Man burde i hvert fald ikke
miste nogle data.

> Hvis den gør det alligevel, overså man enten "og vent til diskene
> holder op med at arbejde", eller filsystemet var allerede smadret.

Hele denne situation er grunden til at jeg anbefaler at folk installerer
Magic SysRq på maskiner der skal "pilles" ved. For at synce:
<ALT>+<SysRq>+s. Den skriver når den er færdig, hvorefter du kan trykke
<ALT>+<SysRq>+u for at unmounte og <ALT>+<SysRq>+b for at reboote. Den
er også meget rar at have i tilfælde af X crashes. Her kan man trykke
<ALT>+<SysRq>+r for at få kontrollen over keyboardet tilbage fra den
låste X.

--
PeKaJe

"How to make a million dollars: First, get a million dollars."
-- Steve Martin

---

Den 31 May 2003 11:16:05 GMT skrev Peter Jensen:
>Kent Friis wrote:
>
>>> Plejer man ikke for god ordens skyld at lave en 'mount -o remount,ro
>>> /', efterfulgt af en 'reboot'?
>>
>> Jeg har før haft problemer med at mounte tilbage til readonly,
>
>Nu du lige nævner det, så har jeg da egentligt også haft det problem. Og
>så alligevel. Hvis alt der ikke er relevant bliver unmounted, så kan man
>vist godt remounte read only.

Jo, men det forekommer mig at bash gerne vil holde fast i en eller
anden dum device-fil, og det generer systemet.

>En efterfølgende 'mount' vil dog stadig
>vise den som mounted rw, men fsck brokker sig ikke. Jeg vil tro at mount
>ikke kan skrive til /etc/mtab efter en remount. Jeg er dog ikke sikker.

Det kan den heller ikke.

>> sync sikrer at alt er skrevet til disken, men sætter den ikke til
>> clean, så næste boot kører en forced fsck, der ikke må finde nogen
>> fejl.
>
>Tjo ... Det er vel en måde at gøre det på. Man burde i hvert fald ikke
>miste nogle data.
>
>> Hvis den gør det alligevel, overså man enten "og vent til diskene
>> holder op med at arbejde", eller filsystemet var allerede smadret.
>
>Hele denne situation er grunden til at jeg anbefaler at folk installerer
>Magic SysRq på maskiner der skal "pilles" ved. For at synce:
><ALT>+<SysRq>+s. Den skriver når den er færdig, hvorefter du kan trykke
><ALT>+<SysRq>+u for at unmounte og <ALT>+<SysRq>+b for at reboote. Den
>er også meget rar at have i tilfælde af X crashes. Her kan man trykke
><ALT>+<SysRq>+r for at få kontrollen over keyboardet tilbage fra den
>låste X.

Eller man rykker lige over til ttyW0, og kill'er X derfra

Mvh
Kent
--
IE is the only thing capable of making Netscape look good
- D. Spider in comp.os.linux.advocacy

---

Kent Friis wrote:

>>> Jeg har før haft problemer med at mounte tilbage til readonly,
>>
>> Nu du lige nævner det, så har jeg da egentligt også haft det problem.
>> Og så alligevel. Hvis alt der ikke er relevant bliver unmounted, så
>> kan man vist godt remounte read only.
>
> Jo, men det forekommer mig at bash gerne vil holde fast i en eller
> anden dum device-fil, og det generer systemet.

Tja ... Jeg har ingen device filer i /. De findes alle i devfs, som jeg
dog ikke kan unmounte. Det lader dog ikke til at genere fsck, så det er
nok for mig.

>> En efterfølgende 'mount' vil dog stadig vise den som mounted rw, men
>> fsck brokker sig ikke. Jeg vil tro at mount ikke kan skrive til
>> /etc/mtab efter en remount. Jeg er dog ikke sikker.
>
> Det kan den heller ikke.

Jeg er lidt i tvivl om mount skriver før eller efter selve operationen.
Når man mounter i rw bruger man jo netop -n parameteren for ikke at
skrive til /etc/mtab, som jo ville være skrivebeskyttet. Hvis det er
tilfældet, så må der jo skrives før selve remount operationen. Det
skulle så ikke være et problem når man går den anden vej.

>> Hele denne situation er grunden til at jeg anbefaler at folk
>> installerer Magic SysRq på maskiner der skal "pilles" ved. For at
>> synce: <ALT>+<SysRq>+s. Den skriver når den er færdig, hvorefter du
>> kan trykke <ALT>+<SysRq>+u for at unmounte og <ALT>+<SysRq>+b for at
>> reboote. Den er også meget rar at have i tilfælde af X crashes. Her
>> kan man trykke <ALT>+<SysRq>+r for at få kontrollen over keyboardet
>> tilbage fra den låste X.
>
> Eller man rykker lige over til ttyW0, og kill'er X derfra

ttyW0 er en remote, ikke? Jeg har faktisk også en gammel bærebar
computer stående, med en "Serial Terminal Linux" på diskette. Den bruges
stort set kun til nødstilfælde.

--
PeKaJe

Stay away from hurricanes for a while.

---

Den 31 May 2003 12:26:38 GMT skrev Peter Jensen:
>Kent Friis wrote:
>
>>>> Jeg har før haft problemer med at mounte tilbage til readonly,
>>>
>>> Nu du lige nævner det, så har jeg da egentligt også haft det problem.
>>> Og så alligevel. Hvis alt der ikke er relevant bliver unmounted, så
>>> kan man vist godt remounte read only.
>>
>> Jo, men det forekommer mig at bash gerne vil holde fast i en eller
>> anden dum device-fil, og det generer systemet.
>
>Tja ... Jeg har ingen device filer i /. De findes alle i devfs, som jeg
>dog ikke kan unmounte. Det lader dog ikke til at genere fsck, så det er
>nok for mig.

Selvfølgelig giver det ikke fsck, devfs filsystemet findes ikke på
disken.

>>> En efterfølgende 'mount' vil dog stadig vise den som mounted rw, men
>>> fsck brokker sig ikke. Jeg vil tro at mount ikke kan skrive til
>>> /etc/mtab efter en remount. Jeg er dog ikke sikker.
>>
>> Det kan den heller ikke.
>
>Jeg er lidt i tvivl om mount skriver før eller efter selve operationen.
>Når man mounter i rw bruger man jo netop -n parameteren for ikke at
>skrive til /etc/mtab, som jo ville være skrivebeskyttet. Hvis det er
>tilfældet, så må der jo skrives før selve remount operationen. Det
>skulle så ikke være et problem når man går den anden vej.

Før remount er gennemført, ved mount ikke om det er gået godt. Så den
må nødvendigvis skrive til mtab bagefter.

>>> Hele denne situation er grunden til at jeg anbefaler at folk
>>> installerer Magic SysRq på maskiner der skal "pilles" ved. For at
>>> synce: <ALT>+<SysRq>+s. Den skriver når den er færdig, hvorefter du
>>> kan trykke <ALT>+<SysRq>+u for at unmounte og <ALT>+<SysRq>+b for at
>>> reboote. Den er også meget rar at have i tilfælde af X crashes. Her
>>> kan man trykke <ALT>+<SysRq>+r for at få kontrollen over keyboardet
>>> tilbage fra den låste X.
>>
>> Eller man rykker lige over til ttyW0, og kill'er X derfra
>
>ttyW0 er en remote, ikke?

Det er en dum terminal på en serielport.

Mvh
Kent
--
.~. .~.
/V\ From Palm Pilot to S/390 /V\
// \\ Truly scalable operating system // \\
/( )\ Linux /( )\
^^-^^ ^^-^^

---

Kent Friis wrote:

>> Tja ... Jeg har ingen device filer i /. De findes alle i devfs, som
>> jeg dog ikke kan unmounte. Det lader dog ikke til at genere fsck, så
>> det er nok for mig.
>
> Selvfølgelig giver det ikke fsck, devfs filsystemet findes ikke på
> disken.

Jeg mente egentligt at jeg godt kunne køre fsck bagefter. Normalt ville
den ellers brokke sig slemt over at filsystemet er mountet. Mount
brokker sig også over at / er i brug, indtil alt er stoppet og
unmountet, på nær devfs.

>> Jeg er lidt i tvivl om mount skriver før eller efter selve
>> operationen. Når man mounter i rw bruger man jo netop -n parameteren
>> for ikke at skrive til /etc/mtab, som jo ville være skrivebeskyttet.
>> Hvis det er tilfældet, så må der jo skrives før selve remount
>> operationen. Det skulle så ikke være et problem når man går den anden
>> vej.
>
> Før remount er gennemført, ved mount ikke om det er gået godt. Så den
> må nødvendigvis skrive til mtab bagefter.

Det giver selvfølgeligt mening. Så grunden til at bruge -n ved mount fra
ro til rw må vel være for det tilfælde hvor det ikke går godt?

>>> Eller man rykker lige over til ttyW0, og kill'er X derfra
>>
>> ttyW0 er en remote, ikke?
>
> Det er en dum terminal på en serielport.

OK, det svarer lidt til min ttyS0 så. Det er bare træls når computeren
er så låst at den ikke kan nås med en terminal. Dér bliver man glad for
SysRq, selvom det er temmeligt sjældent at den er nødvendig.

--
PeKaJe

BOFH Excuse #64:
CPU needs recalibration

---

Den 31 May 2003 14:10:03 GMT skrev Peter Jensen:
>Kent Friis wrote:
>
>>> Jeg er lidt i tvivl om mount skriver før eller efter selve
>>> operationen. Når man mounter i rw bruger man jo netop -n parameteren
>>> for ikke at skrive til /etc/mtab, som jo ville være skrivebeskyttet.
>>> Hvis det er tilfældet, så må der jo skrives før selve remount
>>> operationen. Det skulle så ikke være et problem når man går den anden
>>> vej.
>>
>> Før remount er gennemført, ved mount ikke om det er gået godt. Så den
>> må nødvendigvis skrive til mtab bagefter.
>
>Det giver selvfølgeligt mening. Så grunden til at bruge -n ved mount fra
>ro til rw må vel være for det tilfælde hvor det ikke går godt?

Eller fordi man ikke lige kan huske hvornår det er nødvendigt.

>>>> Eller man rykker lige over til ttyW0, og kill'er X derfra
>>>
>>> ttyW0 er en remote, ikke?
>>
>> Det er en dum terminal på en serielport.
>
>OK, det svarer lidt til min ttyS0 så. Det er bare træls når computeren
>er så låst at den ikke kan nås med en terminal. Dér bliver man glad for
>SysRq, selvom det er temmeligt sjældent at den er nødvendig.

Det har jeg aldrig været ude for.

Mvh
Kent
--
.~. .~.
/V\ From Palm Pilot to S/390 /V\
// \\ Truly scalable operating system // \\
/( )\ Linux /( )\
^^-^^ ^^-^^