[Rick Stevens wrote:]

If you are unlucky enough to get stuck with a USB thumb drive that has U3
stuff on it, generally they've got it stuffed so that a normal write to
those blocks won't work unless you do some "magic" and delete the U3 stuff
first. If you don't, writing your bootable ISO to it is useless as you
can't overwrite the boot loader on the thumb drive. [end quote]


Even a series of drives that seemed to first not have this sort of thing
(not necessarily U3 but firmware with baggage) seem to later have it or
change the other way around. It is “transparent” to the normal user so why
do they care? To those wishing to use the drive to boot Linux this could be
a game changer...


Other than buy the drive and try it I know of no way to find out ahead of
time.


[Rick Stevens wrote:]

I refuse to buy thumb drives that have that crap on it. God knows what evil
software they've stuffed into it (remember the stupid KVM that had code
that would force your browser to go to a specific website?) [end quote]


I have read that at least at “proof of concept” level they have modified a
drive to “infect” a computer upon insertion. Those who know how to infect
computer firmware – well – a flash drive is probably an easy way in for
them. I never feel safe using thumb drives.


And then there is the performance issue. Optimization information may well
be in the area between the start of the drive and the provided partition.
Change that “front of the drive” soft/firm-ware and you may well slow the
drive to cold molasses levels.


It is not the quickest and easiest way but I seem to have the best luck
simply “shrinking” the provided partition on the drive from the back thus
leaving the front of the drive as it was. Then I do an actual install of
the Linux on the drive using the dive as any other SSD. The results do seem
to consistently perform better.


The biggest problem using Fedora 20 and 22 I have seen while doing this is
the crazy large first update. If the drive and computer are not fast that
can take most of a day. I have much better luck with other distros.


FWIW - I have had some luck loop mounting an ISO contained within the file
system of the main installed Linux from Grub 2 (40_custom 41_custom) and
booting that.


In general I am tending more toward using mSATA SSDs within USB3 containers
for external bootable drives. Not at all free from concern about firmware
but in general cleaner to use and close to price point for a similar size
flash drive. OTOH – not as tiny and easy to carry as a flash drive.
Performance is also much better than a flash drive.

On Fri, Oct 16, 2015 at 6:33 PM, Rick Stevens <ri...@alldigital.com> wrote:

> On 10/16/2015 02:14 PM, Tod Merley wrote:
>
>> What of the device firmware, boot capability contained therein,
>> performance optimization contained in the section between the front of
>> the drive and the start of the provided partition, and and crazy often
>> auto-mount firmware “CD-ROM” provided as a method of device software
>> availability and possible auto-installation in Windows systems set up to
>> do so?
>>
>
> If you are unlucky enough to get stuck with a USB thumb drive that has
> U3 stuff on it, generally they've got it stuffed so that a normal write
> to those blocks won't work unless you do some "magic" and delete the U3
> stuff first. If you don't, writing your bootable ISO to it is useless
> as you can't overwrite the boot loader on the thumb drive.
>
> I refuse to buy thumb drives that have that crap on it. God knows what
> evil software they've stuffed into it (remember the stupid KVM that
> had code that would force your browser to go to a specific website?)
>
>
>>
>> On Fri, Oct 16, 2015 at 9:43 AM, Rick Stevens <ri...@alldigital.com
>> <mailto:ri...@alldigital.com>> wrote:
>>
>>     On 10/16/2015 02:36 AM, Ranjan Maitra wrote:
>>
>>         On Thu, 15 Oct 2015 22:44:20 -0700 Joe Zeff <j...@zeff.us
>>         <mailto:j...@zeff.us>> wrote:
>>
>>             On 10/15/2015 09:14 PM, Ranjan Maitra wrote:
>>
>>                 No, I would not think so. But if the device is not
>>                 mounted, would it not write to the mount point,
>>                 especially because you are doing so as root (so nothing
>>                 to stop you). This logic seems to make sense to me, and
>>                 indeed is what happens when I have done it accidentally
>>                 (without mounting the USB drive).
>>
>>
>>             If the device isn't mounted, there's no mount point for the
>>             command to
>>             write to.
>>
>>
>>         Correct. Then where would it write to?
>>
>>
>>     If you write to a /dev/sd* node, you write to the raw device whether
>>     it's mounted or not. If that device happens to be mounted at the time,
>>     then things are going to get very ugly with the mountpoint as the
>>     filesystem associated with the mountpoint won't necessarily know about
>>     what you've done to the underlying device--the filesystem's idea of
>>     what's on the device will be different than what's actually on the
>>     device. Some programs do take care to not permit you to write to a
>>     raw device if it's mounted to keep this from happening.
>>
>>     Mountpoints are just directories. If you write to the mountpoint
>>     _without_ any device being mounted there, then you write into the
>>     mountpoint directory as you would any directory. If you then mount a
>>     device at that spot, the contents of the device will hide the content
>>     existing in that mountpoint directory until you unmount the device.
>>     Then the content you wrote to that directory will reappear.
>>
>>     In general, if the target of some operation is a node in /dev then do
>>     try to ensure it (or any part of it) is _not_ mounted. One of the
>>     easiest ways is to use "mount | grep <device>", e.g.
>>
>>              mount | grep /dev/sdb
>>
>>     If you don't get any output, then you can be relatively sure that no
>>     part of the physical device /dev/sdb is being used as a filesystem.
>>     ----------------------------------------------------------------------
>>     - Rick Stevens, Systems Engineer, AllDigital ri...@alldigital.com
>>     <mailto:ri...@alldigital.com> -
>>     - AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
>>     -                                                                    -
>>     -         "OK, so you're a Ph.D. Just don't TOUCH anything!"         -
>>     ----------------------------------------------------------------------
>>
>>     --
>>     users mailing list
>>     users@lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>
>>     To unsubscribe or change subscription options:
>>     https://admin.fedoraproject.org/mailman/listinfo/users
>>     Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>     Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>>     Have a question? Ask away: http://ask.fedoraproject.org
>>
>>
>>
>>
>>
>
> --
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer, AllDigital    ri...@alldigital.com -
> - AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> -                                                                    -
> -                       When in doubt, mumble.                       -
>
> ----------------------------------------------------------------------
> --
> users mailing list
> users@lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org
>
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Reply via email to