On 18 January 2017 at 15:39, bugproxy <[email protected]> wrote: > ------- Comment From [email protected] 2017-01-18 10:36 EDT------- > (In reply to comment #21) >> Installed lpar onto 154d dasd drive, using LVM automatic partitioning recipe. >> After installation and reipl, I did the following: > >> $ sudo update-initramfs -u > > I understand that things work with this explicit call.
How does it work with e.g. dracut? One must regenerate the initramfs to activate the additional drive on boot, no? Does one required to call zipl (which calls into dracut to regenerate initramfs....?!) or does one call dracut? E.g. how does thing work without any explicit calls to regenerate the initramfs? > However, users can easily miss this since it's not entirely obvious. > Regular ubuntu/debian users do know to call update-initramfs -u when fiddling/changing rootfs devices (not the most trivial task to be honest). Same as fedora users know to call dracut. IMHO. >> At the end of all of this I have triggered a reboot; whilst watching >> Operating system messages. Reboot was completed successfully. Thus imho this >> bug is invalid. > >> However, I do think that on Ubuntu systems "chzdev -e" should always trigger >> "initramfs-update -u" irrespective of what has been activated. Such that >> initramfs has as up-to-date udev rules as possible. Simply because it is >> impossible to predict at chzdev activation time whether or not something >> will be formated and added to become part of the rootfs backing devices or >> not. > > Hm, good point. But then again, it would be suboptimal to have hundreds > of disks (paths) (or vNICs or other device types) activated early in > initramfs just because a few of the disks are actually required to mount > the root-fs (and that's all an initramfs should do). Alas, I don't know > how to solve it optimally. > Ubuntu uses chzdev, which generates udev rules, and our initramfs hooks copy all of the udev rules into the initramfs as udev is running in Ubuntu initramfs. The boot continues as soon as rootfs is detected to be available. If other devices are activated in parallel, it should be mostly harmless. And the boot will not wait to activate all the things that udev rules specify in the initramfs. Thus it's kind of a zero sum game, eventually all chzdev->udev rules specified devices will be activated, and it does not matter much if some of them are activated from initramfs or post-initramfs. > (In reply to comment #18) >> I have now added zdev root update hook in zesty, such that chzdev will >> call update-initramfs -u. >> I will test the behaviour and will cherry-pick that as an SRU into >> xenial & yakkety. > > I cannot quite follow why this bug is invalid. > I thought your above quoted code changes actually fixed this bug by not > requiring the user to explicitly run "update-initramfs -u" any more. I added the hook in place such that chzdev can call it when it needs to. But I'm arguing that the hooks that chzdev calls will never be sufficient when one decides to move their rootfs, on any Linux. Because at initial "chzdev -e" call time the device that is being activated is not yet part of the rootfs stack, but will become after one e.g. expands lvm / mdadm / btrfs / etc on to it. Does that make sense? > If the bug is now declared invalid as in "user error", then I'm puzzled about > the reasons for a code change. > a code change was mostly a red-herring (oh there is a hook integration that is not currently used, let's use it if we can). The root cause of the bug is a user error - not regenerating initramfs after changing rootfs devices. >From the bug log, it seems there have been no attempts made to make sure initramfs is updated, after the devices for the rootfs are changed. As far as I understand the pattern should be: (1) chzdev -e new-device; (2) mangle new-device into roofs; (3) call something to regenerated initramfs Where (3) should be "update-initramfs -u" or "chzdev" (again) since at this point it should have enough information to realise that rootfs stack has changed and would therefore call "update-initramfs -u" via the newly integrated hook (the red-herring code change, on the newer ubuntu, as I don't think I have SRUed this). But in practice step (3) imho should be just "update-initramfs -u" (debian/ubuntu) or "dracut" (fedora/suse/rhel/etc) which is in my opinion trivial and discoverable enough. -- Regards, Dimitri. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1641078 Title: System cannot be booted up when root filesystem is on an LVM on two disks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1641078/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
