Ubuntu server gecrasht tijdens dist-upgrade

[iMars]

Mijn vraag
Een paar dagen geleden probeerde ik mijn server/nas te upgraden van Ubuntu 14.04 LTS naar 16.04 LTS. Helaas is dat niet goed gegaan en komt mijn server in de "welcome to emergency mode after logging in" loop.

Relevante software en hardware die ik gebruik

• SuperMicro mainboard
• Disk 1: 160G SSD Main OS disk
• Disk 2: 32GB SSD Oude OS disk (niet gebruikt)
• Disk 3: 2TB in mdadm soft raid5
• Disk 4: 2TB in mdadm soft raid5
• Disk 5: 2TB in mdadm soft raid5
• Disk 6: 2TB in mdadm soft raid5

Wat ik al gevonden of geprobeerd heb

• Eerst dacht ik aan fsck, dus server booten met live-cd en fsck uitgevoerd op de OS disk, probleem niet opgelost.
• Daarna wilde ik kijken of ik nog bij mijn data kan komen. Opgestart met live-cd, mdadm geïnstalleerd en array toegevoegd: mdadm --assemble --scan. En dat werkte, data kan ik bij komen.
• Ik heb Ubuntu server opnieuw geïnstalleerd op de 32GB disk. Alles gaat goed, deze disk als bootable ingesteld. Server start, grub wordt goed getoond, maar daarna blijft het beeld zwart (op de console)
• ...

Nou wil ik nog niet gelijk mijn 160GB disk formatteren en opnieuw installeren omdat er nog wat data op staat. Maar volgens mij moet ik ook gewoon van mijn 32GB disk kunnen opstarten. Maar wat ik ook probeer, ik krijg het niet aan de praat...

Mijn Linux kennis is vrij goed, maar heb te weinig ervaring hiermee en wil geen spontane acties doen waar ik later spijt van krijg

Kan ik Ubuntu server installeren op de 160GB disk over de corrupte installatie? Dus zonder te formatteren zodat ik de data nog heb?

Mijn last resort is data van 160GB kopiëren naar of 32GB, of m'n raid5 en dan een clean install...

Ik hoor graag wat advies van jullie...

[Hero of Time]

Het lijkt mij ook wel handig te vermelden op welk punt de upgrade is gefaald. Wat als je een chroot uitvoert vanaf een Live omgeving naar de 160 GB installatie en van daaruit op updates controleert? Welke repo's staan er bijvoorbeeld ingesteld? Wat zie je zoal als je opstart zonder de 'quiet splash' kernel parameters? Wat staat er zoal in de logs van de mislukte upgrade?

[BCC]

Gezien de mdadm vermoed ik dat de disks niet goed meegenomen zijn? Wat zegt df -h en mdadm?

[iMars]

Hero of Time schreef op zondag 05 juni 2016 @ 12:24:
Het lijkt mij ook wel handig te vermelden op welk punt de upgrade is gefaald. Wat als je een chroot uitvoert vanaf een Live omgeving naar de 160 GB installatie en van daaruit op updates controleert? Welke repo's staan er bijvoorbeeld ingesteld? Wat zie je zoal als je opstart zonder de 'quiet splash' kernel parameters? Wat staat er zoal in de logs van de mislukte upgrade?

Hij was bezig met de cleaning up (ergens rond de 95%) en dat duurde letterlijk uren (wat in mijn ogen niet zou mogen). Daarna zag ik dat ie mislukt was (error code weet ik niet meer). De dist-upgrade nog een keer uitgevoerd en kreeg de melding dat er niks te upgraden was. Na reboot blijft ie op de emergency mode komen.
Even kijken hoe ik de logs eraf kan krijgen, werk nu via de console.

BCC schreef op zondag 05 juni 2016 @ 12:25:
Gezien de mdadm vermoed ik dat de disks niet goed meegenomen zijn? Wat zegt df -h en mdadm?

Met of zonder mdadm zou de server toch gewoon moeten opstarten?

[Hero of Time]

iMars schreef op zondag 05 juni 2016 @ 12:40:
[...]

Hij was bezig met de cleaning up (ergens rond de 95%) en dat duurde letterlijk uren (wat in mijn ogen niet zou mogen). Daarna zag ik dat ie mislukt was (error code weet ik niet meer). De dist-upgrade nog een keer uitgevoerd en kreeg de melding dat er niks te upgraden was. Na reboot blijft ie op de emergency mode komen.
Even kijken hoe ik de logs eraf kan krijgen, werk nu via de console.

Lijkt mij een goed begin om te achterhalen wat er is gebeurt.

[...]

Met of zonder mdadm zou de server toch gewoon moeten opstarten?

Nee, vziw gaat Linux altijd over de zeik als er een schijf niet gemount kan worden. Nu met SystemD is het helemaal een drama. Dus als je mdadm array niet op komt, doet systemd en wordt je naar een rescue console getrapt.

Overigens is wat jij nu ervaart exact de reden waarom ik de upgrade methode van Ubuntu verafschuw en naar Debian ben gegaan. Want itt Ubuntu werkt het bij Debian wel gewoon. En omdat ik toch geen bijzondere configuratie heb, draai ik gewoon Unstable. Lekker bleeding edge en rolling release. Zou ik overigens met jouw systeem niet doen, daar zou ik eerder naar Jessie of Stretch (huidige testing) gaan.

[Thralas]

Hero of Time schreef op zondag 05 juni 2016 @ 13:27:
Want itt Ubuntu werkt het bij Debian wel gewoon.

Bullshit.

quote: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes

14.04 LTS to LTS upgrades will be enabled with the 16.04.1 LTS point release, in approximately 3 months time.

De upgrade die TS uitvoert is helemaal niet supported tenzij je met development flags loopt te rommelen. You break it, you get to keep the pieces, dat is precies wat TS nu ervaart.

Hero of Time schreef op zondag 05 juni 2016 @ 13:27:
Nee, vziw gaat Linux altijd over de zeik als er een schijf niet gemount kan worden. Nu met SystemD is het helemaal een drama. Dus als je mdadm array niet op komt, doet systemd en wordt je naar een rescue console getrapt.

Dat is precies het idee van je fstab, als je dat niet wil moet je nofail aan een entry toevoegen.

Anyhow, die rescue shell biedt TS genoeg functionaliteit om die array uit z'n fstab te hakken zodat je het daarna rustig kunt debuggen.

En als het dan nog niet lukt is het handig om meer info te geven, als het goed is vertelt systemd precies welke unit failed voordat hij je in die emergency shell gooit (desnoods even 'quiet' verwijderen uit de kernel args).

[Hero of Time]

Thralas schreef op zondag 05 juni 2016 @ 13:52:
[...]

Bullshit.

[...]

De upgrade die TS uitvoert is helemaal niet supported tenzij je met development flags loopt te rommelen. You break it, you get to keep the pieces, dat is precies wat TS nu ervaart.

Ik heb het over de algemene upgrade methode die Ubuntu hanteert. Ik heb jaren lang Ubuntu gebruikt op m'n desktop en van de 6 keer dat ik kon upgraden (update-manager gaf dat aan), heb ik in 3 van de gevallen zelf een herinstallatie gedaan, 2x de upgrade manager methode gebruikt, die keihard faalde en 1x handmatig de upgrade uitgevoerd door domweg de repo's maar aan te passen en een apt-get dist-upgrade uitgevoerd. Die laatste methode werkte vervolgens wel.

Dat de TS een unsupported upgrade heeft uitgevoerd is niet direct een reden dat het daarom stuk is gegaan. Ik heb ook genoeg mensen gehoord die geen enkel probleem ondervinden met de upgrade manier van Ubuntu.

Ik vind Ubuntu persoonlijk minder prettig vanwege de upgrade die je elke 6-9 maanden moet doen als je de normale releases volgt en die regelmatig gewoon mislukt. Daar hoef je geen speciale omgeving/configuratie voor te hebben overigens.

Maar goed, dat is niet voor in dit topic.

[iMars]

fstab was inderdaad het probleem.... naast m'n raid, had ik op de 32GB een swap en een /tmp zitten, die ook niet meer aanwezig waren. Hij start nu wel gewoon door (Weer een leer momentje ).

Nu verder om php weer werkend te krijgen, want dat gaat ook niet goed, maar goed, daar kom ik wel uit

Thnx voor het meedenken!