mx-live-usb-maker inconsistency

Report Bugs, Issues and non- package Requests
Message
Author
User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: mx-live-usb-maker inconsistency

#11 Post by BitJam »

Adrian wrote:I don't think we use that in mx-lum, I think D_O meant he used that in lum-gui which was the old GUI. We'll have to implement that or simply add && sync after the dd command to make sure everything is synced before we pop-up the message "Process done"
Why aren't you using my dd-live-usb?
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

skidoo
Posts: 753
Joined: Tue Sep 22, 2015 6:56 pm

Re: mx-live-usb-maker inconsistency

#12 Post by skidoo »

may easily have not had success if I had removed the stick too early, believing the message that the write had successfully completed when it clearly had not.
Yep, that would explain some of the otherwise inexplicable bug reports which have trickled in.
dd bs=1M if=source of=/dev/usb_device
should there be another parameter?

Code: Select all

if (ui->cb_dd->isChecked()) {
        cmdstr = QString("dd bs=1M if=" + source + " of=/dev/" + device);
"appending sync to the commandline" does not provide a fix; the sync command immediately returns; it doesn't wait to return until all data is written.
So consider adding the oflag=fsync option (flag) to the dd call...
"dd bs=1M conv=fdatasync if=" + source + " of=/dev/" + device
...and, for surety, append ";umount" or "&& umount" to the commandline

User avatar
Adrian
Developer
Posts: 8248
Joined: Wed Jul 12, 2006 1:42 am

Re: mx-live-usb-maker inconsistency

#13 Post by Adrian »

Why aren't you using my dd-live-usb?
Not sure, maybe I didn't know about it, maybe I thought dd should be sufficient, maybe because it's a bit cumbersome to source scripts in Qt and then run commands in that environment.

User avatar
dolphin_oracle
Developer
Posts: 19922
Joined: Sun Dec 16, 2007 1:17 pm

Re: mx-live-usb-maker inconsistency

#14 Post by dolphin_oracle »

BitJam wrote:
Adrian wrote:I don't think we use that in mx-lum, I think D_O meant he used that in lum-gui which was the old GUI. We'll have to implement that or simply add && sync after the dd command to make sure everything is synced before we pop-up the message "Process done"
Why aren't you using my dd-live-usb?
Honestly we were duplicatin lum-gui which had a dd mode already.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.

User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: mx-live-usb-maker inconsistency

#15 Post by BitJam »

We must be imperfect, mortal human beings. Bummer.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

User avatar
Paul..
Posts: 1777
Joined: Sun Mar 18, 2007 6:34 pm

Re: mx-live-usb-maker inconsistency

#16 Post by Paul.. »

BitJam wrote:We must be imperfect, mortal human beings. Bummer.
That usually hits me when I roll out of bed at 6am.

Asus Prime X570-Pro | AMD Ryzen 7 3700X
16 Gig DDR4 3600 | Radeon RX 5600 XT Graphics
Samsung 860 500GB SSDs (2)

User avatar
greywolf
Posts: 40
Joined: Sun Apr 20, 2008 9:06 pm

Re: mx-live-usb-maker inconsistency

#17 Post by greywolf »

One extra thought I had guys, as I did not recall this happening on my MX17 install at all ( and I write LOTS of sticks). This machine has 16Gb memory. Would that make a difference to the size of the buffering mentioned; and therefore to the speed with which the process thinks it is finished?

I have used the 'oflag=fsync' option as well as 'status=progress' from cli on occasion. Also, bs=4M if writing to a usb3 port occasionally. Otherwise, quoted command plus && sync is all that is required. I always follow return of prompt (irrespective of printed messages) with a separate command for 'sudo eject /dev/sdX' just to make sure it is unmounted and ready to remove. Waiting for the prompt return for the eject command ensures all writing and syncing is completed.

I think this is solved from my initial query POV - but if anyone wants more testing done, I'm happy to oblige.

greywolf.
It is about the Dragons - it was always about the Dragons!

User avatar
Adrian
Developer
Posts: 8248
Joined: Wed Jul 12, 2006 1:42 am

Re: mx-live-usb-maker inconsistency

#18 Post by Adrian »

BitJam wrote:Why aren't you using my dd-live-usb?
I could use dd-live-usb in my mx-live-usb-maker Qt program, but I would need a couple of improvements to the script first, see this:

Code: Select all

Shall we begin?
> [7myes
> no
Press <Enter> to select the highlighted entry
Use 'r' to redraw, 'q' to quit

[s
Can we have a --gui or --no-prompts (or whatever switch name you prefer) that turns the prompts off? I could add interactive console in my program, I had that briefly enabled and ask people to type "yes" or press Enter, but I think it should work without prompting.

Also notice that there's some escape code that cannot interpreted in Qt box (I did use --color=off), like [7m and [s (I try to filter as much as I can in my code, but it's probably best if it's not there in the first place) can we remove as much as possible if we add that --gui switch?

Also, can we have this updated on both MX16 and MX17 since mx-live-usb-maker deb is common for both releases and I don't want to split the code.

So... if you make those changes and somebody updates the package on both MX16 and MX17 and somebody lets me know it's done I can very easily add this to mx-live-usb-make instead of "dd".

User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: mx-live-usb-maker inconsistency

#19 Post by BitJam »

Adrian wrote:Can we have a --gui or --no-prompts (or whatever switch name you prefer) that turns the prompts off? I could add interactive console in my program, I had that briefly enabled and ask people to type "yes" or press Enter, but I think it should work without prompting.
TLDR: just add the dirty_bytes code to your existing program.

YES! I already did this with live-usb-maker for Dolphin's wrapper. Instead of turning off the color, I created a .progress log file that can be tailed to see what is going on. One difficulty might be the progress bar. I designed the interface to work with yad. You use "--" on the command line followed by the program I should call for the progress bar. I will send it numbers on stdin between 0 and 100. You can even test it with the existing command line lum. Just give it "--" followed by the program and args. I have a little progress-host test script you can use for testing this. A callback really seemed like the cleanest way.
So... if you make those changes and somebody updates the package on both MX16 and MX17 and somebody lets me know it's done I can very easily add this to mx-live-usb-make instead of "dd".
Cool! I will add it to my list. Thanks!

Another way is to add the dirty_bytes calls to your existing code. The shell code is in a post by Dolphin above. It is maybe a dozen lines and the translation to C++/QT should be very easy. I suggest you do it this way. It might even be easier for you and it takes no work on my part.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

Post Reply

Return to “Bugs and Non-Package Requests Forum”