From nobody Fri Jan 26 21:26:20 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TM9k1514jz58sTZ for ; Fri, 26 Jan 2024 21:26:33 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TM9k12y6pz4V4r; Fri, 26 Jan 2024 21:26:33 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 40QLQKH8007098; Fri, 26 Jan 2024 13:26:20 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 40QLQKKO007097; Fri, 26 Jan 2024 13:26:20 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202401262126.40QLQKKO007097@gndrsh.dnsmgr.net> Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) In-Reply-To: To: Stefan Esser Date: Fri, 26 Jan 2024 13:26:20 -0800 (PST) CC: "Rodney W. Grimes" , Ed Maste , Warner Losh , FreeBSD CURRENT X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4TM9k12y6pz4V4r X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] > Am 26.01.24 um 17:09 schrieb Rodney W. Grimes: > >> Am 25.01.24 um 16:38 schrieb Ed Maste: > >>> On Wed, 24 Jan 2024 at 12:30, Warner Losh wrote: > >>> sbin/growfs/tests/legacy_test.pl > >>> tools/regression/msdosfs/msdosfstest-2.sh > >>> tools/regression/tmpfs/t_vnd > >>> tools/tools/nanobsd/legacy.sh > > All these scripts that currently depend on bsdlabel could > easily be converted to exclusively use gpart instead. > > Other scripts that had been identified to use bsdlabel or > disklabel are unused / not relevant for FreeBSD. > > [...] > >> The bsdlabel/disklabel/fdisk programs could be rewritten using > >> gpart without too much effort, at least for the use cases that > > After looking at the source code it appears that there is > no need to rewrite any of the bsdlabel/disklabel code, since > it already uses geom calls to access the partition data and > only uses direct disk writes to write out the partition table > (as does gpart, AFAICT). > > So, I do not see any dependencies on deprecated kernel features. > > I have not compared the bsdlabel code and gpart_write_partcode() > in detail, but I do not see much of a difference at first glance. > > Therefore, bsdlabel and disklabel could be kept in the base > system, IMHO. (But fdisk should go ...) I still have not seen anything compelling that says fdisk must go, other than someone says there is a PR and I am not sure how a bug fix effects the position of fdisk in or out of base as the bug needs fixed regardless. > > > That would be wonderful. Even just getting it to spit out > > the FULL MBR values that are in a protective 0x238 MBR > > would go along way to diagnose some corrupt GPT disks. > > If you need access to the protective MBR of a GPT partition, > this feature should be added to gpart instead, IMHO. I am fine with that too, probalby 99% of my use case is just a sanity check that the MBR/PMBR is not messed up, but that 1% case when it is one needs a way to deal with it very carefully. > > But what's wrong with using "file -s" for this purpose: > > # file -s /dev/nda0 > /dev/nda0: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), ^sic > end-CHS (0x3ff,255,63), startsector 1, 1953525167 sectors, extended partition ^sic > table (last) Other than the sick mixing of hex and decimal output I suppose that does infact get the :reading: of the MBR/PMBR to validate there isnt an issue. Its the repair work when those values are nonsince I do not seeing file(1) fixing. > > Do you need more information from the protective MBR? I think that is all the information, same as output by fdisk, just in a different and very hard to read format. > > This will not work on mounted file systems, though. But if > you got the disk mounted, I'd expect you do not really need > this information ... Correct > > >> have not become obsolete (e.g. CHS specifications) and only for > >> use in scripts (i.e. no fdisk interactive edit mode). > > > > You are fooling yourself if you think an MBR and CHS values > > are obsolete. GPT *IS* a type 0x238 MBR and see how many > > BIOSes you can crash by writting garbage (Especially 0x0) > > to the CHS values. That MBR must have proper values, and > > you cant just ignore that they exist. > > Again something that gpart should be able to diagnose and fix. > > Doesn't "gpart recover" already fix such protective MBRs? I do not know for certain, but I think mainly "gpart recover" is about fixing the 2 copies of the GPT to be consistant, can it actually reconstuct a toasted PMBR? It would be making assumptions so I would expect to have to use some options to force it to do this. > >> Even parsing of the disktab format and a conversion to gpart > >> backup format for use by gpart restore should not be too hard. > >> > >> That would keep the commands available for those that use them > >> in scripts outside the FreeBSD sources, but would also allow to > >> remove the kernel interfaces used by those legacy tools. > >> > >> I'd be willing to write those emulations of legacy tools, if > >> there is interest in going that way ... > > > > I would be interested in seeing these. > > For me gpart does do a lot of things, but it is missing > > some very low level stuff that is probably should have. > > I read that to mean that gpart is useful for standard setup > operations, but it lacks commands that might be useful to > diagnose inconsistent parameters? Yes, like a disk with a zapped PMBR just shows up as empty, nothing, fully ready to let gpart slice and dice it up until you realize.. uh oh, that wasnt the drive I thought it was.... > > Well, adding consistency checks and warning about potential > issues might not have been on the requirements sheet, but if > you specify checks that should be performed, these could be > added either to "gpart show" or a "gaprt check" command could > be implemented. I think geom layer already does the checks, and if you fail the checks you get a nice "empty" drive. "gpart check" could be interesting. > If you want such consistency checks added, then specify them > in a feature request PR, for example. > Best regards, STefan > > -- Rod Grimes rgrimes@freebsd.org