From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 640D1138350 for ; Thu, 30 Apr 2020 20:48:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6ACB2E0993; Thu, 30 Apr 2020 20:47:56 +0000 (UTC) Received: from coleridge.oriole.systems (coleridge.oriole.systems [IPv6:2a00:1828:2000:35::dece:a5ed]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0E589E08A0 for ; Thu, 30 Apr 2020 20:47:56 +0000 (UTC) Date: Thu, 30 Apr 2020 22:47:54 +0200 From: Wynn Wolf Arbor To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Trouble with backup harddisks Message-ID: <20200430204754.hyh2xzeovsj23xdl@nabokov.fritz.box> Mail-Followup-To: Wynn Wolf Arbor , gentoo-user@lists.gentoo.org References: <20200430093217.efprkpt4kbvir7nr@solfire> <5EAAA0AB.3050505@youngman.org.uk> <22faa7cf-7291-b430-c646-b96c6d428f19@alyf.net> <20200430180839.iz4kxipst2i5stwp@solfire> <20200430192713.ptlo7crtwvskse7n@nabokov.fritz.box> <34ab0115-9336-ad41-5d30-7c8ce6ff1210@alyf.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <34ab0115-9336-ad41-5d30-7c8ce6ff1210@alyf.net> X-Archives-Salt: dde61667-627e-491b-9438-ce4c8273b535 X-Archives-Hash: 62227f60c83b8bb0ffaa3d89cd105492 On 2020-04-30 22:21, Andrea Conti wrote: >It won't, as long as it recognizes it as a protective MBR. Which is the >right thing to do, as a disk with a protective MBR and no valid GPT is >inherently broken. True. It was more my intention to depict what the system "should" do in order to access the file system. >... or just bypass the partition table altogether. The filesystem >starts at sector 1, i.e. 1*512B, so: > >mount -o ro,offset=512 /dev/sdb /mnt/xxx Interesting, thanks. I was initially considering something like this myself, but after a cursory check of the manual, I was under the assumption that 'offset' was only valid with loop devices and dismissed that solution. Turns out if you mount a drive like this, the kernel uses a loop device in the background and you can use the 'offset' option with block devices as well. I feel the documentation could be improved here. -- Wolf