Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #208647

Re: virtual device both is and isn't a valid file system [complete]

Show all headers | View raw

	Hi.

On Tue, May 14, 2019 at 09:52:10AM -0700, Ross Boylan wrote:
> Here's the info:

Nothing interesting in the strace output, short of:

<strace output>:
...
mount("/dev/mapper/stretch--vg-boot",
"/root/tempserver-check/stretch_boot", "ext4", 0, NULL) = -1 EIO
(Input/output error)
...

The reason being - EIO return code is not documented in the mount(2).
Well, mount(1) said something about that 'other error' as a possible
reason of failure, but the clarity of the message is something that's
left to be desired here.


But this (when in doubt - always check dmesg. Userspace can and will
lie. Trust the kernel):

> root@barley:~/tempserver-check# dmesg | tail
...
> [74940.130661] block nbd3: Write on read-only
> [74940.130666] print_req_error: I/O error, dev nbd3, sector 22843394
> [74940.130671] Buffer I/O error on dev dm-30, logical block 1, lost
> sync page write
> [74940.130677] EXT4-fs (dm-30): I/O error while writing superblock
> [74940.130684] EXT4-fs (dm-30): mount failed

combined with this:

> root@barley:~/tempserver-check# e2fsck -fn /dev/stretch-vg/boot
> e2fsck 1.44.5 (15-Dec-2018)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/stretch-vg/boot: 345/97536 files (0.3% non-contiguous),
> 116077/389120 blocks

and this (note -r here):

> qemu-nbd -v -r --fork -c ...

and this:

> mount /dev/stretch-vg/boot stretch_boot


Brings me to the following:

1) One cannot mount an ext* filesystem in read-write mode (it's the
default) unless an underlying block device is also in read-write mode.
Your PV is read-only, that's the source of your problem.

2) One can mount an ext* filesystem in read-only mode, assuming that
it's clean. Currently that's your case, so 

mount -r /dev/stretch-vg/boot stretch_boot

should work for you.

3) Both fsck (with -n option), and dump(1) should work here too.

4) But to escape the future confusion I suggest you to loose that '-r'
flag in qemu-nbd. And to backup that 'vdi' image beforehand, just in
case.

Reco

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

virtual device both is and isn't a valid file system Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-14 09:20 +0200
  virtual device both is and isn't a valid file system [complete] Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-14 10:20 +0200
    Re: virtual device both is and isn't a valid file system [complete] Reco <recoverym4n@enotuniq.net> - 2019-05-14 10:30 +0200
      Re: virtual device both is and isn't a valid file system [complete] Curt <curty@free.fr> - 2019-05-14 15:30 +0200
        Re: virtual device both is and isn't a valid file system [complete] Reco <recoverym4n@enotuniq.net> - 2019-05-14 15:40 +0200
      Re: virtual device both is and isn't a valid file system [complete] Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-14 19:00 +0200
        Re: virtual device both is and isn't a valid file system [complete] Reco <recoverym4n@enotuniq.net> - 2019-05-14 19:20 +0200
        Re: virtual device both is and isn't a valid file system [complete] Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-14 19:30 +0200
          Re: virtual device both is and isn't a valid file system [complete] Reco <recoverym4n@enotuniq.net> - 2019-05-14 19:40 +0200
          Re: virtual device both is and isn't a valid file system [solved] Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-14 19:40 +0200

csiph-web