Quoting Brian (2019-05-02 16:01:31) > On Thu 02 May 2019 at 15:12:46 +0200, Jonas Smedegaard wrote: > > > Quoting Albretch Mueller (2019-05-02 14:42:08) > > > something like: > > > > > > 1) download the iso's > > > > > > 2) go: <some application> /dev/sdb > > > > > > where "/dev/sdb" is the device a USB disk is linked to > > > > > > then you would plug the disk on your computer and take it from > > > there > > > > > > For that I used to burn live DVD but there should be a better way > > > > Debian ISOs specifically are prepared to be used not only on optical > > drives but also booted from e.g. USB flash drives. > > > > So "the better way" is to simply copy the image onto the device: > > > > sudo cp downloaded_image /dev/sdb > > I use cat downloaded_image > /dev/sdb
Is there some benefit to that over cp? Reason I prefer cp is that it is less confusing esp. for newcomers, in that it works also with sudo. > > There is a cargo cult preaching the use of "dd" but that tool is > > like cutting trees with scissors: The wrong tool for the job! > > > > There are some suggesting to avoid the need for sudo by messing with > > udev rules to grant non-root write access to removable devices. > > When properly established that is indeed more safe, but setting it > > up can go wrong in just as bad and more complex ways to decipher > > than simply mistyping the device name and wiping your main system > > drive. > > This is along the same lines as Message #34 at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751892 > > > To random people reading this bug: please do not EVER do > > this or it may subtly break other things and then get you > > flamed when you will waste my time debugging that. > > Although the issue is treated sympathetically towards the end of the > report, I don't believe I've ever seen an example of subtle breakage. > > I agree with what is said in Message #23 at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788662 > > > In any case, it seems unfortunate that users can no > > longer write an image to a USB disk without using root. > > Especially because that makes it easier to make a mistake > > and overwrite the wrong disk. I've made ahabit of always > > dd'ing as non-root, to make it somewhat less likely that > > I'd overwrite a system disk. > > Which is why I have a udev rule with > > SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy" > > in it. I might stop doing that if its use was demonstrated to have an > adverse effect on other things I do. Good for you that you have a hack that works. Really! Reason I discourage that approach more generally is not that I want to "flame" anyone (as in that bugreport you referenced aboe), but that I seek ways reasonable also for non-technical users: Your udev hack is more (not less) complicated for a non-technical user to do right compared to my one-liner sudo+cp command. Your approach is sensible if doing _many_ such operations, but not when doing few, as a beginner. At http://box.redpill.dk/ I currently use these initial steps: [...] 2) Connect microSD card to pc, and locate its device path: * On linux, try this command: lsblk --paths --nodeps * On macOS, try this command: ls /dev/rdisk? * Compare output of above command with and without card plugged in to not COMPLETELY OVERWRITE the wrong device below 3) Make sure card is (connected but) not mounted: * On linux, check that lsblk lists no mountpoint entry 4) Decompress and copy image onto card (adjust image name and device path as needed): gunzip core-lime2-1.0b22.img.gz sudo cp core-lime2-1.0b22.img PATH_TO_YOUR_SDCARD [...] That's not the method I use myself when testing those images over and over again, but the most sensible I have found so far for general use, also for those not fluent in shell pipes and udevadm queries and such... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
