dd produces useless boot on installation USB
dd produces useless boot on installation USB
Followed guidelines and copied install image using dd. Boot never got passed grub. Rufus, however, did a good job although discouraged.
Cheers,
gostal
Cheers,
gostal
Desktop Dell T5810 Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz, 72 GB RAM, Radeon Pro WX 7100
CentOS 7.9.2009
CentOS 7.9.2009
Re: dd produces useless boot on installation USB
test ISO with md5sum and sha256sum
and
be sure you set dd if=image.iso of=/dev/sdX
never use /dev/sdx1..2..3..4
and
be sure you set dd if=image.iso of=/dev/sdX
never use /dev/sdx1..2..3..4
-
- Posts: 1521
- Joined: 2014/05/21 20:16:00
- Location: Central New York, USA
Re: dd produces useless boot on installation USB
Append your 'dd' command line with ";sync" to ensure you're not pulling the key out before the write is complete.
Re: dd produces useless boot on installation USB
As said I did follow guidelines but I will try adding sync to be sure.
Desktop Dell T5810 Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz, 72 GB RAM, Radeon Pro WX 7100
CentOS 7.9.2009
CentOS 7.9.2009
-
- Posts: 1521
- Joined: 2014/05/21 20:16:00
- Location: Central New York, USA
Re: dd produces useless boot on installation USB
I've pulled out intended boot USbs SO many times because linux completed caching (and returned the command prompt) despite it wasn't done writing the cache out to the target. Adding the 'sync' fixed the issue for me.
Re: dd produces useless boot on installation USB
Always ensure you umount any disk before removing it. USB sticks in this context are disks. Folks, UNIX used a cache to speed up write completion and Linux has inherited it. I was taught way back in the 1990s to always:and still do. This is pretty basic user-level 101 stuff I'm afraid to say.
[Simplified explanation] When you issue a write as a user the system moves the buffer from user-space into system-space and returns success. Your process is then free to continue processing and indeed writing. If the system didn't do this all I/Os would proceed as the pace of disks (some milliseconds), not at the pace of memory (under a microsecond) with consequent impact on processing speed. Where this cannot happen, for instance reads that are not pre-cached, then the process is placed in a wait state until the I/O completes. Look at top(1), you'll see a percentage labelled "wa" at the top. At a time determined by the device driver, the data is sent from the buffer to the disk. The driver can combine multiple small reads to efficiently pass data. When you issue a sync(1) command all data is flushed from system buffers to disk regardless. Historically two pushes were required by some systems, hence the advice to sync twice. You can then umount safely. Historically umount didn't always wait for sync to complete, hence syncing first. Clicking on a graphical umount or eject is quite acceptable.
I have come across instances where a USB stick took upwards of 10 minutes to finally sync, so don't assume that things are not working and yank it out regardless.
Code: Select all
# sync; sync
# umount <disk>
[Simplified explanation] When you issue a write as a user the system moves the buffer from user-space into system-space and returns success. Your process is then free to continue processing and indeed writing. If the system didn't do this all I/Os would proceed as the pace of disks (some milliseconds), not at the pace of memory (under a microsecond) with consequent impact on processing speed. Where this cannot happen, for instance reads that are not pre-cached, then the process is placed in a wait state until the I/O completes. Look at top(1), you'll see a percentage labelled "wa" at the top. At a time determined by the device driver, the data is sent from the buffer to the disk. The driver can combine multiple small reads to efficiently pass data. When you issue a sync(1) command all data is flushed from system buffers to disk regardless. Historically two pushes were required by some systems, hence the advice to sync twice. You can then umount safely. Historically umount didn't always wait for sync to complete, hence syncing first. Clicking on a graphical umount or eject is quite acceptable.
I have come across instances where a USB stick took upwards of 10 minutes to finally sync, so don't assume that things are not working and yank it out regardless.
Re: dd produces useless boot on installation USB
dd has multiple methods of ensuring data integrity. You can use conv=fdatasync or oflag=direct on the dd command itself and then sync is unnecessary.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: dd produces useless boot on installation USB
Judging from the discussion above it seems likely that dd wasn't quite finished although umount didn't complain. Maybe I used eject or safely remove in the graphical menus.
Anyway, I suggest that the dd command in the guidelines is modified to include one of the controls mentioned by TrevorH
Anyway, I suggest that the dd command in the guidelines is modified to include one of the controls mentioned by TrevorH
Desktop Dell T5810 Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz, 72 GB RAM, Radeon Pro WX 7100
CentOS 7.9.2009
CentOS 7.9.2009
Re: dd produces useless boot on installation USB
you cant dd an ISO to a mounted disk
Re: dd produces useless boot on installation USB
If it was mounted then that means you did it wrong and probably explains why it did not work.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke