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
Attachment:
signature.asc
Description: signature