partitioner wrongly identifies ext4 partition (upgraded from ext3) as ext3
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
parted (Ubuntu) |
Fix Released
|
Medium
|
Colin Watson | ||
partman-base (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Binary package hint: debian-installer
Due to another issue I ended up with a hosed Lucid. I then decided to reinstall, using the Ubuntu ISO from 2010-04-11. Now, this system uses LVM, and has a series of partitions:
/dev/mapper/
/dev/mapper/sys-tmp on /tmp type ext4 (rw)
/dev/sda2 on /boot type ext4 (rw)
/dev/mapper/sys-usr on /usr type ext4 (rw)
/dev/mapper/sys-var on /var type ext4 (rw)
/dev/mapper/sys-src on /src type ext4 (rw)
/dev/mapper/
/dev/mapper/sys-opt on /opt type ext4 (rw)
/dev/mapper/sys-srv on /srv type ext4 (rw)
Plus the SWAP partition (a primary partition).
Now, specially important, /srv, /opt, and /src are EXT3 partitions upgraded to EXT4 previously (during the Karmic cycle).
The partitioner was unable to see the above 3 partitions as ETX4, insisting in EXT3. Obviously, they failed to mount. Setting them as EXT4 would force them to be formatted, with loss of all data.
I bypassed this by marking them *do not use* and, after Lucid was installed, hand-editing /etc/fstab and adding them as EXT4.
THIS IS A POTENTIAL DATA LOSS SITUATION. If I had not already lost a partition -- /home, also an EXT3-upgraded-
Of course, this is a corner case, but I would expect more users to also fall into this: in Karmic we moved to EXT4, and many users upgraded their existing EXT3.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: debian-installer 20081029ubuntu97
ProcVersionSign
Uname: Linux 2.6.32-20-generic x86_64
Architecture: amd64
CheckboxSubmission: 23f39d583e28959
CheckboxSystem: d00f84de8a55581
Date: Mon Apr 12 10:27:04 2010
Dependencies:
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100411)
MachineType: Dell Inc. Inspiron 1721
MemoryUsage:
total used free shared buffers cached
Mem: 3928264 3757572 170692 0 171912 2490748
-/+ buffers/cache: 1094912 2833352
Swap: 5277344 60 5277284
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
LC_TIME=en_DK.utf8
PATH=(custom, no user)
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: debian-installer
dmi.bios.date: 04/21/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: 0RT951
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Inspiron 1721
dmi.sys.vendor: Dell Inc.
Related branches
affects: | debian-installer (Ubuntu) → partman-base (Ubuntu) |
Changed in partman-base (Ubuntu): | |
importance: | Undecided → Wishlist |
status: | New → Triaged |
Any filesystem type change will cause the partitioner to reformat. If you want to reuse an existing partition, then you must be careful.
Aside from fixing whatever the autodetection problem is (which merely moves the problem around, since you still have to know what filesystem is in use and many people won't know offhand), the only way I can see to improve this is to show the current filesystem type somewhere. However, that code is subtle and quick to anger, and I don't intend to touch it any more for Lucid at this point lest I introduce worse problems.