Labeled Filesystems: partition end offset problem

[Juanitou]

Hi!

I don’t know if this issue deserves a thread, since I haven’t found a lot of references to other people having it, but maybe it could help somebody in the future.

The initial situation: I want to add a second hard disk to my old desktop box. I follow both of these guides:
Disk Setup On FreeBSD (Warren Block)
Create MBR slices/partitions and filesystems (Ross at daemon-notes.com)

I follow the recommendations of these guides:

MBR partitioning schema > FREEBSD partition > BSD partitioning schema > FREEBSD-UFS partition

all goes well but an error appears at boot time (verbose):

GEOM_PART: partition 1 has end offset beyond last LBA: 321672896 > 321672895
GEOM_PART: integrity check failed (label/backup, BSD)

Then I read [post=163078]in this thread[/post] (please correct me if wrong) that GEOM metadata is stored at the end of the drive, so I try to recreate the partition with a smaller size (-63 logical blocks), with no avail: the partition end offset still goes beyond last LBA.

Well, what is inside this last LBA, the filesystem label? I don’t need it, so I proceed to repeat the whole process but without issuing the glabel command and bingo! No more offset errors!

I’m so surprised nobody has complained about this that I guess the problem lies within the old BIOS of this motherboard, which hangs while recognizing drives unless I instruct it to [post=197395]use the Large access method[/post], but then, this second drive didn’t provoked the hang when I first installed it from another computer, with an MBR scheme created by Windows XP. As soon as I destroyed and created again the MBR with FreeBSD, the computer refused to boot.

Too niche to file a PR? Too long to bother reading it? :r I hope at least it saves somebody the hassle when trying to resurrect old hardware.

Best regards,
Juan

PS: Wouldn’t the integrity check failure prevent the mounting of a root filesystem, as the one described in @wblock@ article?

 

[wblock@]

Please show exactly what you did. If the system won't boot, boot mfsBSD and show the output of gpart show.

GEOM classes usually do put metadata at the end of the drive or partition. But you don't show what you used.

Oh, and I recommend the much simpler and more powerful GPT unless the use of the old MBR/BSDlabel partitions-in-partitions format is required.

 

[Juanitou]

Sorry, I have mixed two issues here: the hang while booting is resolved by changing the access method for the IDE channel in the BIOS (Auto -> Large). The disk MBR-partitioned by Windows XP did not produce the hang, it's only when I recreated it in FreeBSD after destroying the whole schema that I saw it and remembered the old thread quoted in the previous post. I disconnected the drive, rebooted, changed the BIOS setting, then connected it again. I consider it solved.

Concerning the labels, I followed almost literally the daemon-notes article (as yours is for boot partitions). I started by deleting/destroying the old MBR schema, don’t remember the details but it worked (the geom disappeared from gpart show output), then:

# gpart create -s mbr ada1
# gpart add -t freebsd ada1
# gpart create -s bsd ada1s1
# gpart add -t freebsd-ufs ada1s1    // Whole disk
# glabel label data0 /dev/ada1s1a
# newfs -U -L data0 /dev/label/data0
# mkdir /data
# mount /dev/ufs/data0 /data

Add entry to /etc/fstab:

# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/ufs/data0          /data           ufs     rw              2       2

Upon reboot, and after correcting the hang problem in the BIOS, I remarked the GEOM_PART integrity check / partition offset error, which not prevented the system to happily start and the file system to mount and be usable. As I had the time to dig into this error, I repeated the process but without creating the label:

...snip...
[DEL]# glabel label data0 /dev/ada1s1a[/DEL]
# newfs -U [DEL]-L data0 /dev/label/data0[/DEL] /dev/ada1s1a
...snip...

Without the label, the GEOM_PART errors are gone.

I have only found this thread that maybe explains why there is an offset, but it does not provide a solution. I have not found related Problem Reports.

I will surely test the GPT partitioning in the future, that could shed some light on the hang issue. Nevertheless, is MBR and labels that seem to not work here, even if it has no importance.

Thanks for your attention.

 

[wblock@]

Concerning the labels, I followed almost literally the daemon-notes article (as yours is for boot partitions). I started by deleting/destroying the old MBR schema, don’t remember the details but it worked (the geom disappeared from gpart show output), then:

# gpart create -s mbr ada1
# gpart add -t freebsd ada1
# gpart create -s bsd ada1s1
# gpart add -t freebsd-ufs ada1s1    // Whole disk
# glabel label data0 /dev/ada1s1a
# newfs -U -L data0 /dev/label/data0
# mkdir /data
# mount /dev/ufs/data0 /data

That is needlessly complicated to create a single partition that fills the whole disk.

# gpart create -s mbr ada1
# gpart add -t freebsd-ufs ada1
# newfs -U -L data0 /dev/ada1s1

Add entry to /etc/fstab:

# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/ufs/data0          /data           ufs     rw              2       2

You created both a filesystem label and a glabel(8), which is unnecessary. And confusing, since they have the same name. Don't give labels the same name, even on different disks.

I have only found this thread that maybe explains why there is an offset, but it does not provide a solution. I have not found related Problem Reports.

It is not a problem except in user perception. Creating a glabel(8) takes one block from the raw device. The /dev/label/labelname device is one block smaller, and that device is the one to use with newfs(8) and other commands. It works, but is more work than using GPT or filesystem labels.

I will surely test the GPT partitioning in the future, that could shed some light on the hang issue. Nevertheless, is MBR and labels that seem to not work here, even if it has no importance.

They work. It's easy to make a mistake when combining them with multiple forms of partitioning.

GPT makes this far easier:

# gpart create -s gpt ada1
# gpart add -t freebsd-ufs -l data0 ada1
# newfs -U /dev/gpt/data0

That's it, all of it. Use /dev/gpt/data0 in /etc/fstab.

 

[Juanitou]

That is needlessly complicated to create a single partition that fills the whole disk.

:x I think I understand now. Why add the BSD schema if you want to use the whole disk, isn’t it? Unfortunately:

# gpart destroy -F ada1s1
ada1s1 destroyed
# gpart destroy -F ada1
ada1 destroyed
# gpart show ada1
gpart: No such geom: ada1.
# gpart create -s mbr ada1
ada1 created
# gpart add -t freebsd-ufs ada1
gpart: Invalid argument

This error explains why I created the FREEBSD schema inside the first slice to then create a unique FREEBSD-UFS partition.

You created both a filesystem label and a glabel(8), which is unnecessary. And confusing, since they have the same name. Don't give labels the same name, even on different disks.
…
They work. It's easy to make a mistake when combining them with multiple forms of partitioning.

:OO I blindly followed the above mentioned guide. Now I see that they are two different labels. I should prevent the person who wrote this guide…

GPT makes this far easier:

# gpart create -s gpt ada1
# gpart add -t freebsd-ufs -l data0 ada1
# newfs -U /dev/gpt/data0

That's it, all of it. Use /dev/gpt/data0 in /etc/fstab.

This worked perfectly! Finally, the motherboard seems to supports GPT, good to know at last.

Thanks a lot for your time, most appreciated.

Best regards,
Juan

 

[wblock@]

:x I think I understand now. Why add the BSD schema if you want to use the whole disk, isn’t it? Unfortunately:

# gpart destroy -F ada1s1
ada1s1 destroyed
# gpart destroy -F ada1
ada1 destroyed
# gpart show ada1
gpart: No such geom: ada1.
# gpart create -s mbr ada1
ada1 created
# gpart add -t freebsd-ufs ada1
gpart: Invalid argument

That may have to be freebsd rather than freebsd-ufs:

# gpart add -t freebsd ada1

Still, GPT is better.