hyper-v: Manual partitioning formats /boot with ext2 file-system

[Abhishek Gupta]

Hi,

It appears that if users manually partition the disk, the /boot partition is formatted using the ext2 file-system. This breaks certain backup scenarios for Hyper-V. Is it possible to change the default format for the /boot partition to ext4?

Please let us know and see attached image for more details.
Thanks,
Abhishek

[Abhishek Gupta (abgupta)]

Logs not required.

[Dimitri John Ledkov (xnox)]

On 2 April 2014 16:41, Launchpad Bug Tracker <email address hidden> wrote:
> You have been subscribed to a public bug:
>
> Hi,
>
> It appears that if users manually partition the disk, the /boot
> partition is formatted using the ext2 file-system. This breaks certain
> backup scenarios for Hyper-V. Is it possible to change the default
> format for the /boot partition to ext4?
>
> Please let us know and see attached image for more details.
> Thanks,
> Abhishek
>

/boot is specifically formatted with ext2 to maximize available
disk-space. As ext2 does not reserve space for journals, etc.
/boot is only used in lvm2/crypt setups. If you require for it to be
ext4, you can provide custom recipe to make sure it's formatted as
ext4 or upgrade to ext4 at post-install (e.g. by simply modifying
/etc/fstab and mounting it as ext4).

Are you sure that it's /boot that's causing problems? Because
ext2/ext3 are forward compatible, that is one can mount/treat it as if
it they were ext4. Thus it should not make any differences if
something is in fact ext2, 3 or 4 (especially for e.g. backup solution
which should access things read-only).

--
Regards,

Dimitri.

[Dimitri John Ledkov (xnox)]

In the screenshot you provide, you can select and choose ext4 if you wish. =)

[Abhishek Gupta (abgupta)]

Hi Dimitri,

Thanks for the explanation. The reason we are having trouble with ext2 is because ext2 does not seem to have a freeze file-system interface. The freeze interface typically flushes all dirty buffers to disk and allows the creation of a file-system consistent snapshot prior to backup. If we take a non file-system consistent backup then restoring the volume later would cause fsck checks that may alarm users or corrupt the file-system in unknown ways.

We can recommend customers to use ext4 in our documentation however it is often that people just go with the default choice. This is the reason why we were wondering if you could change the boot file-system to ext4.

If you do not expect /boot to be modified then wouldn't the journal have a very low impact anyway? Could we tune the journal to be of a small size?

Let me know your thoughts.
Thanks,
Abhishek

[Phillip Susi (psusi)]

As noted in bug #527667, we should not be using ext2 for /boot. The space saved on a 150m /boot by not using the journal is only 7 mb. This is hardly worth the loss of reliability not to mention the fsck after a crash.

[Abhishek Gupta (abgupta)]

Hey Dimitry, You seemed to have closed the bug as Won't fix. However given Phillip's and my comments above, I do see some sense in changing the default choice. Would it be possible to fix it? Please let us know.
Thanks,
Abhishek

[James Page (james-page)]

Unfortunately making this switch so close to the 14.04 release date (next week) is not feasible; I discussed with Dimitry and neither of us where comfortable with making this change right now; its a small change with potential for quite a big impact.

[Dimitri John Ledkov (xnox)]

Hello Abhishek and Phillip,

I've discussed this with a few other engineers and it is to risky to push such change this close to release. There are a few things that are planned / needed to be done with "/boot" and we should target it at u-series. This is a valid bug report / request, but i'm targeting it at u-series for now.

We need to increase size of /boot, use ext4 (possible with journal, extents and huge file options disabled), remove need for /boot at all when one is using simple LVM volume group only. All of these changes are straight-forward, but can have impact on existing deployments and these are not features we'd be comfortable with deploying so late in the cycle, way past Feature Freeze.

Regards,

Dimitri.

[Joseph Salisbury (jsalisbury)]

New bug opened: bug 1362574

[Joseph Salisbury (jsalisbury)]

May want to mark bug 1362574 as a duplicate if that is the case.

[Kylie Liang (kyliel)]

Is this not considered in Ubuntu 14.10 or not any longer in future?

[Phillip Susi (psusi)]

14.10 has already been released so it won't be fixed there.

[Chris Valean (cvalean)]

Hi Phillip,
Can this please be taken into consideration for the next release?
The report has been sent during Trusty, and was delayed through Utopic with no resolution or plan to modify.

If ext2 is kept, then Dexuan has found a few community patches that might be applicable, these have been mentioned in the other thread - Bug ID 1362574

Thank you!

[Dexuan Cui (decui)]

The patches have been in the mainline tree:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bda3253043c54a705c8352096194ab6216e2e5c1
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb0445765866e5b1607af81e2f48ca5a8efbeed8
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f6e63f90809946d410c42045577cb159fedabf8c

Please consider adopting the patch in a future release.

[Dimitri John Ledkov (xnox)]

@decui I've pinged kernel people about those patches, if/when they make into normal release they will also make it into trusty point release via hwe kernels. Thus ext2 freezing will be possible at some point in trusty. I'm awaiting further comments from them.

[Leann Ogasawara (leannogasawara)]

Hi Dimitri et al,

I see the patches noted in comment #15 have been included in the upstream kernel as of v3.18-rc2 and are currently available from our Vivid kernel in the archive. The Vivid HWE kernel will be introduced in the Trusty 14.04.3 point release as well. Thanks.

[Chris Valean (cvalean)]

Verified this against the latest Vivid Server daily build and the issue seems resolved, we were able to successfully create a live backup and restore a default Ubuntu installation with the default partitioning - /boot being ext2.

Testing details:
Linux ubuntu1504 3.19.0-9-generic #9-Ubuntu SMP Wed Mar 11 17:50:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

In the logs there's a message that would relate to this:
Mar 18 15:13:59 ubuntu1504 kernel: [ 14.716508] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem