Date: Mon, 17 Apr 2023 13:46:32 +0200 From: Polytropon <freebsd@edvax.de> To: freebsd@dreamchaser.org Cc: John Levine <johnl@iecc.com>, freebsd-questions@FreeBSD.org Subject: Re: frequent disk error, need guidance Message-ID: <20230417134632.570f53b7.freebsd@edvax.de> In-Reply-To: <5793cdd5-c365-7769-49e9-366cb367a8a0@dreamchaser.org> References: <20230415204721.DD803BF2E2EA@ary.qy> <5793cdd5-c365-7769-49e9-366cb367a8a0@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Apr 2023 18:50:41 -0700, Gary Aitken wrote: > On 4/15/23 13:47, John Levine wrote: > > It appears that Gary Aitken <freebsd@dreamchaser.org> said: > >> of fbsd in such cases), wanted to see if the following is a good way > >> to copy the old disk to the new one. > >> > >> mount /dev/ada1p2 /mnt/newsys > >> cd /mnt/newsys > >> dump -0 -f - /dev/ada0p2 | restore -r -Dv -f - > >> > >> However... this is a running system, which seems unlikely to produce > >> a consistent result. > > > > I'd shut down to single user, make a /.snap directory, and do dump -L > > to tell it to make a snapshot before dumping. That should work OK. > > Thanks. > (Needed to mount /tmp read-write) > The -L didn't work because boot -s mounted the filesystem read-only; > at least that's what it claimed: > > dump -0 -L -f - /dev/ada0p2 | restore -r -Dv -f - > Verify tape and initialize maps > DUMP: WARNING: -L ignored for read-only filesystem That is correct: -L is used to make a "runtime snapshot" of a filesystem that could be subject to changes, i. e. to writes. > Not sure I understand that; > does -s normally start in read-only mode? Yes. Single-user mode starts the system with the root partition / mounted read-only, and all other partitions not mounted at all. If you have "one big /", this will also apply. If you have separate /tmp, /var, /usr, /opt, /home etc. partitions, you need to fsck and then mount them manually, after "mount -wu /". > Has it always done that? It's been quite a while since I did that. Yes, as far as I remember, and I remember since 4.0. ;-) > In any case, I let the dump|restore go through, and it seems to have > been successful. Booted into the restored system and running it now; > smartctl short test ok and doing long now. Excellent! > It looks like the bad blocks/sectors were files in > /var/db/freebsd-update/files/xxx.gz > I unzipped a file in that directory and it appears that they are the > saved files from the old system when upgrading. Is that correct? > Any reason not to remove all files in > /var/db/freebsd-update/files > since the upgraded to 12.x system has been running for several months > now? Those seem to be temporary files belonging to the updating program. There's probably nothing wrong with deleting them, as if they are needed, then freebsd-update would fetch or generate them anyway. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230417134632.570f53b7.freebsd>