Bug #1407

disklabel64 boot problem

Added by thomas.nikolajsen almost 5 years ago. Updated over 1 year ago.

Status:ResolvedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Booting DragonFly from disklabel64 slice has problems:
- using HAMMER it almost works: one module can't be read
Reading /modules/acpi.ko fails; after booting (host can run without ACPI)
(i.e. by kernel) acpi.ko can be read and contents is correct.
(files on test HAMMER system are just cpdup'ed from a working system;
cmp verified acpi.ko is readable and has same contents)

Also doing ls command in loader on HAMMER file system can crash loader.
It seems like libstand/hammerread has an issue.

- using UFS it doesn't work: I just see a spinning bar
It doesn't show any text, like BTX..

I had the impression that disklabel64 booting should be working
(since commits below); is this correct?

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/d64b2e330d33214f962ba88
400ebbf8d11c18ef4
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/6080181b861dd0889598b54
645d4512a48800d21

Is zeroing slice start before making bootable disklabel still needed?
If yes: is it enough to zero 16KB, like disklabel32.

I was going to update disklabel64.8 to include boot info again;
but will hold it back until this issue is resolved.

History

#1 Updated by corecode almost 5 years ago

Matthew Dillon wrote:
> :Booting DragonFly from disklabel64 slice has problems:
> : - using HAMMER it almost works: one module can't be read
> :Reading /modules/acpi.ko fails; after booting (host can run without ACPI)
> :(i.e. by kernel) acpi.ko can be read and contents is correct.
> :(files on test HAMMER system are just cpdup'ed from a working system;
> :cmp verified acpi.ko is readable and has same contents)
>
> It sounds like the hammer fs read code in the boot loader isn't
> handling all the cases properly.

Yes, we should try and fix that. Thomas, can you compile hammerread.c
and try to find out why it is having a problem?

> I'm going to be blunt on the HAMMER boot thing... I don't actually
> like the idea, because the boot code can't run the UNDO's after a
> crash and so might not be able to find the kernel and other boot
> related files. I would rather just boot from a small UFS /boot
> partition and then have the kernel mount HAMMER as the root.
>
> I guess I'll have to deal with changing the installer to create a
> BOOT+HAMMER setup instead of a straight HAMMER setup.

However so far nobody had problems since we fixed the last bugs. I
absolutely agree that we should have the boot code reading the UNDO, and
also multi-volume HAMMER file systems will not work with the boot loader
(will never). However I think for a simple setup, having just one
HAMMER file system should be supported and perfectly fine.

But then, maybe I'm too much an HAMMER enthusiast, and we should go the
Linux route and always install a (UFS) /boot. Then it is also easier to
run more complex setups, like vinum, ccd, etc.

cheers
simon

#2 Updated by ftigeot almost 5 years ago

On Mon, Jun 22, 2009 at 07:28:20PM -0700, Matthew Dillon wrote:
> :But then, maybe I'm too much an HAMMER enthusiast, and we should go the
> :Linux route and always install a (UFS) /boot. Then it is also easier to
> :run more complex setups, like vinum, ccd, etc.
> :
> There are a few other things I'd like to get done for this release.
> Sacha has kindly taken on adding a BOOT+HAMMER feature to the
> installer. I will take on fixing up fdisk to handle multi-terrabyte
> disks. Right now it wraps the 32 bit logical block length instead
> of assigning the max value (0xFFFFFFFF), and our slice code in the
> kernel doesn't translate the max-value into the actual disk size
> which makes disklabel believe that the disk is smaller then it actually

What about gpt ? I had the impression it was meant to replace fdisk for big
storage volumes...

#3 Updated by ftigeot almost 5 years ago

On Tue, Jun 23, 2009 at 10:47:56AM -0700, Matthew Dillon wrote:
>
> :What about gpt ? I had the impression it was meant to replace fdisk for big
> :storage volumes...
>
> Many BIOSes (most, probably) do not understand GPT slices and
> can't boot from it.
>
> I'm sure this will change but adoption has been very slow.

I was thinking about gpt(8): the program, not the on-disk structure itself.
It is able to create a special /boot mbr slice for old bioses and still address
more than 2TB for all the rest.

Shouldn't this be used instead of fdisk(8) in the future ?

#4 Updated by dillon almost 5 years ago

:
:New submission from Thomas Nikolajsen <>:
:
:Booting DragonFly from disklabel64 slice has problems:
: - using HAMMER it almost works: one module can't be read
:Reading /modules/acpi.ko fails; after booting (host can run without ACPI)
:(i.e. by kernel) acpi.ko can be read and contents is correct.
:(files on test HAMMER system are just cpdup'ed from a working system;
:cmp verified acpi.ko is readable and has same contents)

It sounds like the hammer fs read code in the boot loader isn't
handling all the cases properly.

:Also doing ls command in loader on HAMMER file system can crash loader.
:It seems like libstand/hammerread has an issue.
:
: - using UFS it doesn't work: I just see a spinning bar
:It doesn't show any text, like BTX..
:
:I had the impression that disklabel64 booting should be working
:(since commits below); is this correct?

UFS should work.

:Is zeroing slice start before making bootable disklabel still needed?
:If yes: is it enough to zero 16KB, like disklabel32.

Zeroing is still needed.

:I was going to update disklabel64.8 to include boot info again;
:but will hold it back until this issue is resolved.

I'm going to be blunt on the HAMMER boot thing... I don't actually
like the idea, because the boot code can't run the UNDO's after a
crash and so might not be able to find the kernel and other boot
related files. I would rather just boot from a small UFS /boot
partition and then have the kernel mount HAMMER as the root.

I guess I'll have to deal with changing the installer to create a
BOOT+HAMMER setup instead of a straight HAMMER setup.

-Matt
Matthew Dillon
<>

#5 Updated by dillon almost 5 years ago

:However so far nobody had problems since we fixed the last bugs. I
:absolutely agree that we should have the boot code reading the UNDO, and
:also multi-volume HAMMER file systems will not work with the boot loader
:(will never). However I think for a simple setup, having just one
:HAMMER file system should be supported and perfectly fine.
:
:But then, maybe I'm too much an HAMMER enthusiast, and we should go the
:Linux route and always install a (UFS) /boot. Then it is also easier to
:run more complex setups, like vinum, ccd, etc.
:
:cheers
: simon

I'm also a bit worried about BIOS addressability with large disks.
If someone installs a terrabyte disk with HAMMER on it, hammerread
might have to access very high numbered sectors. I don't trust the
BIOS to properly use 48-bit sector addressing.

-Matt
Matthew Dillon
<>

#6 Updated by dillon almost 5 years ago

Another interesting issue here which I really think puts the nail in
coffin is that we really want to be able to use more complex access
schemes, such as vinum, for these large filesystems. I don't want to
have to depend on something like the BIOS fake-raid, its just too severely
limiting.

With a small UFS /boot we can make the primary root filesystem whatever
we want... from multi-volume mounts to vinum or any other scheme we
choose, including eventually mounts named by serial number.

The more I think about it, the more I really want us to default to
a small UFS /boot. Here's another example... lets say we wanted to
support encrypted disks. The information on the UFS /boot would not
have to be encrypted per-say, since it's just a tiny boot-only partition
containing no production data. It could, however, contain sufficient
information to allow the system to auto-boot the encrypted root disk.

For example, the /boot booted kernel could query the local environment,
such as the network, and acquire sufficient information to mount its
encrypted root.

--

If we reserved space for a /boot by default on every disk we disklabel,
it could lead to some fairly impressive booting and recovery options.
I'd like it to be the new concept for the 'a' partition. Make 'a'
*always* be a small /boot partition.

-Matt

#7 Updated by dillon almost 5 years ago

:But then, maybe I'm too much an HAMMER enthusiast, and we should go the
:Linux route and always install a (UFS) /boot. Then it is also easier to
:run more complex setups, like vinum, ccd, etc.
:
:cheers
: simon

I think you're more enthusiastic about a HAMMER-only install then I
am :-). To me, UFS1 is a perfectly fine filesystem... for small
partitions. There's no reason to throw it away.

The biggest problem I see with trying to put too much intelligence in
the boot code is simply that there is no way for it to keep up with
the kind of intelligence we can put into the kernel. It's a lot easier
to implement new and cool filesystem / mounting / vinum / etc features
with a full-fledged kernel running.

The partition naming scheme also looks a lot more natural if we make
'a' the small boot partition, leave 'b' as swap, and make 'd' the
root mount and rest of the disk (for a BOOT+HAMMER install). That way
swap space can stay on the much higher bandwidth outer rim of the disk
without us having to intentionally mis-order the partition offsets.

There are a few other things I'd like to get done for this release.
Sacha has kindly taken on adding a BOOT+HAMMER feature to the
installer. I will take on fixing up fdisk to handle multi-terrabyte
disks. Right now it wraps the 32 bit logical block length instead
of assigning the max value (0xFFFFFFFF), and our slice code in the
kernel doesn't translate the max-value into the actual disk size
which makes disklabel believe that the disk is smaller then it actually
is. This doesn't matter so much for add-on disks but it does for
boot disks where the BIOS is expecting a slice table, yet we want the
disklabel to be able to make full use of the actual size of the disk.

-Matt
Matthew Dillon
<>

#8 Updated by dillon almost 5 years ago

:What about gpt ? I had the impression it was meant to replace fdisk for big
:storage volumes...
:
:--
:Francois Tigeot

Many BIOSes (most, probably) do not understand GPT slices and
can't boot from it.

I'm sure this will change but adoption has been very slow.

-Matt
Matthew Dillon
<>

#9 Updated by dillon almost 5 years ago

:On Tue, Jun 23, 2009 at 10:47:56AM -0700, Matthew Dillon wrote:
:>
:> :What about gpt ? I had the impression it was meant to replace fdisk for big
:> :storage volumes...
:>
:> Many BIOSes (most, probably) do not understand GPT slices and
:> can't boot from it.
:>
:> I'm sure this will change but adoption has been very slow.
:
:I was thinking about gpt(8): the program, not the on-disk structure itself.
:It is able to create a special /boot mbr slice for old bioses and still address
:more than 2TB for all the rest.
:
:Shouldn't this be used instead of fdisk(8) in the future ?
:
:--
:Francois Tigeot

It has a mbr compat feature but BIOSes often can't deal with it. i.e.
it isn't as compatible as was originally intended.

-Matt
Matthew Dillon
<>

#10 Updated by thomas.nikolajsen over 1 year ago

  • Status changed from New to Resolved
  • Assignee deleted (0)

(don't remember why I kept this one open)

Also available in: Atom PDF