I've been trying to get an HP elitedesk 705 G1 mt to boot from dvd. So far no luck. I've managed to get DVD listed as the first boot entry for both UEFI and legacy. The machine seems to try and fail. The error messages go by rather fast. I think I've seem things like "invalid header" and "no such file", but am not as sure as I'd like to be. Most recently I tried and failed with Fedora-Workstation-Live-x86_64-39.1.5.iso
Any idea what I should try next?
My late girlfriend used it. I remember her password, which is why she is not on the sudo list. I do not remember either the root password or my own.
On 3/24/24 16:43, Michael Hennebry wrote:
I've been trying to get an HP elitedesk 705 G1 mt to boot from dvd. So far no luck. I've managed to get DVD listed as the first boot entry for both UEFI and legacy. The machine seems to try and fail. The error messages go by rather fast. I think I've seem things like "invalid header" and "no such file", but am not as sure as I'd like to be. Most recently I tried and failed with Fedora-Workstation-Live-x86_64-39.1.5.iso
You've tried booting it in both legacy and UEFI modes? Do you get the grub menu or does it fail before that? From the EFI boot menu, can you pick the BOOT or GRUB efi files from the DVD?
On 3/24/24 18:43, Michael Hennebry wrote:
I've been trying to get an HP elitedesk 705 G1 mt to boot from dvd. So far no luck. I've managed to get DVD listed as the first boot entry for both UEFI and legacy. The machine seems to try and fail. The error messages go by rather fast. I think I've seem things like "invalid header" and "no such file", but am not as sure as I'd like to be. Most recently I tried and failed with Fedora-Workstation-Live-x86_64-39.1.5.iso
Any idea what I should try next?
My late girlfriend used it. I remember her password, which is why she is not on the sudo list. I do not remember either the root password or my own.
Condolences on the loss of your girlfriend. I'm sorry.
If the system was set up for legacy BIOS mode, changing it to UEFI mode will typically mean that the UEFI can't "see" the necessary disk partitions you need to boot. I would set it back to however it was when you started trying this so it boot off your existing partitions.
You can also create bootable media using a USB thumb drive if you follow the instructions at https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-in.... There's a section on how to do it from Windows or MacOS, too.
To recover the root password, you can do this: https://docs.fedoraproject.org/en-US/quick-docs/reset-root-password/
Then you can log in with root privileges and recover whatever is on the disk.
If you need additional help, post here and we'll help.
Thanks folks. Disabling UEFI mode did the trick, though I do not understand why it was necessary. I thought that recent Fedora DVDs worked with both legacy and UEFI. The Fedora-WS-Live-39-1.5 DVD does have an EFI directory.
I didn't get a grub menu until disabling UEFI.
On 3/25/24 10:21, Michael Hennebry wrote:
Thanks folks. Disabling UEFI mode did the trick, though I do not understand why it was necessary. I thought that recent Fedora DVDs worked with both legacy and UEFI. The Fedora-WS-Live-39-1.5 DVD does have an EFI directory.
I didn't get a grub menu until disabling UEFI.
Fedora can install on either legacy BIOS mode or modern UEFI. But when it installs on UEFI systems, it creates a special partition mounted on /boot/efi. If you boot a system which was installed in BIOS mode in UEFI mode, it doesn't see that partition and won't boot.
If you want to run Fedora in UEFI mode, I am relatively certain you have to reinstall (but I could absolutely be wrong). When I got a machine which supported UEFI, I initially turned off UEFI and Secure Boot because I'd heard horror stories about them with Linux. When I changed it to UEFI, I couldn't access my Linux installation. But since I had a backup of my home directory on another machine, I just nuked it and reinstalled, then restored my home directory.
I've actually set up my Linux machines so that they mount /home on an NFS file server in my home office. I can nuke my desktop and reinstall it in less than 10 minutes with a kickstart, and my home directory is unchanged. Makes it a lot easier when I do the inevitable "oops" and screw up my desktop.
As an aside: Using KVM virtualization has eliminated a lot of those "oops" moments. If I want to test software or something, I spin up a VM and test it there before I do it on my actual "production" workstation.
On 03/25/2024 09:33 AM, Thomas Cameron wrote:
I've actually set up my Linux machines so that they mount /home on an NFS file server in my home office. I can nuke my desktop and reinstall it in less than 10 minutes with a kickstart, and my home directory is unchanged. Makes it a lot easier when I do the inevitable "oops" and screw up my desktop.
If you have /home on its own partition, you don't even need to have it mounted on your file server. Just do a custom partitioning (I presume that you can do that with a kickstart) mounting that partition as /home and not reformatting and Bob's your uncle. I know, as I've been doing that for over two decades.
On 3/25/24 11:01, Joe Zeff wrote:
If you have /home on its own partition, you don't even need to have it mounted on your file server. Just do a custom partitioning (I presume that you can do that with a kickstart) mounting that partition as /home and not reformatting and Bob's your uncle. I know, as I've been doing that for over two decades.
I did that for a long time (been using Linux since '94), but now I have 10 gigabit ethernet between my desktop and my NFS server. It's fast as heck for /home.
When I realize I need to nuke my machine and start over, it's:
sudo -i dmesg > /dev/nvme1n1 systemctl reboot Choose the right kickstart from the menu. Refill coffee. Go back to working as if nothing happened. My home directory is there and my machine is reset to sane defaults.
On Mon, 25 Mar 2024, Patrick O'Callaghan wrote:
On Mon, 2024-03-25 at 11:07 -0500, Thomas Cameron wrote:
dmesg > /dev/nvme1n1
What's that about?
My guess is that nvm stands for non-volatile memory.
On 3/25/24 11:38, Patrick O'Callaghan wrote:
On Mon, 2024-03-25 at 11:07 -0500, Thomas Cameron wrote:
dmesg > /dev/nvme1n1
What's that about?
If you overwrite the first few sectors of the drive (i.e. with the output of the dmesg command), it nukes the boot instructions. It causes my machine to PXE boot and I kickstart it.
Sorry, I should have been more clear about that. It could be anything. I used to use dd if=/dev/zero of=/dev/nvme1n1 bs=1M count=1 but dmesg is quicker to type.
On Mon, 2024-03-25 at 12:36 -0500, Thomas Cameron wrote:
On 3/25/24 11:38, Patrick O'Callaghan wrote:
On Mon, 2024-03-25 at 11:07 -0500, Thomas Cameron wrote:
dmesg > /dev/nvme1n1
What's that about?
If you overwrite the first few sectors of the drive (i.e. with the output of the dmesg command), it nukes the boot instructions. It causes my machine to PXE boot and I kickstart it.
Sorry, I should have been more clear about that. It could be anything. I used to use dd if=/dev/zero of=/dev/nvme1n1 bs=1M count=1 but dmesg is quicker to type.
That's what I thought.
poc
On 3/25/24 11:38, Patrick O'Callaghan wrote:
On Mon, 2024-03-25 at 11:07 -0500, Thomas Cameron wrote:
dmesg > /dev/nvme1n1
What's that about?
poc
To further clarify, my system uses NVMe drives (/dev/nvme0n1 and /dev/nvme1n1). So when I do dmesg > /dev/nvme1n1 as root, it overwrites the first few hundred k of the NVMe disk, nuking the partition tables and boot instructions and the like. Then when I reboot, it causes my machine to PXE boot. You can nuke any drive by writing to the first few sectors, so it could have been /dev/sda, /dev/vda, /dev/xvda, or whatever.
On Mar 25, 2024, at 13:43, Thomas Cameron thomas.cameron@camerontech.com wrote:
On 3/25/24 11:38, Patrick O'Callaghan wrote:
On Mon, 2024-03-25 at 11:07 -0500, Thomas Cameron wrote: dmesg > /dev/nvme1n1
What's that about? poc
To further clarify, my system uses NVMe drives (/dev/nvme0n1 and /dev/nvme1n1). So when I do dmesg > /dev/nvme1n1 as root, it overwrites the first few hundred k of the NVMe disk, nuking the partition tables and boot instructions and the like. Then when I reboot, it causes my machine to PXE boot. You can nuke any drive by writing to the first few sectors, so it could have been /dev/sda, /dev/vda, /dev/xvda, or whatever.
On any modern system that uses UEFI, you can just use “efibootmgr -n ####” to temporarily set the next boot target to be the PXE boot entry (which has its own unique entry, replace #### with its number). Probably also worth deleting the existing entry to boot into Fedora at the same time.
Wiping the partition table doesn’t always guarantee that the next boot will be PXE, which is why I liked to automate it specifically.
No need to delete or wipe any bootloaders or partition tables, although it probably doesn’t hurt. I had a kickstart that preserved custom stuff like the krb5 keytab between reloads in the kickstart %pre section, so I didn’t want to just nuke the filesystem.
On Mon, Mar 25, 2024 at 11:08 AM Thomas Cameron < thomas.cameron@camerontech.com> wrote:
On 3/25/24 11:01, Joe Zeff wrote:
If you have /home on its own partition, you don't even need to have it mounted on your file server. Just do a custom partitioning (I presume that you can do that with a kickstart) mounting that partition as /home and not reformatting and Bob's your uncle. I know, as I've been doing that for over two decades.
I did that for a long time (been using Linux since '94), but now I have 10 gigabit ethernet between my desktop and my NFS server. It's fast as heck for /home.
When I realize I need to nuke my machine and start over, it's:
sudo -i dmesg > /dev/nvme1n1 systemctl reboot Choose the right kickstart from the menu. Refill coffee. Go back to working as if nothing happened. My home directory is there and my machine is reset to sane defaults.
-- Thomas
Neat! Is there a tutorial somewhere about how to do this?
On 4/1/24 00:25, Javier Perez wrote:
When I realize I need to nuke my machine and start over, it's: sudo -i dmesg > /dev/nvme1n1 systemctl reboot Choose the right kickstart from the menu. Refill coffee. Go back to working as if nothing happened. My home directory is there and my machine is reset to sane defaults. -- ThomasNeat! Is there a tutorial somewhere about how to do this?
Not that I know of. I saw it in some article decades ago. Basically, what you're doing is overwriting the first few k of the disk, which overwrites the boot instructions and partitions and the like.
Unless you're talking about kickstart or something else?
On 1 Apr 2024, at 18:21, Thomas Cameron thomas.cameron@camerontech.com wrote:
On 4/1/24 00:25, Javier Perez wrote:
When I realize I need to nuke my machine and start over, it's: sudo -i dmesg > /dev/nvme1n1 systemctl reboot Choose the right kickstart from the menu. Refill coffee. Go back to working as if nothing happened. My home directory is there and my machine is reset to sane defaults. -- Thomas Neat! Is there a tutorial somewhere about how to do this?
Not that I know of. I saw it in some article decades ago. Basically, what you're doing is overwriting the first few k of the disk, which overwrites the boot instructions and partitions and the like.
I tend to dd of a few MiB of zeros over the front of the disk. A few KiB is often not enough. In some cases you also need to overwrite at the end of the disk I have been told.
Barry
Unless you're talking about kickstart or something else?
Thomas
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 4/1/24 15:57, Barry Scott wrote:
I tend to dd of a few MiB of zeros over the front of the disk. A few KiB is often not enough. In some cases you also need to overwrite at the end of the disk I have been told.
Barry
TMTOWTDI.
The dmesg output is generally *plenty* to nuke the boot sector and render the drive unbootable, triggering a PXE boot. Depending on your hardware, the boot sector is either 512 bytes or 4096 bytes (4K), and the output of dmesg is over 40K on my system. So I'm lazy and just do:
dmesg > /dev/[device] systemctl reboot
I've known folks who do:
cat /var/log/messages > /dev/[device] systemctl reboot
or
dd if=/dev/zero of=/dev/[device] bs=1M count=1 systemctl reboot
and that works, too.
I've never heard of having to overwrite the end of the drive, but then, I've only been working with Linux professionally since 1995. ¯_(ツ)_/¯
On 4/1/24 17:10, Samuel Sieb wrote:
On 4/1/24 15:03, Thomas Cameron wrote:
I've never heard of having to overwrite the end of the drive, but then, I've only been working with Linux professionally since 1995. ¯_(ツ)_/¯
GPT has a backup copy stored in the last block of the disk.
You are absolutely correct. My poor little systems aren't big enough to use GPT volumes (mostly smaller KVM instances), so I didn't think about that. :-D
Although I'm relatively certain I've nuked GPT volumes on my hypervisors when I've rebuilt them, and they were not visible as volumes when I reinstalled the OS. I'll dig into that, now you have me curious.
On Mon, Apr 1, 2024 at 12:21 PM Thomas Cameron < thomas.cameron@camerontech.com> wrote:
On 4/1/24 00:25, Javier Perez wrote:
When I realize I need to nuke my machine and start over, it's: sudo -i dmesg > /dev/nvme1n1 systemctl reboot Choose the right kickstart from the menu. Refill coffee. Go back to working as if nothing happened. My home directory is there and my machine is reset to sane defaults. -- ThomasNeat! Is there a tutorial somewhere about how to do this?
Not that I know of. I saw it in some article decades ago. Basically, what you're doing is overwriting the first few k of the disk, which overwrites the boot instructions and partitions and the like.
Unless you're talking about kickstart or something else?
I was talking about kickstart
-- Thomas -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 4/4/24 00:27, Javier Perez wrote:
I was talking about kickstart
Here you go:
https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/advanced/Kicks...
If you have any specific questions, feel free to ask.
I usually "cheat" by building a system like I want it and then using the /root/anaconda-ks.cfg as a starting point for my kickstart.cfg file.
Happy to give more details if you'd like.
Thomas Cameron wrote:
I've actually set up my Linux machines so that they mount /home on an NFS file server in my home office. I can nuke my desktop and reinstall it in less than 10 minutes with a kickstart, and my home directory is unchanged. Makes it a lot easier when I do the inevitable "oops" and screw up my desktop.
Joe Zeff:
If you have /home on its own partition, you don't even need to have it mounted on your file server. Just do a custom partitioning (I presume that you can do that with a kickstart) mounting that partition as /home and not reformatting and Bob's your uncle. I know, as I've been doing that for over two decades.
I always favoured two drives in the box (separate software & data). You could easily unplug a data drive and be very sure that a new install could *never* screw it up.
And back when I had some spares, I favoured unplugging all drives on an old system, installing a new OS onto the spare drive in isolation, then using it *instead* of the old system drive. If the new OS install didn't work, or a new design was a major pain, it was a moment's work to go back to something that had worked.
Brute force and ignorance is a tried and tested method. Trying to be clever with boot menus, and carefully selecting specific partitions while installing, often goes awry. Not to mention the times you come across an installer that only wants to do a full takeover of your install drive and nuke everything that was on it.
On 03/25/2024 07:57 PM, Tim via users wrote:
Brute force and ignorance is a tried and tested method. Trying to be clever with boot menus, and carefully selecting specific partitions while installing, often goes awry. Not to mention the times you come across an installer that only wants to do a full takeover of your install drive and nuke everything that was on it.
In all the years I've been doing this I've never had it fail with a Fedora re-installation. Of course, I always have a full backup of /home before I upgrade or re-install, JIK.
On Mon, 2024-03-25 at 20:57 -0600, Joe Zeff wrote:
On 03/25/2024 07:57 PM, Tim via users wrote:
Brute force and ignorance is a tried and tested method. Trying to be clever with boot menus, and carefully selecting specific partitions while installing, often goes awry. Not to mention the times you come across an installer that only wants to do a full takeover of your install drive and nuke everything that was on it.
In all the years I've been doing this I've never had it fail with a Fedora re-installation. Of course, I always have a full backup of /home before I upgrade or re-install, JIK.
Ditto.
poc
On 3/25/24 21:57, Joe Zeff wrote:
In all the years I've been doing this I've never had it fail with a Fedora re-installation. Of course, I always have a full backup of /home before I upgrade or re-install, JIK.
I've never had it fail, either. But *in my case* it makes more sense for me to use an NFS mounted /home and now I just don't worry about it at all. I use a kickstart which rebuilds my desktop in about as much time as it takes me to pour a coffee and put my cream and sugar into it.
Not saying it's the right thing for anyone else. I am saying it's the right thing for me, in my little home lab.
Tim:
Brute force and ignorance is a tried and tested method. Trying to be clever with boot menus, and carefully selecting specific partitions while installing, often goes awry. Not to mention the times you come across an installer that only wants to do a full takeover of your install drive and nuke everything that was on it.
Joe Zeff:
In all the years I've been doing this I've never had it fail with a Fedora re-installation. Of course, I always have a full backup of /home before I upgrade or re-install, JIK.
Me neither, but better safe than sorry.
I hate having to deal with back-ups, it's time-consuming. Things can go wrong with them too, like what my web host did: Backed-up and restored my site's files without telling me (they were probably doing some maintenance on their gear the first time, the second time they were flailing around in the dark after they'd destroyed their perl installation). Every file had their permissions fouled up. Twice, now, I've had to un-munge about 1500 files.
On Tue, Mar 26, 2024 at 7:31 PM Tim via users users@lists.fedoraproject.org wrote:
I hate having to deal with back-ups, it's time-consuming. Things can go wrong with them too, like what my web host did: Backed-up and restored my site's files without telling me (they were probably doing some maintenance on their gear the first time, the second time they were flailing around in the dark after they'd destroyed their perl installation). Every file had their permissions fouled up. Twice, now, I've had to un-munge about 1500 files.
T'is a common tale but true.
I once spent a summer rescuing plain text data files from a backup of CDC Cyber onto Solaris. The files had records out of order or missing and blocks of duplicated records. Over the years, there had been changes to the data format.
The original files were used to produce printed data reports, then later scanned with an automated system that sometimes messed up a page without anyone checking. In some cases OCR on short sections of the data reports was able to replace missing records.
I did the work using command-line tools in Apple OSX. Rather than manually editing the files I was able to write shell scripts to remove duplicate records, sort them correctly, and adjust to a common format. It was a big exercise in POSIX shell and utilities text processing.
On Mon, 25 Mar 2024, Thomas Cameron wrote:
Fedora can install on either legacy BIOS mode or modern UEFI. But when it installs on UEFI systems, it creates a special partition mounted on /boot/efi. If you boot a system which was installed in BIOS mode in UEFI mode, it doesn't see that partition and won't boot.
To be clear: I wasn't trying to boot the hard drive or install to it. I was just trying to boot the DVD. Eventually I succeeded by disabling UEFI. The need surprised me. To boot from the hard drive, I had to re-enable UEFI.
If you want to run Fedora in UEFI mode, I am relatively certain you have to reinstall (but I could absolutely be wrong). When I got a machine which supported UEFI, I initially turned off UEFI and Secure Boot because I'd heard horror stories about them with Linux. When I changed it to UEFI, I couldn't access my Linux installation. But since I had a backup of my home directory on another machine, I just nuked it and reinstalled, then restored my home directory.
On 3/25/24 08:21, Michael Hennebry wrote:
Thanks folks. Disabling UEFI mode did the trick, though I do not understand why it was necessary. I thought that recent Fedora DVDs worked with both legacy and UEFI. The Fedora-WS-Live-39-1.5 DVD does have an EFI directory.
I didn't get a grub menu until disabling UEFI.
The DVD does work with both, so it's most likely an issue with the firmware on the system. Have you checked for firmware updates? Does it have an option to select an EFI file to boot from?
On Mon, 25 Mar 2024, Samuel Sieb wrote:
On 3/25/24 08:21, Michael Hennebry wrote:
Thanks folks. Disabling UEFI mode did the trick, though I do not understand why it was necessary. I thought that recent Fedora DVDs worked with both legacy and UEFI. The Fedora-WS-Live-39-1.5 DVD does have an EFI directory.
I didn't get a grub menu until disabling UEFI.
The DVD does work with both, so it's most likely an issue with the firmware on the system. Have you checked for firmware updates? Does it have an option to select an EFI file to boot from?
I thought file selection was part of grub. Didn't get to grub until I disabled UEFI.
On 3/25/24 15:27, Michael Hennebry wrote:
On Mon, 25 Mar 2024, Samuel Sieb wrote:
On 3/25/24 08:21, Michael Hennebry wrote:
Thanks folks. Disabling UEFI mode did the trick, though I do not understand why it was necessary. I thought that recent Fedora DVDs worked with both legacy and UEFI. The Fedora-WS-Live-39-1.5 DVD does have an EFI directory.
I didn't get a grub menu until disabling UEFI.
The DVD does work with both, so it's most likely an issue with the firmware on the system. Have you checked for firmware updates? Does it have an option to select an EFI file to boot from?
I thought file selection was part of grub. Didn't get to grub until I disabled UEFI.
Some firmware implementations will let you pick an EFI file from the boot menu or from the boot configuration in the BIOS.
-
Barry Scott -
George N. White III -
Javier Perez -
Joe Zeff -
Jonathan Billings -
Michael Hennebry -
Patrick O'Callaghan -
Samuel Sieb -
Thomas Cameron -
Tim