recent nightlies can no longer read BFS of older nightlies

[taos]

Using hrev49500 gcc2hybrid.

I have two sd cards with Haiku installed (both don't have partitions, whole disk is used): 1.) "Nightly": regularily updated via pkgman (since 47784), at the moment at hrev49500, german localization 2.) "Release": regularily installed from self-built raw images (built on "Nightly") with Installer, at the moment at 49191

Data on both disks can be read with linux. I can boot Haiku from both disks.

When I tried to update my "Release" disk with a new raw image, I was very confused because I could no longer mount it from "Nightly".

With "Release", DriveSetup shows all disks and partitions: checkfs shows no errors for /Haiku Relase and /Haiku Nightly.

With "Nightly", DriveSetup shows no file system for "Release" disk: {{{checkfs}} shows no error for /Haiku Nightly, but displays the following error message for the "Release" disk (/dev/disk/usb/0/0/raw): checkfs: The disk system does not support repairing.

I've copied the first MB of both disks with dd. Image files are attached.

After checking the old states that I can still boot from on my "Nightly" installation, it seems that hrev49371 can still read the file system of "Release", whereas hrev49474 can't.

This might be related: A week ago, I also lost a 64bit installation on SD card (this time with one partition and BootManager) when updating via pkgman from 489xxx to 494xx. The partition could still be read from linux (always thought it was GPT, but linux told me later it was MBR when I tried to inspect it with cgdisk). Haiku BootManager, however, couldn't load any Haiku partitions. I could access Haiku boot menu with shift key, but there was no bootable Haiku partition to choose from. Unfortunately, I just reformatted the disk and installed again from anyboot image so it's no longer available for testing.

[taos]

DriveSetup from hrev49191.

[taos]

DriveSetup from hrev49500 ("Nightly").

[taos]

First MB of "Release".

[taos]

First MB of "Nightly".

[taos]

Syslog from "Release".

[taos]

Syslog from "Release".

[taos]

Syslog from "Nightly".

[taos]

I was thinking about reformating the "Release" microsd card to install self-built raw images again (or to try a pkgman update to see if you could still boot from it afterwards). Is someone still interested in me keeping the microsd card as it is for further testing?

[axeld]

It looks like the nightly identifies the disk as EFI GPT disk instead of as BFS. The SD card has not partition table but has been formatted directly with BFS, I guess? I haven't yet looked into why the GPT add-on thinks it's his, but have the SD card ever been initialized with GPT before?

In that case, it would be interesting to get the last MB of the drive, too; it might still sport the backup GPT header which the add-on detects and claims.

[pulkomandy]

I can confirm that the GPT add-on will claim volumes even if only the end header (footer?) is present. I am actually using one of my systems like this, as I have bootman at the start of the drive (which erased the initial GPT) and a GPT table at the end (yes, dangerous setup).

[axeld]

I guess we could lower the score if only the end header is found, so that other file or partitioning systems win if they also match.

Also, we should implement (I don't think that has been done yet), a proper uninitializing of file and partitioning systems.

[pulkomandy]

The GPT can be uninitialized now, and DriveSetup does call this code if it can still identify a GPT volume. However, I don't think mkbfs, or even worse, dd of an haiku image onto an USB stick or sd card, will get any help from that.

[axeld]

Ah, great! mkfs could actually do this, since it's using the disk device manager to carry out its task anyway. If you're using dd, you're on your own anyway.

Changing the priorities to improve the situation could prove to be problematic:

• GPT always returns 0.96 in order to override Intel in case of an existing compatibility MBR.
• BFS always returns 0.8
• Intel returns either 0.81 when there are children (in order to override BFS), or 0.5 if not.

So having GPT greater than Intel, and Intel greater than BFS, and BFS greater than GPT sounds impossible :-) I think the only way we could improve the situation is to lower the GPT score to 0.75 if there is only the end header accessible. However, this would probably hinder your use case.

[pulkomandy]

I think my use case would work no matter wat. The start of my disk is the bootman code with nothing around (no MBR, no BFS header). So the other add-ons shouldn't detect anything.

I should fix bootman so it can be installed properly on GPT systems however (the way GRUB does it: in a small partition of type "bootloader"). We need an appropriate bootsector code for this to work however.

[taos]

Replying to axeld:

It looks like the nightly identifies the disk as EFI GPT disk instead of as BFS. The SD card has not partition table but has been formatted directly with BFS, I guess?

Yes.

I haven't yet looked into why the GPT add-on thinks it's his, but have the SD card ever been initialized with GPT before?

I can't remember (maybe if you had asked 1.5 years ago) doing that. However, since cgdisk in Linux also thinks there might be a damaged GPT backup header, it's possible. On the other hand, fdisk now doesn't complain that it's a GPT disk, so the old GPT partition map at the beginning of the disk was probably overwritten before I initialized the disk with Intel Partition Map to install Haiku.

In that case, it would be interesting to get the last MB of the drive, too; it might still sport the backup GPT header which the add-on detects and claims.

I've attached the output of tail -c 1M as release_last1M.img. I hope that's sufficient.

[taos]

Last MB of release disk via 'tail -c 1M'.

[taos]

Output of 'fdisk' for release disk under linux.

[taos]

Output of 'cgdisk' for release disk under linux.

[axeld]

Confirmed that there is a EFI GPT header at the end of the drive.

[pulkomandy]

Please try with hrev51114.

[taos]

Works for me with hrev51115 gcc2 hybrid.