Hi,

I've found that d-i creates /boot as ext2 for guided partioning
with LVM. I think ext4 is better but is there any reason to do so?
(e.g. some architecture or bootloader cannot recognize ext4 for it)

If not, I'll prepare a MR for it.
(Of course, it will be treated after bullseye release).


--
Regards,

Hideki Yamane henrich @ debian.org/iijmio-mail.jp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Hideki!

On Aug 7, 2021, at 4:12 PM, Hideki Yamane <henrich@iijmio-mail.jp> wrote:

I've found that d-i creates /boot as ext2 for guided partioning
with LVM. I think ext4 is better but is there any reason to do so?
(e.g. some architecture or bootloader cannot recognize ext4 for it)

It’s normally a bootloader compatibility issue but since we switched many architectures over to GRUB where possible, it might no longer be necessary to use ext2 for /boot.

I will have to go through the list of bootloaders currently in use and I’ll let you know.

I’m currently not at home, so I can’t to that right now. But I can do that tomorrow evening.

Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2021-08-07 at 16:24 +0200, John Paul Adrian Glaubitz wrote:

Hi Hideki!

On Aug 7, 2021, at 4:12 PM, Hideki Yamane <henrich@iijmio-mail.jp>

wrote:

I've found that d-i creates /boot as ext2 for guided partioning
with LVM. I think ext4 is better but is there any reason to do so?
(e.g. some architecture or bootloader cannot recognize ext4 for it)

It’s normally a bootloader compatibility issue but since we switched
many architectures over to GRUB where possible, it might no longer be necessary to use ext2 for /boot.

I will have to go through the list of bootloaders currently in use
and I’ll let you know.

[...]

This is bug #985463.

Ben.

--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmESuHEACgkQ57/I7JWG EQnLvBAAx8+KtZZ9flxMwB52oVcTvwxSOPSS09PCmSQSLfZ9PPkaB9ZiF0+n0Svg dvAgq1LLcuD0CCTzq6QSvr6JTsGRIL8vA83/2gFtuS0R3ndPvBklTzQ0xOKyT6dN E1P2/XtMFH7awa10jpgiqth0jfMWIAWA8gE4cK4aOcAJqCWQZAJSQv/7OI7fQJpn OXbnNGVEvkBPo4/42P56s7wAgQAAAE8x+kIXaK0TTwPM29xiafS9ryOh3L0yS4nk E5eQ6wVarg4OnEEoLA5uenGRFIYDnMLM0bdaIVuEnhkEUjJ+ucZLlpZbkUMyZjAz KDpFCk4PXaKDGy47lIYJC3ehK+xT4rkBjcQ7CFiGt+02iwHg4dpUAeT7Yz0N8SrF CZIN9dHuDUbOAi0n0iDvqwR2z702Kn1X4h18M61fivHVu0AxtUL+vZlGuiuWZvgC xUDSQXnfxL3L+iRnMSYgznqSnc83XP3vNwEzKXZ+UK7X21FhYDrvxd4gjppCVM3/ Eff6g6MSpkdnIM1/Tic3qcny8IWtA9uYegs9FcL9McXlixqAKOLpO8gVMEosLAWy 11B4dxpx7TPCX2pi2i32nypICCvOdxDVX/YSML4Qq6xiihlXmsboedz3tpD9KbaJ LfGzBiTftJj9EFzymC0ps8mDfkD6ZJtL0stmZzyLZZpstiPdV8Q=
=tAtR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/4/21 22:32, Hideki Yamane wrote:

On Tue, 10 Aug 2021 19:33:37 +0200
Ben Hutchings <ben@decadent.org.uk> wrote:

This is bug #985463.

If we can confirm no architecture has a limit to use ext2 now,
then we can change it to ext4, right?

We should make a list with the bootloaders in use. Many architectures use
GRUB but some architectures use boot loaders that use blocklists so they
still may work with ext4.

Architectures that use GRUB are:

- amd64
- arm64
- i386
- ia64
- powerpc
- ppc64
- ppc64el
- riscv64 (not sure if supported on all boards)
- sparc64
- s390x (loaded from zIPL)
- x32

Other bootloaders are:

- armel - u-boot
- armhf - u-boot
- alpha - aboot
- hppa - palo
- m68k - amiboot, atariboot, emile
- mipsel - u-boot
- mips64el - u-boot
- riscv64 - u-boot
- sh4 - u-boot

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 Aug 2021 19:33:37 +0200
Ben Hutchings <ben@decadent.org.uk> wrote:

This is bug #985463.

If we can confirm no architecture has a limit to use ext2 now,
then we can change it to ext4, right?


--
Regards,

Hideki Yamane henrich @ debian.org/iijmio-mail.jp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Sep 05, 2021 at 05:32:51AM +0900, Hideki Yamane wrote:

On Tue, 10 Aug 2021 19:33:37 +0200
Ben Hutchings <ben@decadent.org.uk> wrote:

This is bug #985463.

If we can confirm no architecture has a limit to use ext2 now,
then we can change it to ext4, right?

Ummm. In my experience quite a number of older armel/armhf devices
booting using U-Boot may *not* be able to boot using ext4. Whether we
should change the default on other arches is a useful discussion, but
I'd be worried about maybe breaking support here.

--
Steve McIntyre, Cambridge, UK. steve@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/4/2021 1:44 PM, John Paul Adrian Glaubitz wrote:

On 9/4/21 22:32, Hideki Yamane wrote:

On Tue, 10 Aug 2021 19:33:37 +0200
Ben Hutchings <ben@decadent.org.uk> wrote:

This is bug #985463.

If we can confirm no architecture has a limit to use ext2 now,
then we can change it to ext4, right?

I may have missed some of the discussion, but if we are talking about a
/boot partition, there is no good reason to change it to ext4. The
performance advantages of a JFS just don't matter on a partition that
seldom changes. Since ext2 can be read by any system that can read ext4,
that also is not an issue. So why change?

If we are talking about a /boot directory that is part of a larger
partition that contains other things that are regularly written to, that
is a different case.

Bill Campbell

We should make a list with the bootloaders in use. Many architectures use GRUB but some architectures use boot loaders that use blocklists so they still may work with ext4.

Architectures that use GRUB are:

- amd64
- arm64
- i386
- ia64
- powerpc
- ppc64
- ppc64el
- riscv64 (not sure if supported on all boards)
- sparc64
- s390x (loaded from zIPL)
- x32

Other bootloaders are:

- armel - u-boot
- armhf - u-boot
- alpha - aboot
- hppa - palo
- m68k - amiboot, atariboot, emile
- mipsel - u-boot
- mips64el - u-boot
- riscv64 - u-boot
- sh4 - u-boot

Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 4 Sep 2021 14:00:06 -0700
"J. William Campbell" <jwilliamcampbell@comcast.net> wrote:

but if we are talking about a
/boot partition, there is no good reason to change it to ext4.

Ext4 is reliable than ext2, I guess. And, /boot needs it.


--
Regards,

Hideki Yamane henrich @ debian.org/iijmio-mail.jp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 4 Sep 2021 21:43:50 +0100
Steve McIntyre <steve@einval.com> wrote:

Ummm. In my experience quite a number of older armel/armhf devices
booting using U-Boot may *not* be able to boot using ext4.

I don't have any knowledge about U-Boot and arm devices, so here's
a question. Is U-Boot different on each devices? It means, U-Boot
on device A can read ext4 but on device B cannot.


--
Regards,

Hideki Yamane henrich @ debian.org/iijmio-mail.jp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/4/2021 4:47 PM, Hideki Yamane wrote:

On Sat, 4 Sep 2021 14:00:06 -0700
"J. William Campbell" <jwilliamcampbell@comcast.net> wrote:

but if we are talking about a
/boot partition, there is no good reason to change it to ext4.

Ext4 is reliable than ext2, I guess. And, /boot needs it.

Ext4 is more reliable than ext2 in that it journals it's metadata
changes so that if a write doesn't complete for some reason the volume
can be recovered the next time it is mounted. However, on a boot
partition which receives essentially no writes after it is initially
created, this is no advantage at all, as there are no writes being done.
Since this change may cause some people trouble and doesn't help
anything as far as I can see, why do it?

Best Regards,

Bill Campbell




--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Would it be possible to make uboot (and/or any of the other non-grub boot loaders) load grub, which then would load and configure the kernel from an ext4 or LVM partition?

Rick

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello all,

John Paul Adrian Glaubitz wrote:

On Aug 7, 2021, at 4:12 PM, Hideki Yamane <henrich@iijmio-mail.jp> wrote:

I've found that d-i creates /boot as ext2 for guided partioning
with LVM. I think ext4 is better but is there any reason to do so?
(e.g. some architecture or bootloader cannot recognize ext4 for it)

It’s normally a bootloader compatibility issue

Why then does guided partitioning without LVM use ext4 for / and not
create a separate ext2 /boot ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Sep 05, 2021 at 09:00:52AM +0900, Hideki Yamane wrote:

On Sat, 4 Sep 2021 21:43:50 +0100
Steve McIntyre <steve@einval.com> wrote:

Ummm. In my experience quite a number of older armel/armhf devices
booting using U-Boot may *not* be able to boot using ext4.

I don't have any knowledge about U-Boot and arm devices, so here's
a question. Is U-Boot different on each devices? It means, U-Boot
on device A can read ext4 but on device B cannot.

That's correct. U-Boot is often forked by vendors, then built with
their own special config. Depending on the age of the board (and the
fork!), I've seen lots of different issues here. :-(

--
Steve McIntyre, Cambridge, UK. steve@einval.com 'There is some grim amusement in watching Pence try to run the typical
"politician in the middle of a natural disaster" playbook, however
incompetently, while Trump scribbles all over it in crayon and eats some
of the pages.' -- Russ Allbery

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/5/2021 6:41 AM, Steve McIntyre wrote:

On Sun, Sep 05, 2021 at 09:00:52AM +0900, Hideki Yamane wrote:

On Sat, 4 Sep 2021 21:43:50 +0100
Steve McIntyre <steve@einval.com> wrote:

Ummm. In my experience quite a number of older armel/armhf devices
booting using U-Boot may *not* be able to boot using ext4.

I don't have any knowledge about U-Boot and arm devices, so here's
a question. Is U-Boot different on each devices? It means, U-Boot
on device A can read ext4 but on device B cannot.

Actually, I doubt that is literally true, although there is a big
asterisk involved. AFAIK, the on disk format for ext4 is the same as
ext2. If the code can read an ext2 filesystem, it can read an ext4
filesystem. The "asterisk" is that older u-boots didn't know about ext4,
so when they check the version of the filesystem they see a number that
they don't understand and give up. So, de-facto they won't read the
filesystem, although they actually could!

FWIW, I have always used a separate "boot" partition. It can waste a
small amount of disk space unless you pay close attention to how big it
needs to be, but it is never written to (almost) and therefore is much
less likely to be damaged by some hardware, software, or operator error.
TBH, it is also because "back in the day" many bios couldn't read a
large disk and the boot partition had to be on low cylinder numbers.  In
any case, it is a simple thing to do and has no down side AFAIK. Having
this as the default behavior seems like a good idea to me😁.

Bill Campbell

That's correct. U-Boot is often forked by vendors, then built with
their own special config. Depending on the age of the board (and the
fork!), I've seen lots of different issues here. :-(

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Le 05/09/2021 à 18:47, J. William Campbell a écrit :

AFAIK, the on disk format for ext4 is the same as
ext2. If the code can read an ext2 filesystem, it can read an ext4 filesystem.

I am not sure about that. AFAIK, some ext4 features such as extents
create a different on-disk format than ext2 or ext3. The ext2, ext3 and
ext4 Linux drivers refuse to mount an ext4 filesystem as ext2 because of unsupported features.

older u-boots didn't know about ext4,
so when they check the version of the filesystem they see a number that
they don't understand and give up.

IIUC, an ext* filesystem does not have a version number. Instead it has
a collection of "features", some of which are supported only by ext4.

But IMO the real point is : if ext2 is mandatory for /boot when
installing with LVM, why then is it not mandatory when installing
without LVM ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/7/2021 12:58 AM, Pascal Hambourg wrote:

Hello,

Le 05/09/2021 à 18:47, J. William Campbell a écrit :

AFAIK, the on disk format for ext4 is the same as ext2. If the code
can read an ext2 filesystem, it can read an ext4 filesystem.

I am not sure about that. AFAIK, some ext4 features such as extents
create a different on-disk format than ext2 or ext3. The ext2, ext3
and ext4 Linux drivers refuse to mount an ext4 filesystem as ext2
because of unsupported features.

Actually, there is a 32 bit rev level defined in the superblock.
However, it doesn't distinguish much and isn't the whole story. There
are also feature bits that must be supported by any software attempting
to read the disk. I think you are correct that incompatible features
would cause any software trying to read the disk to fail. ext4 also
supports 48 bit block numbers. It is therefore probable u-boot couldn't actually read an ext4 file system if the file sizes were such that
extents were used. It doesn't actually matter, because u-boot see
options it doesn't recognize and won't try.

older u-boots didn't know about ext4, so when they check the version
of the filesystem they see a number that they don't understand and
give up.

IIUC, an ext* filesystem does not have a version number. Instead it
has a collection of "features", some of which are supported only by ext4.

But IMO the real point is : if ext2 is mandatory for /boot when
installing with LVM, why then is it not mandatory when installing
without LVM ?

Good question. I think it should be. Making the boot partition as simple
as possible without adding problems accessing it from "normal" software
seems like a good goal. All userspace programs can access ext2 file
systems with ease equal to ext4. IMHO it should be a requirement that
the file system be ext2. For sure, the boot partition doesn't need 48
bit block numbers an "largefile" support. The kernel/initrd is big but
not that big😁.



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)