On Fri, March 10, 2017 11:57, m.roth at 5-cent.us wrote:> > Looks like only one sector's bad. Running badblocks should, > I think, mark that sector as bad, so the system doesn't try > to read or write there. I've got a user whose workstation has > had a bad sector running for over a year. However, if it > becomes two, or four, or 64 sectors, it's replacement > time, asap. > <snip>Bear with me on this. The last time I did anything like this I ended up having to boot into recovery mode from an install cd and do this by hand. This is not an option in the present circumstance as the unit is a headless server in a remote location. If I do this: echo '-c' > /fsckoptions touch /forcefsck shutdown -r now Will this repair the bad block and bring the system back up? If not then what other options should I use? The bad block is located in an LV assigned to a libvirt pool associated with a single vm. Can this be checked and corrected without having to deal with the base system? If so then how? Regards, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
On Tue, Mar 14, 2017, 7:41 AM James B. Byrne <byrnejb at harte-lyne.ca> wrote:> On Fri, March 10, 2017 11:57, m.roth at 5-cent.us wrote: > > > > > Looks like only one sector's bad. Running badblocks should, > > I think, mark that sector as bad, so the system doesn't try > > to read or write there. I've got a user whose workstation has > > had a bad sector running for over a year. However, if it > > becomes two, or four, or 64 sectors, it's replacement > > time, asap. > > <snip> > > > Bear with me on this. The last time I did anything like this I ended > up having to boot into recovery mode from an install cd and do this by > hand. This is not an option in the present circumstance as the unit > is a headless server in a remote location. > > If I do this: > > echo '-c' > /fsckoptions > touch /forcefsck > shutdown -r now > > Will this repair the bad block and bring the system back up? If not > then what other options should I use? > > The bad block is located in an LV assigned to a libvirt pool > associated with a single vm. Can this be checked and corrected > without having to deal with the base system? If so then how?You'll need to search the smartmontools site for their doc on bad sectors. There's a how to, to find what file is affected by the bad sector so you can replace it. That's the only way to fix the problem. This gets tricky going through LVM. Chris Murphy
On Mon, 2017-03-20 at 04:53 +0000, Chris Murphy wrote:> On Tue, Mar 14, 2017, 7:41 AM James B. Byrne <byrnejb at harte-lyne.ca> wrote: > > > On Fri, March 10, 2017 11:57, m.roth at 5-cent.us wrote: > > > > > > > > Looks like only one sector's bad. Running badblocks should, > > > <snip>> You'll need to search the smartmontools site for their doc on bad sectors. > There's a how to, to find what file is affected by the bad sector so you > can replace it. That's the only way to fix the problem. > > This gets tricky going through LVM.After booting from USB into single-user mode and dd'ing all readable blocks, multiple passes as I then had to "skip=" to start with next good blocks, I ran the manufacurers diag/repair software and had good results. YMMV> > > Chris Murphy > <snip>HTH, Bill