[opensuse] RAID1 13.2 clone via rsync could not find /dev/mdX root device
CPU is Intel Haswell on B85 chipset. Multiboot RAID1 installation started with 13.1 on /dev/md1, 11.4 on /dev/md2, and 13.2 on /dev/md3. Wishing to test a DVD media upgrade from 32 bit to 64, booted to 13.1, I umounted 11.4 (on EXT3), reformatted md2 EXT4, remounted md2, then rsync'd from 13.2 on md3 to the freshly formatted md2. Next I adjusted what was the 11.4 grub stanza on /dev/sda1 to do the new 13.2 on md2, and fstab on md2. When I tried to boot md2, I always got a Dracut emergency shell reporting [/dev/md2|LABEL=10os13264] root device does not exist. After a few repeats, I booted the original 13.2 on md3, chrooted into the new 13.2 on md2, changed dracut's configs to hostonly="no" and hostonly_cmdline="no", ran dracut, and tried booting 13.2 on md2 again, with identical result, except taking 6+ seconds instead of 4+ seconds to reach the fail point due to the monstrously larger non-hostonly initrd. The dracut shell seems to be produce a runaround trying to mount anything to copy rdsosreport.txt to. It has no fdisk to report anything about partitioning. /dev/md* does not exist. 'systemctl reboot' apparently won't complete, as it's trying to undo things that it failed to do in the first place. CAD doesn't do anything. 'exit' doesn't cause reboot either. Finally I tried another chroot initrd build, this time with hostonly='no', and with add_drivers+="raid1 md_mod". It works, but I don't understand why the explicit addition of the two extra modules to the initrd was required, or why the failure with the comprehensive hostonly=no initrd. If this kind of clone can't be booted without all the fuss, how could a restored backup? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Nov 17, 2015 at 11:14 AM, Felix Miata
CPU is Intel Haswell on B85 chipset. Multiboot RAID1 installation started with 13.1 on /dev/md1, 11.4 on /dev/md2, and 13.2 on /dev/md3.
Wishing to test a DVD media upgrade from 32 bit to 64, booted to 13.1, I umounted 11.4 (on EXT3), reformatted md2 EXT4, remounted md2, then rsync'd from 13.2 on md3 to the freshly formatted md2. Next I adjusted what was the 11.4 grub stanza on /dev/sda1 to do the new 13.2 on md2, and fstab on md2.
When I tried to boot md2, I always got a Dracut emergency shell reporting [/dev/md2|LABEL=10os13264] root device does not exist. After a few repeats, I booted the original 13.2 on md3, chrooted into the new 13.2 on md2, changed dracut's configs to hostonly="no" and hostonly_cmdline="no", ran dracut, and tried booting 13.2 on md2 again, with identical result, except taking 6+ seconds instead of 4+ seconds to reach the fail point due to the monstrously larger non-hostonly initrd.
The dracut shell seems to be produce a runaround trying to mount anything to copy rdsosreport.txt to. It has no fdisk to report anything about partitioning. /dev/md* does not exist.
'systemctl reboot' apparently won't complete, as it's trying to undo things that it failed to do in the first place. CAD doesn't do anything. 'exit' doesn't cause reboot either.
Finally I tried another chroot initrd build, this time with hostonly='no', and with add_drivers+="raid1 md_mod". It works, but I don't understand why the explicit addition of the two extra modules to the initrd was required, or
One reason could be that your chroot did not have /dev, /sys and /proc required for autodetection of kernel drivers.
why the failure with the comprehensive hostonly=no initrd. If this kind of clone can't be booted without all the fuss, how could a restored backup? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov composed on 2015-11-17 11:44 (UTC+0300):
Felix Miata wrote:
Finally I tried another chroot initrd build, this time with hostonly='no', and with add_drivers+="raid1 md_mod". It works, but I don't understand why the explicit addition of the two extra modules to the initrd was required, or
One reason could be that your chroot did not have /dev, /sys and /proc required for autodetection of kernel drivers.
For the second chroot dracut execution, I typed no commands. I used only most recent bash history and <ENTER>, both to initiate the chroot following the three bind mounts, and to run dracut.
why the failure with the comprehensive hostonly=no initrd. If this kind of clone can't be booted without all the fuss, how could a restored backup? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
17.11.2015 12:00, Felix Miata пишет:
Andrei Borzenkov composed on 2015-11-17 11:44 (UTC+0300):
Felix Miata wrote:
Finally I tried another chroot initrd build, this time with hostonly='no', and with add_drivers+="raid1 md_mod". It works, but I don't understand why the explicit addition of the two extra modules to the initrd was required, or
One reason could be that your chroot did not have /dev, /sys and /proc required for autodetection of kernel drivers.
For the second chroot dracut execution, I typed no commands. I used only most recent bash history and <ENTER>, both to initiate the chroot following the three bind mounts, and to run dracut.
why the failure with the comprehensive hostonly=no initrd. If this kind of clone can't be booted without all the fuss, how could a restored backup?
https://bugzilla.opensuse.org/show_bug.cgi?id=935993#c50 could be related (skipping to the relevant comment for you). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov composed on 2015-11-18 06:51 (UTC+0300):
Felix Miata composed:
Andrei Borzenkov composed on 2015-11-17 11:44 (UTC+0300):
Felix Miata wrote:
Finally I tried another chroot initrd build, this time with hostonly='no', and with add_drivers+="raid1 md_mod". It works, but I don't understand why the explicit addition of the two extra modules to the initrd was required, or
One reason could be that your chroot did not have /dev, /sys and /proc required for autodetection of kernel drivers.
For the second chroot dracut execution, I typed no commands. I used only most recent bash history and <ENTER>, both to initiate the chroot following the three bind mounts, and to run dracut.
why the failure with the comprehensive hostonly=no initrd. If this kind of clone can't be booted without all the fuss, how could a restored backup?
https://bugzilla.opensuse.org/show_bug.cgi?id=935993#c50 could be related (skipping to the relevant comment for you).
I'm unable to recognize a connection between that bug and what happened here. I grep'd raid output of lsinitrd on both original and freshly working initrds, then diff'd, and the only difference is in timestamps. /etc/modules-load.d is empty. Timestamps on /usr/lib/udev/rules.d/ 63-md-raid-arrays.rules and 64-md-raid-assembly.rules' timestamps predate the old initrd. That bug is TW, while this is about 13.2, so that report could be about since changed behavior. Now that this trouble is behind me I'm going to proceed to try the offline upgrade from 32 bit to 64 bit that surfaced this obstacle in preparation for. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Andrei Borzenkov -
Felix Miata