Ubuntu installation writes into foreign partitions and MBR without permission, damaging other operating systems on the disk

[Oliver]

Below is the original text of the question as I posted it. Underneath some new information.
Thanks
Oliver Kluge

Hi,

I want to install Ubuntu 10.04 LTS Desktop AMD64 on a PC that has a terabyte sized hard disk, which is already fully partitioned (with two partitions prepared for Ubuntu and Ubuntu's swap device). On that system there is a Logical Volume Manager installed (IBM). This LVM could be ignored by Ubuntu, as it is meant for an existing, working, bootable JFS partition containing eComStation, which is the current version of IBMs OS/2.

But unfortunately, Ubuntu trashes the LVMs information on the disk, either the DLAT or the BBR. After installing Ubuntu _and telling it not to install Grub2 into the MBR (!)_ the LVM info gets damaged beyond repair. Ubuntu runs flawlessly, having actually installed Grub2 into it's partitions PBR, as instructed.

But eComStation won't run, and a Logical Volume Manager run from CD complains corrupt partition info (the actual partition table is intact. But disk editing tools like DFsee show that it's the LVM info that got damaged).

IBMs LVM stores its info in the last sector of track 0, as opposed to the MBR which of course is in the first. The MBR is not damaged. It boots IBMs boot manager out of a small partition, and that runs okay. It will boot Ubuntu and every Windows installed on the system, but because of the damaged DLAT and/or BBR no longer eComStation.

The error can be pinned down to Ubuntu. Immediately before installation everything is fine, immediately afterwards it is broken, reproducibly.

Anyone got a hint why Ubuntu does this, even when told not to install boot code into /dev/sda?

Thanks
Oliver

New information:
a) Happens with 10.04.1, too, and also happens using the installation function of a running Live Ubuntu
b) I bulk copied the entire hard disk to external storage and so I am able to binary compare immediately before and immediately after installing Ubuntu in /dev/sda9 (and Grub2 in there, too, not into the MBR). I am scanning the whole disk, but apparently Ubuntus installer wrote, without permission, into /dev/sda5 which contains the JFS partition of eComStation.

Thanks
Oliver Kluge

[Oliver (ok23)]

Link to the bug report in eComStation:
http://bugs.ecomstation.nl/view.php?id=2914

[Oliver (ok23)]

This is what Ubuntu writes into the MBR without permission
000001f3 ff
000001f4 ff
000001f5 fe
000001f6 88 | c5
000001f7 f0
000001f8 80
000001f9 06
000001fa 35 | f8
000001fb 53 | 52
000001fc 3f
000001fd 38
000001fe 55

And this gets written into /dev/sda5 without permisson
00008025 00
00008026 40
00008027 09
00008028 01 | 00
00008029 00
0000802a 00
0000802b 00
------
0000803d 00
0000803e 00
0000803f 00
00008040 15 | 01
00008041 08 | 00
00008042 00
00008043 00
00008044 05 | 04
00008045 00
00008046 00
00008047 00
------
13ed42005 00
13ed42006 00
13ed42007 00
13ed42008 05 | 04
13ed42009 00
13ed4200a 00
13ed4200b 00
------
13ed42019 00
13ed4201a 40
13ed4201b 09
13ed4201c 00 | 01
13ed4201d 00
13ed4201e 00
13ed4201f 00
------
13fb34003 00
13fb34004 00
13fb34005 00
13fb34006 d8 | b4
13fb34007 0b
13fb34008 01
13fb34009 00
------
13fb34bb1 f1
13fb34bb2 ff
13fb34bb3 7a
13fb34bb4 00 | 54
13fb34bb5 00 | 9d
13fb34bb6 00 | 6a
13fb34bb7 00 | 48
13fb34bb8 00
13fb34bb9 00
13fb34bba 00
------
13fb34bb9 00
13fb34bba 00
13fb34bbb 00
13fb34bbc 00 | 0c
13fb34bbd 40 | 55
13fb34bbe 00 | cd
13fb34bbf 00 | 4c
13fb34bc0 00
13fb34bc1 00
13fb34bc2 00
------
13fb34bc6 00
13fb34bc7 00
13fb34bc8 00
13fb34bc9 88 | 00
13fb34bca ff | 00
13fb34bcb ff | 00
13fb34bcc ae | 00
13fb34bcd 68 | 00
13fb34bce 13 | 00
13fb34bcf 81 | 00
13fb34bd0 ff | 00
13fb34bd1 ff | 00
13fb34bd2 ff | 00
13fb34bd3 ff | 00
13fb34bd4 00
13fb34bd5 00
13fb34bd6 34 | 00
13fb34bd7 bb | 00
13fb34bd8 00
13fb34bd9 00
13fb34bda 00
------
13fb34ffb 00
13fb34ffc 00
13fb34ffd 00
13fb34ffe d8 | b4
13fb34fff 0b
13fb35000 f1
13fb35001 0d

[Oliver (ok23)]

And it gets even worse, it writes into the Windows 7 partition, /dev/sda2, too. Also without permission:
b3885025 00
b3885026 00
b3885027 00
b3885028 9f | 9d
b3885029 00
b388502a cb
b388502b 01
------
b38850cd cb
b38850ce 01
b38850cf 78
b38850d0 cc | 4e
b38850d1 17 | c1
b38850d2 8a | b6
b38850d3 df | 29
b38850d4 bb | e0
b38850d5 79 | 3a
b38850d6 cb
b38850d7 01
b38850d8 00
------
b38851fb dc
b38851fc 78
b38851fd 79
b38851fe 9f | 9d
b38851ff 00
b3885200 f7
b3885201 a2
------
b3885265 cb
b3885266 01
b3885267 78
b3885268 1a | 8a
b3885269 4e | f5
b388526a 7e | 82
b388526b df | 29
b388526c bb | e0
b388526d 79 | 3a
b388526e cb
b388526f 01
b3885270 00
------
b38853fb 00
b38853fc 00
b38853fd 00
b38853fe 9f | 9d
b38853ff 00
b3885400 33
b3885401 95
------
b38855fb 59
b38855fc 00
b38855fd 00
b38855fe 9f | 9d
b38855ff 00
b3885600 54
b3885601 00
------
b38857fb 00
b38857fc 00
b38857fd 00
b38857fe 9f | 9d
b38857ff 00
b3885800 10
b3885801 00
------
b38859fb 6d
b38859fc 00
b38859fd 00
b38859fe 9f | 9d
b38859ff 00
b3885a00 00
b3885a01 88
------
b3885bfb 35
b3885bfc 00
b3885bfd 00
b3885bfe 9f | 9d
b3885bff 00
b3885c00 2e
b3885c01 00
------
b3885dfb 49
b3885dfc 00
b3885dfd 00
b3885dfe 9f | 9d
b3885dff 00
b3885e00 37
b3885e01 00
------
b3885ffb 00
b3885ffc 00
b3885ffd 00
b3885ffe 9f | 9d
b3885fff 00
b3886000 49
b3886001 4e
------
c02b482d 00
c02b482e 00
c02b482f 0a
c02b4830 08 | 07
c02b4831 00
c02b4832 49
c02b4833 00
------
c02b4865 cb
c02b4866 01
c02b4867 78
c02b4868 cc | 4e
c02b4869 17 | c1
c02b486a 8a | b6
c02b486b df | 29
c02b486c bb | e0
c02b486d 79 | 3a
c02b486e cb
c02b486f 01
c02b4870 00
------
c02b49fb 52
c02b49fc 00
c02b49fd 00
c02b49fe 08 | 07
c02b49ff 00
c02b4a00 56
c02b4a01 00
------
c02b4bfb 00
c02b4bfc 00
c02b4bfd 00
c02b4bfe 08 | 07
c02b4bff 00
c02b4c00 46
c02b4c01 49
------
c7d0782d 01
c7d0782e 00
c7d0782f f4
c7d07830 0c | 0b
c7d07831 00
c7d07832 00
c7d07833 00
------
c7d07865 cb
c7d07866 01
c7d07867 78
c7d07868 1a | 8a
c7d07869 4e | f5
c7d0786a 7e | 82
c7d0786b df | 29
c7d0786c bb | e0
c7d0786d 79 | 3a
c7d0786e cb
c7d0786f 01
c7d07870 03
------
c7d079fb 00
c7d079fc 00
c7d079fd 10
c7d079fe 0c | 0b
c7d079ff 00
c7d07a00 08
c7d07a01 02
------
c7d07bfb 00
c7d07bfc 00
c7d07bfd 00
c7d07bfe 0c | 0b
c7d07bff 00
c7d07c00 46
c7d07c01 49

[Leo Arias (elopio)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in ubiquity.

[Oliver (ok23)]

And Ubuntu writes into the logical container /dev/sda4, too:
00000187 00
00000188 00
00000189 00
0000018a 01 | 00
0000018b 2d | 00
0000018c 2d | 00
0000018d 3e | 00
0000018e 20 | 00
0000018f 4c | 00
00000190 56 | 00
00000191 4d | 00
00000192 2a | 00
00000193 00
00000194 00
00000195 00
------
000001c3 ff
000001c4 ff
000001c5 fe
000001c6 3f | 02
000001c7 00
000001c8 00
000001c9 00
------
000001d3 ff
000001d4 ff
000001d5 fe
000001d6 4d | 10
000001d7 12
000001d8 a0
000001d9 00
------
000001fd 55
000001fe aa
000001ff 00
00000200 00 | 02
00000201 00 | 52
00000202 00 | 4d
00000203 00 | 42
00000204 00 | 50
00000205 00 | 4d
00000206 00 | 46
00000207 00 | 44
00000208 00 | 24
00000209 00 | ae
0000020a 00 | cc
0000020b 00 | 64
0000020c 00 | 01
0000020d 00 | ed
0000020e 00 | 5e
0000020f 00 | df
00000210 00 | 01
00000211 00 | ed
00000212 00 | 5e
00000213 00 | df
00000214 00
00000215 00
00000216 00
------
00000215 00
00000216 00
00000217 00
00000218 00 | ff
00000219 00 | ff
0000021a 00
0000021b 00
0000021c 00 | ff
0000021d 00
0000021e 00
0000021f 00
00000220 00 | 3f
00000221 00
00000222 00
00000223 00
00000224 00 | 44
00000225 00 | 69
00000226 00 | 73
00000227 00 | 6b
00000228 00 | 31
00000229 00 | 20
0000022a 00 | 2d
0000022b 00 | 20
0000022c 00 | 20
0000022d 00 | 35
0000022e 00 | 31
0000022f 00 | 34
00000230 00 | 30
00000231 00 | 37
00000232 00 | 32
00000233 00 | 20
00000234 00 | 4d
00000235 00 | 69
00000236 00 | 42
00000237 00
00000238 00
00000239 00
------
00000239 00
0000023a 00
0000023b 00
0000023c 00 | e6
0000023d 00 | 3d
0000023e 00 | e0
0000023f 00 | 1d
00000240 00 | 83
00000241 00 | 5a
00000242 00 | 5c
00000243 00 | a5
00000244 00 | 0e
00000245 00 | 12
00000246 00 | a0
00000247 00
00000248 00 | c7
00000249 00 | f0
0000024a 00 | 80
0000024b 00 | 06
0000024c 00 | 01
0000024d 00 | 01
0000024e 00 | 44
0000024f 00
00000250 00 | 65
00000251 00 | 43
00000252 00 | 6f
00000253 00 | 6d
00000254 00 | 53
00000255 00 | 74
00000256 00 | 61
00000257 00 | 74
00000258 00 | 69
00000259 00 | 6f
0000025a 00 | 6e
0000025b 00 | 20
0000025c 00 | 32
0000025d 00 | 2e
0000025e 00 | 30
0000025f 00
00000260 00
00000261 00
------
00000261 00
00000262 00
00000263 00
00000264 00 | 65
00000265 00 | 43
00000266 00 | 6f
00000267 00 | 6d
00000268 00 | 53
00000269 00 | 74
0000026a 00 | 61
0000026b 00 | 74
0000026c 00 | 69
0000026d 00 | 6f
0000026e 00 | 6e
0000026f 00 | 20
00000270 00 | 32
00000271 00 | 2e
00000272 00 | 30
00000273 00
00000274 00
00000275 00

All of these diffs were generated from binary comparing disk devices /dev/sdb_n_ and /dev/sda_n_. A binary comparison of /dev/sdb and /dev/sda is added as an attachment, together with an fdisk output of /dev/sda.

[Oliver (ok23)]

I wonder why nothing happens? This is serious stuff!

Installing Ubuntu damages foreign partitions, effectively killing other operating systems! IMHO, such a (mis)behaviour cannot be tolerated and requires a timely bugfix!

[Dave Yeo (dave-r-yeo)]

I'm also very unhappy with 10.10 destroying my OS/2 LVM information. I'll add that I had a couple of preexisting swap partitions on different drives and these drives also had their LVM tables corrupted

[Frank Beythien (fbeythien)]

My LVM information was corrupted, too. After trying Ubuntu 10.10 in Virtualbox and as Live CD with success, I installed into free space following my eCS / OS/2 LVM partitions, just to make the disk unusable until restoring a backup.

[interbird1964 (interbird1964)]

Debian Squeeze now has this behaviour too.
What actually happens is that the lower bound of the extended container,
which is based on a cylinder boundary when created with eCOmStation's (OS/2) LVM disktool,
is moved upwards to a MiB boundary by the Debian Squeeze / Ubuntu 10.04+ installation process.

This causes the eComStation Logical Volume Management system to fail,
as it expects the extended container to start on a cylinder boundary.

It would be very neighbourly if the Linux people would respect eComStations disk-layout
and not touch the extended container.

Since the extended container can potentially contain other bootable operating systems,
this Linux installer behaviour could be considered quite anti-social, since it has no business
messing with the extended container.

There already exists a company that messes with parts of the disk it does not own for
more that decades.

Please don't duplicate this behaviour.

[interbird1964 (interbird1964)]

The kernelparameter 'partman/alignment=cylinder' seems to fix this behaviour.

When you add the 'partman/alignment=cylinder' kernel-parameter before
starting the Linux installation, the partitioner will not realign the
extended partition to MB-boundaries and eCS LVM-info will be preserved.

So, installing Ubuntu 10.10 will go like this:
- Create the extended partition (and swap) with eCS MiniLVM
- Boot from the Ubuntu live CD
- Press a key to get the menu (this takes a second before being displayed)
- Choose your language
- Press F6
- Press ESC

Now you see the line with the kernel-parameters that looks something like this:
..... quiet splash --
Insert the partman-parameter, so the line reads like:
..... quiet splash partman/alignment=cylinder --

Double-check you spelled the parameter correctly.

Now proceed with the Linux installation.

Note: I have not tested this on non-Debian derived distro's.

[Dale Diamond (ntxmt)]

This BUG is worse than any I've ever experienced. PLEASE GIVE IT SOME HIGH PRIORITY!!! I am not a programmer, user only. I wish I could help fix it. I've seen this one cause a newly installed Ubuntu 10.10 installation to not boot using IBM boot manager. Boot manager was set up to point to that specific Linux drive but now, boot manager can't see or edit it. When trying to boot, the screen comes back and says the drive is not formatted. Yet I can boot from a cd and look at the drive and see that there are the Linux directories present. Strangely enough, the OS2 install survived it. In another instance, the OS/2 drives are rendered inert. In both cases however, the windoze installs have survived. This one is also reported on the eComstation bug list. Please help. This one is more serious than given credit for being. There are business files and such involved here. It's back up but so what? That doesn't fix the problem. Please find a way to repair damaged drives.

[Oliver (ok23)]

So now that a couple of other users say there parition layout has been killed, too: Could someone at least please markt the bug "Confirmed" - as the bug reporter I would be hesitant to do this myself.

It is a shame that no one finds a bug that kills other operating systems on the disk important enough to introduce a fix. Previously I only thought Windows would be so anti-social to not respect what other OSes wrote on the disk.

[Oliver (ok23)]

B y pure chance I hit the "Also affects project" button, and the screen that comes up then says that ubiquity doesn't track it's bugs on Launchpad. My goodness.

So I have decided to use the dialog that reports this bug as being upstream, but it has not yet been reported there. Let's hope that we now got the attention of the right people to this critical bug...

[Colin Watson (cjwatson)]

I'll throw this over to partman-base while I ponder on exactly where to fix it. Thanks for observing that partman/alignment=cylinder is a workaround; that suggests some useful possibilities.

Oliver, ubiquity doesn't have a separate upstream existence - it's a package in Ubuntu and that's as far upstream as it goes, which is why you got that message about it not tracking its upstream bugs in Launchpad. The Ubuntu task here is fine.

[Colin Watson (cjwatson)]

It would be really helpful if somebody could attach /var/log/installer/syslog and /var/log/installer/partman from an Ubuntu installation that has damaged the partition table in this way.

[Dale Diamond (dale-diamond)]

I'd be happy to send you the requested files. I'm logged in as administrator but the system tells me permission is denied. Another bug?

[Colin Watson (cjwatson)]

I doubt it; I suspect you're a non-root user with sudo permissions, so
the system is behaving as designed. You can use a root shell to copy
the files to somewhere readable.

[Dale Diamond (dale-diamond)]

Colin - files sent to your canonical.com e-mail address.

[Oliver (ok23)]

partman log: http://paste.ubuntu.com/818254/
installer syslog: http://paste.ubuntu.com/818256/

[Oliver (ok23)]

Also there is a Launchpad question for the same topic, I moved that to partman-base. There is bootinfoscript output:

http://paste.ubuntu.com/805639/

But obviously bootinfoscript is not aware of MBR boot code written by IBMs Boot Manager, it falsely declares the MBR to be empty. The script was run on my current configuration, where IBM Boot Manager takes care of booting all my six OS on the disk. Boot Manager has a partition of its own (sda3).

[misterp (ubuntu-f-misterp)]

This also happens when using Boot It Bare Metal(http://www.terabyteunlimited.com/bootit-bare-metal.htm) as a boot manager and Kubuntu 12.04.

[Oliver (ok23)]

This is still open?

Has anyone tried this on Precise?