replacing the Startup Disk Creator

[Nio Wiklund]

Hi again Marc,

I have forwarded your questions to the people (at the 'poll thread') in
the Ubuntu Forums.

See my replies inline.

Best regards
Nio

Den 2015-09-17 kl. 17:47, skrev Marc Deslauriers:
> On 2015-09-17 11:26 AM, Nio Wiklund wrote:
...
>> kansasnoob:
>>
>> 1. Aside from SDC being badly borked one of the most annoying design
>> flaws has always been the 10 minute timeout for installing the
>> bootloader. I'm sure I'm not the only one that multi-tasks constantly,
>> and not just at the desk. Watching and waiting for SDC to ask if you
>> want to install the bootloader is about like watching paint dry
>> ............... but if you get distracted for more than 10 minutes after
>> SDC asks about bootloader installation you have to start all over again
> 
> That's a one-line fix. Is there a bug opened for that issue?
> 
>>
>> 2. Bug numbers
>>
>> https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1325801
>>
>> But the proposed "fix" resulted in this:
>>
>> https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1446646
>>
>> My final comment on that bug was here:
>>
>> https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1325801/comments/146
>>
>> S-D-C is borked - it's useless to create live USB's of either older or
>> newer versions of Ubuntu than the version you're running S-D-C on. And
>> the proposed fix that made it into Vivid and got backported into Utopic
>> resulted in S-D-C being able to only produce live USB's of the same
>> architecture.
> 
> Bug 1325801 is being actively worked on.
> 
> Interesting, I can't reproduce bug 1446646. I can create both amd64 and i386
> bootable usb disks for trusty and vivid on my vivid amd64 laptop.
> 
> Is there something special I need to do to reproduce your issue?
> 
> 
>>
>> mc4man:
>>
>> s-d-c worked ok here on 14.04.1 but fails now on installing bootloader
>> with 14.04.2/3. s-d-c does currently work in 15.10 (trying to create
>> 14.04.3 image)
>>
>> sudodus - alias me, Nio:
>>
>> There is also a bug that makes it impossible to 'erase a disk'. I don't
>> know if it has a bug number, but it is there at least in some of the
>> current versions.
> 
> That's probably a udisks issue. It would help to actually have a bug filed for it.

There are several new bugs that seem to address this issue in the long
list from Alberto. In the short (revised) edition I think this one is
relevant:

Erasing disk failed: Error wiping newly created partition, Bug #1460602

https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1460602

My tip for a solution is independent of waiting for udisks to be fixed:

* Wipe the first megabyte (actually mibibyte) *

When the target drive is identified and selected (so that there can be
no mistake), simply wipe the first mibibyte (use dd under the hood to
overwrite it with zeros). This has worked well for me and people I have
helped at the Ubuntu Forums. It is part of mkusb and I have used and
recommended the method for years. mkusb from ppa:mkusb/unstable has a
menu with several alternatives, where the first one (standard) will
create pendrives, that work with for example the s-d-c and Unetbootin.

...

>> mkusb uses bash + zenity + pv, which are available without importing
>> heavy stacks of gtk or kde packages.
> 
> I do hope you're not proposing to replace s-d-c with a bash script that needs
> admin privileges and doesn't use udisks or policykit. That would be a non-starter.
> 

Yes, mkusb is one of the options to replace s-d-c ;-)

1. It is a bash script

Using bash makes is likely to work without changes in new versions of
Ubuntu, because bash is very stable. But I have to check for changes in
zenity, which is not as stable as bash.

2. It needs admin privileges

The s-d-c also needs privileges (at least to write the bootloader, if I
remember correctly). And I think that a tool that is potentially
dangerous, should need admin privileges. In spite of warnings and
checkpoints it can overwrite vital data, if you give it the the wrong
target drive.

3. It doesn't use udisks

I'm glad that mkusb does not use udisks, since it is obviously creating
problems for the s-d-c.

4. It uses 'sudo -H' instead of policykit

mkusb checks that $USER is root and $HOME is root, and before reading
the mkusb help page via the internet, it switches to the standard
non-privileged user. I don't think it will create security problems.

I have seen problems in more than on of the *buntu flavours, that are
caused by policykit. It seems complicated to use. If the Ubuntu policy
is to never accept sudo or gksu/gksudo, mkusb is not accepted in its
current state. Maybe someone can treat it with policykit in the future.