Allvarligt fel efter GRUB-uppdatering i Ubuntu 9.10

[mghg]

En uppdatering av GRUB för Ubuntu 9.10 har orsakat ett mycket allvarligt fel på min bärbara dator. Felet beskrivs nedan men det är inte hjälp med felet jag här frågar efter, utan jag önskar råd och hjälp med att rapportera felet till Canonical.

Jag har större delen av 2009 använt ett USB-minne med ett fullständig Ubuntu-system, d.v.s. inklusive GRUB så att det har gått att köra igång systemet från vilken dator som helst under förutsättning att datorn har accepterat boot från USB. För c:a en månad sedan installerade jag 9.10 och igår startade jag Uppdateringshanteraren och då genomfördes bl.a. en uppdatering av GRUB.

Under GRUB-uppdatering skrevs en del felmeddelanden som svischade förbi i detalj-fönstret, men efter en stund rapporterade ändå Uppdateringshanteraren att allt var klart och efterfrågade omstart. Jag upptäckte inga problem under omstarten och allt såg ut att fungera som det skulle.

När jag sedan startade datorn på normalt vis utan USB-minnet för att använda systemet på hårddisken så startade GRUB som aldrig tidigare funnits på datorns hårddisk. Eftersom inte USB-minnet satt i datorn så gick det inte att komma vidare. Det riktigt allvarliga är att det inte gick att få igång det Windows-system som är installerat på datorns krypterade hårddisk. (Det gick dock att få igång USB-minnets Ubuntu-system som tidigare).

Min (ganska självklara) slutsats är att GRUB-uppdateringen har hamnat på hårddiskens masterboot-area istället för på USB-minnet och därmed förstört "upplåsningsprogrammet" för hårddiskkrypteringen.

Nu har jag lämnat in datorn för att komma mina filer på hårddisken och jag efterfrågar ingen mer hjälp med det problemet, men önskar råd och hjälp med att rapportera felet till Canonical.

MGHG

[Osprey]

Grub-uppdateringen har antagligen hamnat helt korrekt på USB-pinnen, men på något sätt har antagligen MBR på hårddisken skrivits över. Det enda MBR egentligen gör är att peka ut för datorn var Grub (eller t.ex en Windows-loader) finns och att det är den som ska användas för att starta upp datorn.

Upplåsningsprogrammet för hårddiskkrypteringen ligger/låg med största sannolikhet inte i MBR utan i de delar som MBR pekade ut på Windows-disken. Förmodligen hade du kunnat fixa problemet själv med SuperGrub där du helt enkelt hade talat om att Windows bootloader ska användas istället för Grub. Det borde för den delen också ha funkat att göra en "chainload" från USB-pinnen till Windows-loadern på disken, jag har svårt att tänka mig att Windows bootloader är krypterad.

Jag har installerat både Grub och Grub2 ett antal gånger, men vad jag kan påminna mig så har den alltif frågat efter på vilken disk jag vill ha Grub installerat. Enda möjliga problemet skulle kunna vara om jag skulle vilja installera Grub enbart i en viss partition, men inte för hela disken (vilket motsvaras av MBR). Såväl Grub/Linux som Windows skriver i detta läge både till partitionen och till MBR, vilket för det mesta är helt logiskt.

Förutom nyinstallationerna av Grub så har jag bara gjort en Grub-uppdatering (från Grub till Grub2) en gång och jag kommer inte ihåg exakt vad den frågade då. Hur som helst så är detta kanske inte relevant i mitt fall eftersom jag ändå har Grub för att starta upp både Linux och Windows (okrypterat).

En uppdatering av Ubuntu till 9.10 ska hursomhelst inte installera Grub2 automatiskt så någon sådan uppdatering bör inte ha skett.

Kan det vara så enkelt att du av misstag svarat ja på att installera Grub i /dev/sda, vilket antagligen är Windows.?

Jag ber om ursäkt om det är något jag missat, själv har jag av prestandaskäl varit restriktiv med att kryptera själva systemet. Vid de tillfällen jag gjort det har krypteringen oftast legat i själva hårdvaran...

[Bowmore]

Jag råkade ut för samma sak, dvs att en uppdatering av paketet grub-pc (vill jag minnas) skrev över MBR på första disken utan att jag själv kunde påverka det. Jag återställde MBR men kollade tyvärr inte om det fanns en bugg rapporterad då och skrev ingen själv. Nu var det ett tag sen och svårt att återskapa så vi får hoppas att det åtgärdats. Dessutom lär flertalet aldrig upptäcka detta då de har grub installerat på första disken. Återkommer med ev buggrapport om jag hittar en sån.

Edit
Hittade fler buggar, t.ex denna:
update to grub-pc writes MBR without checks, prompt or backup
Tycker att Felix Zielcke (Proud Debian Maintainer and GNU GRUB developer) är ute och cyklar lite

[mghg]

Tack Osprey och Bowmore för era svar. Efter så lång tid undrade jag om det skulle bli något alls ...

Kan det vara så enkelt att du av misstag svarat ja på att installera Grub i /dev/sda, vilket antagligen är Windows.?

Jag ber om ursäkt om det är något jag missat, själv har jag av prestandaskäl varit restriktiv med att kryptera själva systemet. Vid de tillfällen jag gjort det har krypteringen oftast legat i själva hårdvaran...

Som jag minns det så genomfördes uppdateringen utan någon fråga om var grub skulle ligga i fortsättningen.

Det företag där jag är anställd har som regel att samtliga bärbara datorer skall ha hårddiskkryptering, speciellt om man reser i tjänsten. Att då få krypteringsprogrammet i MBR förstört var en mycket trist upplevelse som medförde flera dagars merjobb med ominstallation etc. (det har inget med backup att göra).

Hittade fler buggar, t.ex denna:
update to grub-pc writes MBR without checks, prompt or backup
Tycker att Felix Zielcke (Proud Debian Maintainer and GNU GRUB developer) är ute och cyklar lite

Beskrivningen av Bug #495423 var så lik mitt problem att jag skrev en kommentar istället för att lämna in en helt egen bug-anmälan.

Det tråkigaste med hela historien för min del är att jag numera inte vågar ta risken att starta min bärbara dator från ett USB-minne med Ubuntu. Visserligen kan man strunta i uppdateringar och installationer, men att inte kunna ha ett fräscht system är inget alternativ för mig. Och därmed blir det tyvärr ingen mer Ubuntu alls på ett tag.