> May i propose my personal favorite culprit for the next test here ?
> If so, then try what happens if at ISO production time the options
> -part_like_isohybrid -isohybrid-gpt-basdat
> are omitted in order to drop the invalid GPT of the ISO.
Yes, thanks, this was the next thing on the list for us to test. http://cdimage.ubuntu.com/ubuntu/daily-live/20201008/
is now built, with these changes (restore -partition_offset, drop
isohybrid/gpt-basdat options).
@sudodus, @leok, could you please retest on Lenovo V-series with this image?
Reports on other hardware are only relevant if it does boot on the Lenovo
V-series; also, we don't need test reports from using tools that modify the
image when writing to disk.
Hi Thomas,
On Thu, Oct 08, 2020 at 06:56:47AM -0000, Thomas Schmitt wrote:
> so for now -partition_offset 16 is not to blame ?
Appears not.
> The only tangible report was back in 2011 about a Macbook Pro /lists. debian. org/debian- cd/2011/ 04/msg00029. html /lists. debian. org/debian- cd/2011/ 04/msg00060. html /lists. debian. org/debian- cd/2011/ 04/msg00061. html
> https:/
> with decisive test in
> https:/
> and (deplorable) success report in
> https:/
> May i propose my personal favorite culprit for the next test here ?
> If so, then try what happens if at ISO production time the options
> -part_like_ isohybrid -isohybrid- gpt-basdat
> are omitted in order to drop the invalid GPT of the ISO.
Yes, thanks, this was the next thing on the list for us to test. http:// cdimage. ubuntu. com/ubuntu/ daily-live/ 20201008/ gpt-basdat options).
is now built, with these changes (restore -partition_offset, drop
isohybrid/
@sudodus, @leok, could you please retest on Lenovo V-series with this image?
Reports on other hardware are only relevant if it does boot on the Lenovo
V-series; also, we don't need test reports from using tools that modify the
image when writing to disk.