From nobody Fri Jan 26 20:01:54 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 4TM7rQ0Bmsz58kjg for ; Fri, 26 Jan 2024 20:01:58 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TM7rP5WRvz4DqF; Fri, 26 Jan 2024 20:01:57 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706299317; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gko2uFZsDrfARZt+oxRevf5SNSLqj0Kcnp1aNIXjnvU=; b=RPXIGhDExzAUTLgnXm332na35N51qS+2aU5f0vZ8RjpfNQu+DbX+vp9NuUvroeH8iGcQav QdrofJ75Kn0RJDc+4c40SECwWdSkm5g15j68nawcqF/sRM1Qmj6cdqsEaxr5tHCQxYubPe htOACnpVkbbOwvr1YLNslMze1cfKifqNqCjJojViKrJijBwnYDuYSY3XGNoDaM2wj7cbte 8lXIHAZLXPNWok3sIJF/5sGVBo8f8/o1/meek94bfAt1Ox7J2OVbOytRd3myuzJBVZOM1g XEoVRnA2bu6zHVi1yTDU2MMDn3OF0H2Z/wShcWN9i1CwCVoQXYFMoJ8Gxh4R2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706299317; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gko2uFZsDrfARZt+oxRevf5SNSLqj0Kcnp1aNIXjnvU=; b=e2Y3bzMy5VIhv4eZbewrrX4xYizNjgqL1YrZp2bVtEU17LE3PwtmK/zPvXWyKeBxszDtXF qZUTc+PzL/xSLWBhNHuukyZ2R9Kklkkyr5bx20uL+Eb+ZBgm9NznZEFrUr1+CDrJPZ2wEh 23aSw9M5UgIKHiDiNFBpTjPwyGUyws1x4vWdnC43Nkiy/aCd+dZjzBJ54cmrk78HuCA6vc EoLG3nALZnv8FSykFRJDmbJig2nPt5FSLd2LP4XvJCUOwIpjZzOVGZ9L1t2eVWkwX4vBGC Lmimd2DlVTESXFlAVs2IQc0NfIkTGI6aZKZ/0J/jdXqikC5WQS+WxualQtzTWA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706299317; a=rsa-sha256; cv=none; b=q7ePB+EQuPD14hFO9HHo91/xh/2p3i6ZddyDwuBDo/J7EmXWmTa8wvVBCfkZwb6uPjsjHZ 78Z1VPzl2hpgwaFnJ02O8zDpK4v2Gs0luy32ypIex/+cYszyyh1L4fs5M1GhYdrhdYjF53 Y0J6H4MOnCYfQEZRUU6huOgAnQhdFDtn+xlnWIg+6dPx71SWTMq2j2Ym/XmaqvbysSdvRc 8ihl9iEyTcf5R5m+vqPeEVrfOc5wJp6hSq1LAeX1d7EqH/TKn8Ydx9xFBVZZRHOsy+20An N6kvISm77Xr4dpVy4CLxJXkwG6VmW2KelMlQcLENrPLk3edJ0ZisvNOtKDaG7A== Received: from [IPV6:2003:cd:5f2c:9d00:b5c6:f2af:6888:1ab7] (p200300cd5f2c9d00b5c6f2af68881ab7.dip0.t-ipconnect.de [IPv6:2003:cd:5f2c:9d00:b5c6:f2af:6888:1ab7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TM7rN74FPzdS8; Fri, 26 Jan 2024 20:01:56 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Fri, 26 Jan 2024 21:01:54 +0100 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 User-Agent: Mozilla Thunderbird From: Stefan Esser Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) Content-Language: de-DE To: "Rodney W. Grimes" Cc: Ed Maste , Warner Losh , FreeBSD CURRENT References: <202401261609.40QG9th8006226@gndrsh.dnsmgr.net> In-Reply-To: <202401261609.40QG9th8006226@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 ...) > 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. 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), end-CHS (0x3ff,255,63), startsector 1, 1953525167 sectors, extended partition table (last) Do you need more information from the protective MBR? 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 ... >> 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? >> 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? 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. If you want such consistency checks added, then specify them in a feature request PR, for example. Best regards, STefan