Re: migrating drives on UEFI systems
On 6/21/20 10:42 PM, Tim via users wrote: Hi, On the old BIOS systems, if I wanted to swap hard drives on a system (e.g. move over to a bigger one), I could clone it off-line, then swap over, and it'd just work. Should I expect a UEFI system to do it that simply? Yes, it should be even easier than non-UEFI. No MBR and hidden boot sectors to worry about. I just did this with my son's laptop a few days ago. I booted a live image and used gparted to shrink and copy partitions from an HDD to an SSD. Fedora booted up just fine, but Windows is really unhappy. And do secure boot options throw any spanners in the works, too? No, you're not changing any signatures. It's still all the same files. I tried this last night, and it didn't want to boot. I cloned it using "dd if=/dev/sda of=/dev/sdb" while booted from a gparted ISO on a USB flashdrive (current release). Shut down. Unplugged the old drive. Rebooted. If it makes any difference, I can't recall if I plugged it into the same SATA port on the motherboard. It's a board with 6 sockets, and I'm only using two of them (DVD and HDD). That might be the problem. If you run "efibootmgr -v" you'll see which drive it's going to try to find it on. You might have ended up with the DVD and HDD in a different order. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: migrating drives on UEFI systems
On 6/21/20 10:42 PM, Tim via users wrote: On the old BIOS systems, if I wanted to swap hard drives on a system (e.g. move over to a bigger one), I could clone it off-line, then swap over, and it'd just work. Should I expect a UEFI system to do it that simply? In theory, yes. At least I think so. :) Your UEFI firmware has a list of boot devices and paths to a bootloader. On each device, it expects a FAT filesystem, in which it will find the bootloader at the corresponding path. If you "dd" a drive, then all of the UUIDs for the filesystems should be the same, and the system should boot without complaints. If any UUIDs do change, the UEFI should look for /EFI/BOOT/BOOTX64.EFI as a default. That file exists on your Fedora system partition, and IIRC, it will add a new boot entry to the UEFI list and boot your Fedora system. And do secure boot options throw any spanners in the works, too? No, it shouldn't. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: How do I change the grub kernel boot parameters in F32 ?
On Fri, Jun 19, 2020 Stephen Morris wrote:
> On 17/6/20 1:52 am, Tom H wrote:
>> On Tue, Jun 16, 2020 Stephen Morris wrote:
>>>
>>> If GRUB_ENABLE_BLSCFG=false is not going to be supported anymore,
>>> how does one disable BLS if we don't want it?
>>
>> You MAY be right in assuming that Fedora might choose only to
>> support BLS.
>>
>> If that day comes, we'll use BLS. I hope that, by then, we'll have
>> a way to customize the snippets, for example, not to use the
>> machine-id UUIDs.
>
> My issue with BLS is the way it displays the kernel menu entries in
> grub, it is exactly the same as the way grubby showed the entries
> which I also hated, consequently I refuse to use BLS until such time
> as they provide an option to get the menus displayed as an entry for
> the current kernel and an expandable menu for all other kernels and
> the recovery entries.
I agree that the default menu entries are pretty weird.
I only have two Fedora BIOS VMs where the BLS snippets are created by
"/usr/lib/kernel/install.d/20-grub.install".
I've edited the 20-... script to create the file name and the menu
entry that I want. It's not a "%config" or "%config(noreplace)" file,
so it'll be overwritten on "grub2-common" upgrades.
I overwrite the snippet for the running kernel with:
KERNEL_INSTALL_MACHINE_ID=$(cat /etc/machine-id)
/usr/lib/kernel/install.d/20-grub.install add $(uname -r)
/boot/${KERNEL_INSTALL_MACHINE_ID}/$(uname -r) /lib/modules/$(uname
-r)/vmlinuz
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
On 2020-06-21 18:54, Patrick O'Callaghan wrote: 0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ; /usr/local/bin/dock down I would suggest to avoid multiple commands on a cron entry, better to have a simple /usr/local/bin/do_backup with the three commands inside. There you can log with "date" commands the execution the starting of each of the part and probably discover that the up part is working fine (md127: active with 2 out of 2 mirrors) then the backup script is failing (or not starting) and the down part is having problems, apparently shutting down disks while md is still active. Cron jobs have often problems with missing env variables (e.g. simplified PATH) , those can also be fixed if you go the do_backup approach. Regards. -- Roberto Ragusamail at robertoragusa.it ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
[389-users] Re: 389 + sssd: Give user information about 389 server password policy
> On 19 Jun 2020, at 23:15, Mark Reynolds wrote: > > Directory Server has its own internal password policy that it manages itself. > It does not communicate with other services. 389's password policy does say > why it rejects passwords. But in IPA deployments IPA also has its own unique > password policy plugin, and it does NOT use 389's password policy. > >> To follow up what Mark said, can you confirm if this is 389 ds on it's own, or a FreeIPA installation? — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Re: migrating drives on UEFI systems
Tim via users 于2020年6月22日周一 下午9:14写道： > > Tim: > >> I tried this last night, and it didn't want to boot. I cloned it > >> using > > Qiyu Yan: > > How it didn't want to boot, did you enter the GRUB or just stuck in > > UEFI or something else? I'd guess you stuck at UEFI stage and can't > > enter GRUB. > > UEFI gave me its error message about not being a bootable drive. I had > to reboot and try different boot devices using UEFI boot options. That makes sense, old boot entry doesn't work and UEFI may look for a fallback and unable to find one. Try: - Change boot options, make default device to your new disk - If that don't work, setup boot entry manually. Use a live disk will be a good choice. > > >> If it makes any difference, I can't recall if I plugged it into the > >> same SATA port on the motherboard. It's a board with 6 sockets, > > > For most motherboards, this will not affect if you have removed the > > old disk, UEFI will search for available EFI partitions. > > > > But you need to recreate boot entries via efibootmgr or grub2- > > install. > > I was hoping that when I used dd on the whole drive, that doing so > would have created everything it needed on the drive. **most everything** but by this way you didn't set up boot entry for your disk in UEFI's nvram, you need to do this manually. But usually, BOOTX64.EFI will be a fallback. > > Or is this a case of UEFI needing to be set for the right SATA port? > > -- > > uname -rsvp > Linux 3.10.0-1127.10.1.el7.x86_64 #1 SMP Wed Jun 3 14:28:03 UTC 2020 x86_64 > > Boilerplate: All unexpected mail to my mailbox is automatically deleted. > I will only get to see the messages that are posted to the mailing list. > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: migrating drives on UEFI systems
Tim: >> I tried this last night, and it didn't want to boot. I cloned it >> using Qiyu Yan: > How it didn't want to boot, did you enter the GRUB or just stuck in > UEFI or something else? I'd guess you stuck at UEFI stage and can't > enter GRUB. UEFI gave me its error message about not being a bootable drive. I had to reboot and try different boot devices using UEFI boot options. >> If it makes any difference, I can't recall if I plugged it into the >> same SATA port on the motherboard. It's a board with 6 sockets, > For most motherboards, this will not affect if you have removed the > old disk, UEFI will search for available EFI partitions. > > But you need to recreate boot entries via efibootmgr or grub2- > install. I was hoping that when I used dd on the whole drive, that doing so would have created everything it needed on the drive. Or is this a case of UEFI needing to be set for the right SATA port? -- uname -rsvp Linux 3.10.0-1127.10.1.el7.x86_64 #1 SMP Wed Jun 3 14:28:03 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: migrating drives on UEFI systems
Tim via users 于2020年6月22日周一 下午1:44写道： > > Hi, > > On the old BIOS systems, if I wanted to swap hard drives on a system > (e.g. move over to a bigger one), I could clone it off-line, then swap > over, and it'd just work. > > Should I expect a UEFI system to do it that simply? > > And do secure boot options throw any spanners in the works, too? > > > I tried this last night, and it didn't want to boot. I cloned it using How it didn't want to boot, did you enter the GRUB or just stuck in UEFI or something else? I'd guess you stuck at UEFI stage and can't enter GRUB. > "dd if=/dev/sda of=/dev/sdb" while booted from a gparted ISO on a USB > flashdrive (current release). Shut down. Unplugged the old drive. > Rebooted. > > If it makes any difference, I can't recall if I plugged it into the > same SATA port on the motherboard. It's a board with 6 sockets, and For most motherboards, this will not affect if you have removed the old disk, UEFI will search for available EFI partitions. But you need to recreate boot entries via efibootmgr or grub2-install. > I'm only using two of them (DVD and HDD). > > I did get it to boot by messing with the boot menus in UEFI, but it was > quite hit-and-miss about what to boot from. I can't remember now if I > selected the drive with it on, or the entry with the release's name in > it, but neither worked on the first boot. It was a few reboots before > I got it to go. > > -- > > uname -rsvp > Linux 3.10.0-1127.10.1.el7.x86_64 #1 SMP Wed Jun 3 14:28:03 UTC 2020 x86_64 > > Boilerplate: All unexpected mail to my mailbox is automatically deleted. > I will only get to see the messages that are posted to the mailing list. > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: migrating drives on UEFI systems
On Mon, 2020-06-22 at 10:28 +0100, Patrick O'Callaghan wrote: > Surely if you're moving to a larger disk, you don't want 'dd', which > will just clone the exact same partition table and sizes? I was doing a quick and dirty attempt to get a system running. If it worked, I would have grown the partitions to fill the drive. -- uname -rsvp Linux 3.10.0-1127.10.1.el7.x86_64 #1 SMP Wed Jun 3 14:28:03 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: migrating drives on UEFI systems
On Mon, 2020-06-22 at 15:12 +0930, Tim via users wrote: > Hi, > > On the old BIOS systems, if I wanted to swap hard drives on a system > (e.g. move over to a bigger one), I could clone it off-line, then swap > over, and it'd just work. > > Should I expect a UEFI system to do it that simply? > > And do secure boot options throw any spanners in the works, too? > > > I tried this last night, and it didn't want to boot. I cloned it using > "dd if=/dev/sda of=/dev/sdb" while booted from a gparted ISO on a USB > flashdrive (current release). Shut down. Unplugged the old drive. > Rebooted. Surely if you're moving to a larger disk, you don't want 'dd', which will just clone the exact same partition table and sizes? poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
On Sun, 2020-06-21 at 18:06 -0500, Roger Heflin wrote:
> It would appear that the md stop is still running when you remove the disk.
>
>
>
> So in both cases you run the exact same script but from cron it fails?
Yes.
> I would think you either need a loop validating that the md stopped or
> just put a simple few second sleep delay between the md stop and the
> disk stop.
I'll look at that (though I would think that when 'mdadm' returns it
means that md has in fact stopped), however the errors appear when
starting ('dock up'), not when stopping.
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
