1

My personal server (odroid-c1 tiny ARM computer) is running Archlinux on an LVM filesystem over USB disks. Logical volumes containing data (backups, etc) are mirrored and everything works fine.

Now, I mirror the root filesystem with the command :

sudo lvconvert -m 1 VG01/NASSYS

Command processing is Ok and, after a while, NASSSYS LV is 100% mirrored.

But, on reboot, the system hangs, as if it could not recognize the mirrored LVM Volume. If I revert to a non mirrored NASSYS LV, boot is Ok again.

Can't a root filesystem simply be mirrored ?

(Below copy of my previous post, closed and unanswered, for full details )


Previous post
I have installed my personal fileserver running ARM Archlinux on an Odroid-C1 computer (a tiny computer board, similar to the Raspberry Pi) and a Xystec PX2590 USB case containing 4 disks, 2 of them being LVM2 configured in a single VG (VG01) and several LVs, not mirrored, including NASSYS, SDATA and GDATA.

Except for the /boot directory, which resides on an SDCard (mandatory for booting the Odroid-C1), the Archlinux System is installed on the NASSYS LV.

Configuration of the boot process, described in the /boot/boot.ini file, allows to change the root device to the NASSYS LV after Kernel is loaded from the SDCard (see setenv statement below).

Excerpt of the /boot/boot.ini file

...
setenv bootargs "console=ttyS0,115200n8 console=tty0 rootwait root=/dev/mapper/VG01-NASSYS lvmwait=/dev/mapper/VG01-NASSYS rw no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout_mode} ${disableuhs} ${hdmi_hpd} ${hdmi_cec}"

ext4load mmc 0:1 0x21000000 /boot/uImage
ext4load mmc 0:1 0x30000000 /boot/uInitrd
ext4load mmc 0:1 0x21800000 /boot/dtbs/meson8b_odroidc.dtb
fdt addr 21800000

if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi

if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi

bootm 0x21000000 0x30000000 0x21800000

This configuration is Ok, and the system boots and works perfectly (see my post on Odroid Forum to read the whole story of this installation !).

I then planned to secure my system by mirroring my xDATA LVs using the following commands :

$ sudo lvconvert -m 1 VG01/SDATA
$ sudo lvconvert -m 1 VG01/GDATA

All commands were correctly executed, and, after synchronization of the mirrors, I rebooted the system, which was up and running without problem.

Lately, I decided to mirror the NASSYS LV, containing the root filesystem with the same command :

$ sudo lvconvert -m 1 VG01/NASSYS

This command also ran without any error, and after mirroring was ended, I rebooted the system, but it hanged, and I had to turn off the computer (I tried it several times).

Using Minicom, I then used the serial console to view the boot process on my laptop, but couldn't see any relevant errors. The boot process simply stopped, seeming to wait for the root filesystem... So I suspected the mirroring of NASSYS somewhat broke this recognition

This was confirmed by reverting, from my laptop, NASSYS to a linear LV with the command :

$ sudo lvconvert -m 0 VG01/NASSYS

The Odroid-C1 booted again normally.

Here are the last lines of the boot process when it fails

...
[    6.549908@0]  sda: sda1
[    6.564824@0] sd 0:0:0:0: [sda] No Caching mode page found
[    6.567473@0] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    6.576850@0] sd 0:0:0:0: [sda] Attached SCSI disk
[    7.189162@3] device-mapper: uevent: version 1.0.3
[    7.192823@3] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-devel@redhat.com
[    7.228105@2] bio: create slab <bio-2> at 2
[    8.639100@0] emmc: mmc_rescan_try_freq: trying to init card at 300000 Hz
[    8.678075@0] aml_emmc_hw_reset 1379
<<< BOOT HANGED HERE >>>

and the same part of the boot process when it succeeds

....
[    6.268597@3] sd 0:0:0:3: [sdd] No Caching mode page found
[    6.268602@3] sd 0:0:0:3: [sdd] Assuming drive cache: write through
[    6.268609@3] sd 0:0:0:3: [sdd] Attached SCSI disk
[    6.332835@2] sd 0:0:0:2: [sdc] No Caching mode page found
[    6.335515@2] sd 0:0:0:2: [sdc] Assuming drive cache: write through
[    6.341668@2] sd 0:0:0:2: [sdc] Attached SCSI disk
[    6.938489@1] device-mapper: uevent: version 1.0.3
[    6.941347@1] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-devel@redhat.com
[    6.991678@0] bio: create slab <bio-2> at 2
[    7.504299@1] force enable DISCARD here for ext4 fs
[    7.514669@1] checked enable EXT4 DISCARD here
[    7.517501@1] EXT4-fs (dm-2): mounting with "discard" option, but the device does not support discard
[    7.525519@1] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null)
[    8.539137@0] emmc: mmc_rescan_try_freq: trying to init card at 300000 Hz
[    8.552060@3] systemd-journald[111]: Received SIGTERM from PID 1 (systemd).
[    8.578083@0] aml_emmc_hw_reset 1379
[    9.148086@1] Changing uart_ao_ttyS0: baud from 0 to 115200
[   10.227180@2] EXT4-fs (dm-2): re-mounted. Opts: data=ordered
[   10.284815@2] systemd-journald[245]: Failed to set file attributes: Inappropriate ioctl for device
[   11.498794@3] Driver for 1-wire Dallas network protocol.
[   12.149753@3] ionvideo open
[   12.152921@3] ionvideo_stop_generating!!!!
[   12.155830@3] ionvideo release
[   12.149860@3] amlvideo openamlvideo close[   13.336840@3] systemd-journald[245]: Received request to flush 1
[   13.402213@0] force enable DISCARD here for ext4 fs
[   13.411071@0] checked enable EXT4 DISCARD here
[   13.414142@0] EXT4-fs (mmcblk0p1): mounting with "discard" option, but the device does not support discard
<<< BOOT CONTINUES NORMALLY >>>
...

Despite many searches on Internet, I couldn't find any information about this kind of issue concerning LVM. Could it be specific to ARM ?

Or did I miss anything in the LVM configuration file below ?

config {
    checks = 1
    abort_on_errors = 0
    profile_dir = "/etc/lvm/profile"
}
devices {
    dir = "/dev"
    scan = [ "/dev" ]
    external_device_info_source = "none"
    obtain_device_list_from_udev = 1
    cache_dir = "/etc/lvm/cache"
    cache_file_prefix = ""
    write_cache_state = 1
    sysfs_scan = 1
    multipath_component_detection = 1
    md_component_detection = 1
    fw_raid_component_detection = 0
    md_chunk_alignment = 1
    data_alignment_detection = 1
    data_alignment = 0
    data_alignment_offset_detection = 1
    ignore_suspended_devices = 0
    ignore_lvm_mirrors = 1
    disable_after_error_count = 0
    require_restorefile_with_uuid = 1
    pv_min_size = 2048
    issue_discards = 0
}
allocation {
    maximise_cling = 1
    use_blkid_wiping = 1
    wipe_signatures_when_zeroing_new_lvs = 1
    mirror_logs_require_separate_pvs = 0
    cache_pool_metadata_require_separate_pvs = 0
    thin_pool_metadata_require_separate_pvs = 0
}
log {
    verbose = 0
    silent = 0
    syslog = 1
    overwrite = 0
    level = 0
    indent = 1
    command_names = 0
    prefix = "  "
    debug_classes = [ "memory", "devices", "activation", "allocation",
              "lvmetad", "metadata", "cache", "locking" ]
}
backup {
    backup = 1
    backup_dir = "/etc/lvm/backup"
    archive = 1
    archive_dir = "/etc/lvm/archive"
    retain_min = 10
    retain_days = 30
}
shell {
    history_size = 100
}
global {
    umask = 077
    test = 0
    units = "h"
    si_unit_consistency = 1
    suffix = 1
    activation = 1
    proc = "/proc"
    locking_type = 1
    wait_for_locks = 1
    fallback_to_clustered_locking = 1
    fallback_to_local_locking = 1
    locking_dir = "/run/lock/lvm"
    prioritise_write_locks = 1
    abort_on_internal_errors = 0
    detect_internal_vg_cache_corruption = 0
    metadata_read_only = 0
    mirror_segtype_default = "raid1"
    raid10_segtype_default = "raid10"
    sparse_segtype_default = "thin"
    use_lvmetad = 1
}
activation {
    checks = 0
    udev_sync = 1
    udev_rules = 1
    verify_udev_operations = 0
    retry_deactivation = 1
    missing_stripe_filler = "error"
    use_linear_target = 1
    reserved_stack = 64
    reserved_memory = 8192
    process_priority = -18
    raid_region_size = 512
    readahead = "auto"
    raid_fault_policy = "warn"
    mirror_log_fault_policy = "allocate"
    mirror_image_fault_policy = "remove"
    snapshot_autoextend_threshold = 100
    snapshot_autoextend_percent = 20
    thin_pool_autoextend_threshold = 100
    thin_pool_autoextend_percent = 20
    use_mlockall = 0
    monitoring = 1
    polling_interval = 15
    activation_mode = "degraded"
}
dmeventd {
    mirror_library = "libdevmapper-event-lvm2mirror.so"
    snapshot_library = "libdevmapper-event-lvm2snapshot.so"
    thin_library = "libdevmapper-event-lvm2thin.so"
}

Thanks for your help.

2

I answer to myself. Archlinux kernel for Odroid-C1 doesn't include the dm_raid module, mandatory to access LVM mirrors (now raid1 by default).

The solution is to include it in the MODULES variable of the /etc/mkinitcpio.conf file and regenerate the uInitrd.

Problem solved.

0

The old link doesn't seem to work, so there isn't enough detail here. At what point in the boot process does it hang, what are the last few messages before it gets stuck? Do you have a separate /boot partition?

  • Hmm, I guess the link is broken for you because the post is closed. I'll copy it at the bottom of my new post. – hutou Jun 4 '15 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.