Opened 9 years ago

Closed 8 years ago

#12290 closed bug (fixed)

recent nightlies can no longer read BFS of older nightlies

Reported by: taos Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Partitioning Systems/Intel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by pulkomandy)

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: DriveSetup from hrev49191. checkfs shows no errors for /Haiku Relase and /Haiku Nightly.

With "Nightly", DriveSetup shows no file system for "Release" disk: DriveSetup from hrev49500 ("Nightly"). {{{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.

Attachments (10)

DriveSetup_hrev49191_release.png (62.7 KB ) - added by taos 9 years ago.
DriveSetup from hrev49191.
DriveSetup_hrev49500_nightly.png (65.5 KB ) - added by taos 9 years ago.
DriveSetup from hrev49500 ("Nightly").
hrev49191_release.img (1.0 MB ) - added by taos 9 years ago.
First MB of "Release".
hrev49500_nightly.img (1.0 MB ) - added by taos 9 years ago.
First MB of "Nightly".
syslog_release.txt (159.8 KB ) - added by taos 9 years ago.
Syslog from "Release".
syslog_release.2.txt (159.8 KB ) - added by taos 9 years ago.
Syslog from "Release".
syslog_nightly.txt (156.5 KB ) - added by taos 9 years ago.
Syslog from "Nightly".
release_last1M.img (1.0 MB ) - added by taos 8 years ago.
Last MB of release disk via 'tail -c 1M'.
fdisk.txt (561 bytes ) - added by taos 8 years ago.
Output of 'fdisk' for release disk under linux.
cgdisk.txt (310 bytes ) - added by taos 8 years ago.
Output of 'cgdisk' for release disk under linux.

Change History (26)

by taos, 9 years ago

DriveSetup from hrev49191.

by taos, 9 years ago

DriveSetup from hrev49500 ("Nightly").

by taos, 9 years ago

Attachment: hrev49191_release.img added

First MB of "Release".

by taos, 9 years ago

Attachment: hrev49500_nightly.img added

First MB of "Nightly".

by taos, 9 years ago

Attachment: syslog_release.txt added

Syslog from "Release".

by taos, 9 years ago

Attachment: syslog_release.2.txt added

Syslog from "Release".

by taos, 9 years ago

Attachment: syslog_nightly.txt added

Syslog from "Nightly".

comment:2 by pulkomandy, 9 years ago

Description: modified (diff)

comment:3 by diver, 8 years ago

Component: - GeneralPartitioning Systems/Intel

comment:4 by taos, 8 years ago

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?

comment:5 by axeld, 8 years ago

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.

comment:6 by pulkomandy, 8 years ago

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).

comment:7 by axeld, 8 years ago

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.

comment:8 by pulkomandy, 8 years ago

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.

comment:9 by axeld, 8 years ago

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.

comment:10 by pulkomandy, 8 years ago

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.

in reply to:  5 comment:11 by taos, 8 years ago

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.

by taos, 8 years ago

Attachment: release_last1M.img added

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

comment:12 by taos, 8 years ago

patch: 01

Is there a way to remove "Has a Patch set"?

Last edited 8 years ago by taos (previous) (diff)

by taos, 8 years ago

Attachment: fdisk.txt added

Output of 'fdisk' for release disk under linux.

by taos, 8 years ago

Attachment: cgdisk.txt added

Output of 'cgdisk' for release disk under linux.

comment:13 by pulkomandy, 8 years ago

patch: 10

comment:14 by axeld, 8 years ago

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

comment:15 by pulkomandy, 8 years ago

Please try with hrev51114.

comment:16 by taos, 8 years ago

Works for me with hrev51115 gcc2 hybrid.

comment:17 by pulkomandy, 8 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.