Re: [systemd-devel] root= ignored
On 29.01.2015 17:38, Chris Murphy wrote: On Thu, Jan 29, 2015 at 2:20 AM, Felix Miata mrma...@earthlink.net wrote: I wrote clone for a reason. I don't just copy files. I clone (logical, root, autonomous) *partitions*, subsequently modifying only fstab, volume label and UUID before attempting boot from it. Clone is a generic term, it doesn't require a particular process. Are you changing the volume UUID with, e.g. tune2fs -U random? files from old to new (I actually used btrfs send receive). I of course had to install a new bootloader with grub2-install, and create The process I wrote was intended to make it clear that no bootloader that may have been on a Fedora / partition was used for booting a Fedora clone as adjusted to its new location. It's a process that was relatively simple and reliable until humanly memorable cmdline root= parameters what worked formerly began being disregarded by Fedora's boot process in apparent favor of incorporating a root filesystem UUID subject to change during backup/restore process in its initrd. Like I said, I can't reproduce this behavior. The BIOS system boots fine without rebuilding the initramfs just by changing fstab and grub.cfg UUIDs to match the root volume's UUID. Therefore I see no evidence root= is ignored on Fedora. The failed UEFI boot is strictly due to the old ESP UUID not being found. The failure has nothing to do with root=. dracut -f -v --debug shows only on UEFI is there a wait for device by uuid /usr/lib/dracut/modules.d/99base/module-setup.sh@113(install): wait_for_dev /dev/disk/by-uuid/5AC5-5766 will follow up in private email and on the bugzilla ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
On Thu, Jan 29, 2015 at 2:20 AM, Felix Miata mrma...@earthlink.net wrote: I wrote clone for a reason. I don't just copy files. I clone (logical, root, autonomous) *partitions*, subsequently modifying only fstab, volume label and UUID before attempting boot from it. Clone is a generic term, it doesn't require a particular process. Are you changing the volume UUID with, e.g. tune2fs -U random? files from old to new (I actually used btrfs send receive). I of course had to install a new bootloader with grub2-install, and create The process I wrote was intended to make it clear that no bootloader that may have been on a Fedora / partition was used for booting a Fedora clone as adjusted to its new location. It's a process that was relatively simple and reliable until humanly memorable cmdline root= parameters what worked formerly began being disregarded by Fedora's boot process in apparent favor of incorporating a root filesystem UUID subject to change during backup/restore process in its initrd. Like I said, I can't reproduce this behavior. The BIOS system boots fine without rebuilding the initramfs just by changing fstab and grub.cfg UUIDs to match the root volume's UUID. Therefore I see no evidence root= is ignored on Fedora. The failed UEFI boot is strictly due to the old ESP UUID not being found. The failure has nothing to do with root=. dracut -f -v --debug shows only on UEFI is there a wait for device by uuid /usr/lib/dracut/modules.d/99base/module-setup.sh@113(install): wait_for_dev /dev/disk/by-uuid/5AC5-5766 -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
Chris Murphy composed on 2015-01-28 23:51 (UTC-0700): Felix Miata wrote: Chris Murphy composed on 2015-01-27 23:29 (UTC-0700): Felix Miata wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. All current distros whose bootloaders I've used include a root= in each of their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2 stanzas. That's true unless LVM is being used, which happens to be the default, in which case it's root=VG/LV. I've used LVM on exactly one HD, since wiped, too many years ago to remember when or which. When Fedora is the source and clone, attempting boot of clone using default initrd produces an emergency shell, unlike openSUSE. I'm unable to reproduce this problem on a BIOS system. What you describe below looks little like the process I described. Old volume is Btrfs, new volumes is Btrfs (new volume UUID), I didn't think any mention of filesystem type would be relevant in describing my process, but all clones used as a Fedora / here have been either EXT3 or EXT4. and I just copy the I wrote clone for a reason. I don't just copy files. I clone (logical, root, autonomous) *partitions*, subsequently modifying only fstab, volume label and UUID before attempting boot from it. files from old to new (I actually used btrfs send receive). I of course had to install a new bootloader with grub2-install, and create The process I wrote was intended to make it clear that no bootloader that may have been on a Fedora / partition was used for booting a Fedora clone as adjusted to its new location. It's a process that was relatively simple and reliable until humanly memorable cmdline root= parameters what worked formerly began being disregarded by Fedora's boot process in apparent favor of incorporating a root filesystem UUID subject to change during backup/restore process in its initrd. Somehow dracut is baking in the EFI System partition UUID into the initramfs, instead of honoring the correct one that I put into fstab. As a result boot fails and will always fail until I rebuild the initramfs. So I'd definitely consider that a bug. https://bugzilla.redhat.com/show_bug.cgi?id=1187007 Noted, commented, CC'd. -- 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
Chris Murphy composed on 2015-01-27 23:29 (UTC-0700): Felix Miata wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. All current distros whose bootloaders I've used include a root= in each of their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2 stanzas. Maybe it went into Fedora's Grub Legacy cmdlines before the switch to Grub2. I don't remember. I haven't installed any of Fedora's bootloaders since Fedora dropped Grub Legacy, so don't have first-hand experience from which to know otherwise. Most distros do not require use of their own bootloaders to successfully boot. I've been using openSUSE's Grub Legacy for booting all distros installed on my own systems ever since Grub2 started becoming distros' default bootloader. This has worked for all, except as described below. In the pre-libata days, as I remember, any syntactically correct root= on cmdline was what would be used to find /etc/fstab and get the root filesystem up. Included among the possibles valid with post-libata distros have been: root=/dev/sdX root=/dev/disk/by-label/... root=LABEL=... root=/dev/disk/by-uuid/... root=UUID=... What it means is that traditional cmdline root= option still works with openSUSE's configured-by-default initrds, but not with Fedora's configured-by-default initrds. Translated, this means the following process that works with non-Fedora root partitions fails with Fedora's root partitions: 1-boot anything other than intended logical source partition on a BIOS multiboot system with 1 HD only 2-clone an existing unmounted logical source/root partition to some other unmounted partition 3-configure a unique UUID and volume label on the clone 4-mount the clone and adjust its fstab appropriately 5-in the HD's bootloader menu (not the boot menu on the clone), clone the source stanza and adjust it appropriately to use for the clone, using any of the above listed (legal) root= forms. When Fedora is the source and clone, attempting boot of clone using default initrd produces an emergency shell, unlike openSUSE. To boot a Fedora clone normally requires a chroot rescue (what I usually do) or a /boot/initramfs-0-rescue*.img boot to rebuild its normal initrd(s). This Fedora characteristic in effect produces an undesirable, and likely unforeseeable by most, stumbling block to at least one backup/restore scenario that involves no change of hardware that Fedora's Dracut hostonly configuration seems to suggest would be safe. -- 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored (was: failing boot start jobs delay reboot)
On Wed, 28.01.15 00:58, Felix Miata (mrma...@earthlink.net) wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Felix Miata wrote: Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. Hmm, Fedora doesn't obey root=? That sounds like a bug. I think it's only a problem due to Fedora's configuration of its Dracut hostonly option used by default. AFAICR, its rescue initrds have always worked. I can't remember now, but it may possibly be Mageia with hostonly enabled disobeys root= too, locking onto root's UUID when the initrd was built. It's never been a problem I've observed in openSUSE, which let dracut evolve a lot longer before switching to it from mkinitrd. Hmm, but even in hostonly mode I'd assume that kernel cmdline settings override the included settings... Still sounds like a bug... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
On Wed, Jan 28, 2015 at 1:19 AM, Felix Miata mrma...@earthlink.net wrote: Chris Murphy composed on 2015-01-27 23:29 (UTC-0700): Felix Miata wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. All current distros whose bootloaders I've used include a root= in each of their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2 stanzas. That's true unless LVM is being used, which happens to be the default, in which case it's root=VG/LV. When Fedora is the source and clone, attempting boot of clone using default initrd produces an emergency shell, unlike openSUSE. I'm unable to reproduce this problem on a BIOS system. Old volume is Btrfs, new volumes is Btrfs (new volume UUID), and I just copy the files from old to new (I actually used btrfs send receive). I of course had to install a new bootloader with grub2-install, and create a new grub.cfg with grub2-mkconfig in order for the correct new volume root=UUID= to be set. And I also had to edit the fstab on the new volume so that the right UUIDs are called for there too. The resulting system boots fine. However, on UEFI that's not the case, I get dropped to a dracut shell: [ 188.409072] f21s2.localdomain dracut-initqueue[263]: Warning: /dev/disk/by-uuid/083A-7E6C does not exist That UUID is for the old FAT32 EFI System Partition. Somehow dracut is baking in the EFI System partition UUID into the initramfs, instead of honoring the correct one that I put into fstab. As a result boot fails and will always fail until I rebuild the initramfs. So I'd definitely consider that a bug. https://bugzilla.redhat.com/show_bug.cgi?id=1187007 -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored (was: failing boot start jobs delay reboot)
On Tue, Jan 27, 2015 at 10:58 PM, Felix Miata mrma...@earthlink.net wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Felix Miata wrote: Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. I think it's only a problem due to Fedora's configuration of its Dracut hostonly option used by default. AFAICR, its rescue initrds have always worked. The problem(s) with Fedora rescue initramfs: 1. It behaves differently depending on whether its /lib/modules have been deleted because the originally installed kernel has been removed due to yum.conf installonly_limit=3 being reached. If deleted, user gets dropped to a dracut prompt. And if not they get a complete boot to a login prompt. It's better than a kernel panic, but the inconsistency is not a good UX. 2. rescue is a generic term, but this nohostonly initramfs is really meant to get a close to full boot when changing hardware such that the hostonly initramfs does't work. So the use case is not really rescue. 3. A user might think rescue is for fsck or something basic. But that can be done with rd.break=cmdline it doesn't require the rescue initramfs. 4. Confusion with rescue.target and emergency.target. Both of which require a root password, and Fedora now doesn't require a root password at install or setup time, so the user can actually get stuck being unable to access rdsosreport.txt because they can't login. So... it's slightly ickey right now for these edge cases. Anyway, room for improvement. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored (was: failing boot start jobs delay reboot)
Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Felix Miata wrote: Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. Hmm, Fedora doesn't obey root=? That sounds like a bug. I think it's only a problem due to Fedora's configuration of its Dracut hostonly option used by default. AFAICR, its rescue initrds have always worked. I can't remember now, but it may possibly be Mageia with hostonly enabled disobeys root= too, locking onto root's UUID when the initrd was built. It's never been a problem I've observed in openSUSE, which let dracut evolve a lot longer before switching to it from mkinitrd. Harald? -- 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
