MX-19 Beta 3 Feedback

[JayM]

Suggestion: try creating a new partition table on the USB stick, either gpt or msdos, which should wipe everything from it, then run LUM again and see if it creates a gpt table this time. I've had instanced where, if I reused a USB stick that had one of the MX-19 betas burned to it and I tried to burn an MX-18 ISO to it, or vice-versa, it wouldn't work unless I completely wiped the USB in gparted first.

This won't help. Live-usb-maker actually wipes the partition table better than gparted does. If you are having trouble with a device behaving properly in gparted then you can try the clear-partition feature of live-usb-maker.

Also, since we wipe out the partition table and start afresh, it doesn't matter what partitioning is originally on the device.

I just used the command line tool live-usb-maker using the --gpt flag and it uses gpt partitioning so I think this is just a minor bug in the gui wrapper.

Thanks for catching it bpr323!

I actually noticed it back in 19b1, when I tried to reuse its USB stick within MX-18 to burn an 18 iso and LUM failed with an error unless I wiped the stick in gparted first by creating a new msdos partition table, but it didn't even occur to me to report it, I don't know why not. I just assumed that 19 did something differently when it burned live USBs and let it go at that. This was using strictly msdos partitioning, both for 18 and 19. So whatever's wrong also needs to be fixed in MX-18's LUM's gui.

[bpr323]

Suggestion: try creating a new partition table on the USB stick, either gpt or msdos, which should wipe everything from it, then run LUM again and see if it creates a gpt table this time. I've had instanced where, if I reused a USB stick that had one of the MX-19 betas burned to it and I tried to burn an MX-18 ISO to it, or vice-versa, it wouldn't work unless I completely wiped the USB in gparted first.

This won't help. Live-usb-maker actually wipes the partition table better than gparted does. If you are having trouble with a device behaving properly in gparted then you can try the clear-partition feature of live-usb-maker.

Also, since we wipe out the partition table and start afresh, it doesn't matter what partitioning is originally on the device.

I just used the command line tool live-usb-maker using the --gpt flag and it uses gpt partitioning so I think this is just a minor bug in the gui wrapper.

Thanks for catching it bpr323!

Do you have a cloud space somewhere I can upload a bunch of s/shots of errors from my failed 19b3 install?
There's 230mib of hi-res mobile phone photos of my laptop screen (45 of them) - I can't be bothered shrinking and posting them here

[asqwerth]

Just upload to a picture hosting site, and provide links to all the pics here instead of shrinking and posting the pics themselves here.

[bpr323]

Uploaded to Google photos - hope you can see them there -
https://photos.app.goo.gl/DirQd11Fs5J54ESq6

[BitJam]

I actually noticed it back in 19b1, when I tried to reuse its USB stick within MX-18 to burn an 18 iso and LUM failed with an error unless I wiped the stick in gparted first by creating a new msdos partition table, but it didn't even occur to me to report it, I don't know why not.

If this happens again, I'd like to see the failed session in /var/log/live-usb-maker.log.

Also, if you have a recipe for creating sticks that will fail, that would be grand but I realize this is a long shot and may not be possible.

My wild guess is that maybe we got tripped up by auto-mounting. The log file should tell us more. I've written LUM live-usbs on top of previous LUM live-usbs literally hundreds of times without a problem like this. But I don't have auto-mounting enabled. If automounting is the problem, I do have an adjust I can make. We may also be able to use the anti-automounting technique that fehlix developed for the installer.

[JayM]

I actually noticed it back in 19b1, when I tried to reuse its USB stick within MX-18 to burn an 18 iso and LUM failed with an error unless I wiped the stick in gparted first by creating a new msdos partition table, but it didn't even occur to me to report it, I don't know why not.

If this happens again, I'd like to see the failed session in /var/log/live-usb-maker.log.

Also, if you have a recipe for creating sticks that will fail, that would be grand but I realize this is a long shot and may not be possible.

My wild guess is that maybe we got tripped up by auto-mounting. The log file should tell us more. I've written LUM live-usbs on top of previous LUM live-usbs literally hundreds of times without a problem like this. But I don't have auto-mounting enabled. If automounting is the problem, I do have an adjust I can make. We may also be able to use the anti-automounting technique that fehlix developed for the installer.

OK, I'll see if I can replicate the problem later and if so I'll post my log file.

[JayM]

@BitJam: I'm unable to replicate the problem now.

Things that are different include my computer (I was using my AMD desktop before but its motherboard failed. I'm currently on an HP laptop), the MX-19 beta version (I encountered the issue with betas 1 and 2) and possibly the version of LUM if it was upgraded in the past two or three months, though I don't see it in my upgrade history (which only starts on 23 September.)

If I encounter the issue again I'll start a new topic for it if it's happening in MX-18, or else post a new reply here if it's in 19b3. There's no point on seeing if I can make LUM fail with 19b1 or 2.1 involved as we've already moved to b3 anyway.

[BitJam]

[...] the MX-19 beta version (I encountered the issue with betas 1 and 2) and possibly the version of LUM if it was upgraded in the past two or three months, though I don't see it in my upgrade history (which only starts on 23 September.)

Thanks for the report JayM! The part of the code that clears the partition table(s) has been stable for a long time. Probably years. I'd be very surprised if it fails. It is possible we are getting tripped up by auto-mounting.

If I encounter the issue again I'll start a new topic for it if it's happening in MX-18, or else post a new reply here if it's in 19b3. There's no point on seeing if I can make LUM fail with 19b1 or 2.1 involved as we've already moved to b3 anyway.

Whatever works for you. I will PM you my email address which is the best way for you to get in touch with me.

[dolphin_oracle]

We will take a look at the lum-gui options and see what's going on with gpt switch not being respected.

[bpr323]

We will take a look at the lum-gui options and see what's going on with gpt switch not being respected.

Just curious - did you have a chance to have a look at my screenshots?
https://photos.app.goo.gl/DirQd11Fs5J54ESq6
Plenty of bug-porn there :)
For starters, minstall-gui just crashes when it can't complete at any step.
I will rephrase - errors are displayed to User, but if s/he persists and selects continue - minstall-gui just spins its wheels. Should just gracefully exit imho.
You have 2 issues that need to be decoupled:
1) lum-gui works, but produces problematic output in ISO
2) ministall-gui either cannot digest the ISO properly -
a) there might be issues with ISO data but minstall-gui just can't handle the exceptions properly, or
b) the ISO data is "mostly" correct, but minstall-gui can't convert it into succesful install
c) or permutations of all of the above, which makes it incredibly difficult to isolate the cascading bugs