From nobody Sat May 18 17:53:21 2024 X-Original-To: freebsd-hackers@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 4VhWmm1J3kz5LDCG for ; Sat, 18 May 2024 17:59:20 +0000 (UTC) (envelope-from anonloli@autistici.org) Received: from devianza.investici.org (devianza.investici.org [198.167.222.108]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VhWml42jVz4RM1 for ; Sat, 18 May 2024 17:59:19 +0000 (UTC) (envelope-from anonloli@autistici.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=autistici.org header.s=stigmate header.b=R1HJxfUj; dmarc=pass (policy=reject) header.from=autistici.org; spf=pass (mx1.freebsd.org: domain of anonloli@autistici.org designates 198.167.222.108 as permitted sender) smtp.mailfrom=anonloli@autistici.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=autistici.org; s=stigmate; t=1716054837; bh=j/1WOnddp5oPiQhXENhSJzrMjh2CNKAOlIoXkbefPd0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=R1HJxfUjnZBqC/fFZkdFGjz34fqDvfvzCkJVL/5iHscaYOEr5dJddB6Za4siEYxcD HHfhnPMC4MM12JY6rta0pqfg4+55G1BLpOaZfyBdfta94t6RO106OOhtv+99LsFMVX /wn5KF5FJ4xy1EBJ2NGKe+q1GwocZ1WQIiufP2i8= Received: from mx2.investici.org (unknown [127.0.0.1]) by devianza.investici.org (Postfix) with ESMTP id 4VhWfY1xWnz6xbN for ; Sat, 18 May 2024 17:53:57 +0000 (UTC) Received: from [198.167.222.108] (mx2.investici.org [198.167.222.108]) (Authenticated sender: anonloli@autistici.org) by localhost (Postfix) with ESMTPSA id 4VhWfX4d7Bz6xbM for ; Sat, 18 May 2024 17:53:56 +0000 (UTC) Date: Sat, 18 May 2024 17:53:21 +0000 From: Anon Loli To: freebsd-hackers@freebsd.org Subject: Re: GELI disk corrupted or external influence? Message-ID: References: <1716050202-69054-mlmmj-647e0ac8@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: + X-Spamd-Result: default: False [1.30 / 15.00]; MID_END_EQ_FROM_USER_PART(4.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[autistici.org,reject]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[autistici.org:s=stigmate]; R_SPF_ALLOW(-0.20)[+ip4:198.167.222.108:c]; RCVD_IN_DNSWL_LOW(-0.20)[198.167.222.108:received,198.167.222.108:from]; MIME_GOOD(-0.10)[text/plain]; GREYLIST(0.00)[pass,body]; DKIM_TRACE(0.00)[autistici.org:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:39287, ipnet:198.167.192.0/19, country:FI]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4VhWml42jVz4RM1 Yeah I did just that, I did `zpool export [zfs pool]` and ran `gpart show /dev/ada0.eli`, and it tells me this: > gpart: No such geom: /dev/ada0.eli.` so I guess this is what you meant by the partition table? In any case, a zpool scrub should be useful in this case? Maybe I'm doing it wrong? Anyways thanks for your response. The reason I'm leaving FreeBSD is that it's full of bugs including but not limited to filename handling by ls/cd (specifically some encoding like Swedish encoding or something couldn't handle the weird letters) and ports, I couldn't get them to work after an upgrade, perhaps I didn't do something correctly, everything was broken and I decided to switch to OpenBSD, in where it's much better.. Don't get me wrong for something like gaming and lazy/irresponsible storage usecases FreeBSD is alright, but OpenBSD just feels right.. Also FreeBSD crashes as-in reboots the entire PC if the HDMI cable of one of displays I tested is inserted only half-way. On Sat, May 18, 2024 at 01:18:38PM -0400, Karl Denninger wrote: > Gpart on the raw device, if you do the whole device, will not show anything > until and unless you attach it at which point "gpart show" on the ".eli" > device will work. > > But its entirely possible the other OS scribbled on some number of the first > few blocks, in which case you may be utterly boned as even IF you restore > the metadata its highly-probable the data has been severely damaged.  You > can try it (and I would certainly), but you may be screwed. > > IF you can get Geli to attach it then a "gpart show /dev/ada0.eli"  SHOULD > show the structure -- assuming gpart can find a usable partition table. > > I am not a fan of using geli on the whole disk for this exact reason; > another OS is very likely to assume the disk is not formatted AT ALL because > it does not see a partition table signature and in some cases it might > gratuitously write to it and you might either (in confusion) approve it or > worse, it might not even ask!  You'd hope nobody would design something in > an OS that is that THAT dumb but..... > > On 5/18/2024 12:59, Anon Loli wrote: > > Hello mailing list! > > I've had an event which includes modifying some BIOS settings (can't > > remember which exactly), and testing some OS other than FreeBSD. > > > > And I think that the said OS did something malicious to the disk in > > question because it has been doing it for prolonged period of time, and > > mentioned disks.. > > > > So this was all on same machine, like dual-booting but from another > > drive. > > > > Then when I went back into FreeBSD I noticed an error, `geli attach` > > doesn't work, I used a /etc/rc.local script for the GELI disk like so: > > `geli attach -p -k /etc/diskpassword.key /dev/ada0 > > zpool import zmedia` > > I get an error message when I try to run the geli command: > > > geli: Cannot read metadata from /dev/ada0: Invalid argument. > > I have /var/backupts/ada.eli if that can help.. > > There's only /dev/ada0, no ada0s1 for example or .eli or whatever.. > > Also when running `gpart show`, I see 2 disks: > > xxx GPT (main boot drive) > > freebsd-boot > > freebsd-swap > > freebsd-zfs > > > > and > > ada0 GPT (the drive in problem) > > -free- (everything) > > > > > > Does this indicate that everything has been lost, like the partitioning > > table or whatever you call it, like it has been formatted? > > Did the other evil OS-fucker destroy my disk without saying it would do > > that? > > > > > > If you can't tell, I'm hesitant to give more information than what's > > necessary for someone to help me because almost any data can be used to > > deanonymize someone, but if you do need some information, please feel > > free to ask. > > > > > > TL;DR: some OS could have wiped some part of a FreeBSD-zfs drive, can > > you help me conclude wether or not we can somehow save it? > > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/