On Wed, 2015-08-12 at 19:23 +0200, Jan Engelhardt wrote:

On Wednesday 2015-08-12 13:23, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2015-08-12 at 10:10 +0000, Ludwig Nussel wrote:

...

==== cdrkit-cdrtools-compat ==== Subpackages: genisoimage icedax wodim

With this we actually expect to have solved the issue of the ISOs not booting on UEFI systems when transferred to a USB stick.

Any reason normal mkisofs is not used?

WIP - I guess it's a forgotten remnant that was never switched in kiwi. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Alright. At least the updating part does not work. Running zypper dup results *again* in a non-booting system. Am 12.08.2015 um 19:52 schrieb gargamel704:

Thanks for the info.

I am trying right now.

Cheers

Am 12.08.2015 um 13:23 schrieb Dominique Leuenberger / DimStar:

...

On Wed, 2015-08-12 at 10:10 +0000, Ludwig Nussel wrote:

...

==== cdrkit-cdrtools-compat ==== Subpackages: genisoimage icedax wodim

With this we actually expect to have solved the issue of the ISOs not booting on UEFI systems when transferred to a USB stick.

Please test the latest 0811 ISOs and report back.

Cheers, Dominique

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

As I said. The system was unable to boot. It essentially got stuck at the loading ramdisk stage. As for the options: No. I assumed that the installer handles this. I installed the snapshot from 15.05 (or so). Note that this behavior has nothing to do with updating from this old snapshot. I had exactly the same issue when installing a very recent snapshot from the disk and after normally rolling with TW. Why is an unmaintained fork used at all? Are there no alternatives? Cheers Am 13.08.2015 um 11:11 schrieb Joerg Schilling:

gargamel704 wrote:

...

Alright. At least the updating part does not work. Running zypper dup results *again* in a non-booting system. What problems do you have?

Note that genisoimage is an unmaintained fork from mkisofs and based on originalk code from May 2004. At that time, UEFI did not exist.

The original mkisofs added UEFI support in June 2011 with collaboration from Oracle. See the options:

-eltorito-platform together with multi-boot for UEFI methods

-modification-date to set up something usable as "UUID"

Did you use the UEFI related options?

Jörg

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I am using on the harddrive btrfs, it did boot with all earlier snapshots ofc. As far as I can tell the bootloader has not changed in a while. Only the Kernel and the FS specific stuff. Am 13.08.2015 um 12:57 schrieb Joerg Schilling:

gargamel704 wrote:

...

As I said. The system was unable to boot. It essentially got stuck at the loading ramdisk stage. I did not read all messages as the Subject is not cdrtools related....

Does this mean that it did boot first?

...

As for the options: No. I assumed that the installer handles this. I The genisoimage program is not compatible to mkisofs. Around 2006, the Debian people changed some options back to a behavior that was annouced as deprecated in 2000 already and disabled in the code around 2004.

There may be a need to change the caller of mkisofs to match the documented behavior again.

...

installed the snapshot from 15.05 (or so). Note that this behavior has nothing to do with updating from this old snapshot. I had exactly the same issue when installing a very recent snapshot from the disk and after normally rolling with TW. If the bootloader successfully loaded into memory, there may be a problem with the filesystem support in the bootloader or kernel.

Is my assumption correct, that the primary bootloader could be loaded and started and then does not finish with loading the ramdisk?

What filesystem flavor do you use on the medium?

...

Why is an unmaintained fork used at all? Are there no alternatives? This was a result from political pressure from Debian. Suse switched back to the original software in 2013 because the Debian fork is unmaintained since May 2007, but this did not seem to have caused results in the install group yet.

Jörg

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I'd do it but how? Am 13.08.2015 um 13:40 schrieb Joerg Schilling:

gargamel704 wrote:

...

I am using on the harddrive btrfs, it did boot with all earlier snapshots ofc. As far as I can tell the bootloader has not changed in a while. Only the Kernel and the FS specific stuff. You need to find out whether the ramdisk was loaded completely.

After that step, it depends on what FS you are using inside the ramdisk.

Jörg

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

gargamel704 wrote:

As I said. The system was unable to boot. It essentially got stuck at the loading ramdisk stage.

The problem you have is unrelated to the unbootable installation media. Might be worth a bug report. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I just tested Debian testing with the same result. Boot is stuck during the "Loading ramdisk" stage. Seems to be a bigger problem... Am 13.08.2015 um 12:42 schrieb gargamel704:

As I said. The system was unable to boot. It essentially got stuck at the loading ramdisk stage.

As for the options: No. I assumed that the installer handles this. I installed the snapshot from 15.05 (or so). Note that this behavior has nothing to do with updating from this old snapshot. I had exactly the same issue when installing a very recent snapshot from the disk and after normally rolling with TW.

Why is an unmaintained fork used at all? Are there no alternatives?

Cheers

Am 13.08.2015 um 11:11 schrieb Joerg Schilling:

...

gargamel704 wrote:

...

Alright. At least the updating part does not work. Running zypper dup results *again* in a non-booting system. What problems do you have?

Note that genisoimage is an unmaintained fork from mkisofs and based on originalk code from May 2004. At that time, UEFI did not exist.

The original mkisofs added UEFI support in June 2011 with collaboration from Oracle. See the options:

-eltorito-platform together with multi-boot for UEFI methods

-modification-date to set up something usable as "UUID"

Did you use the UEFI related options?

Jörg

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Could be. I have not reinstalled Tumbleweed yet. For Debian testing your suggestion did not work. Am 13.08.2015 um 13:54 schrieb Wolfgang Bauer:

Am Donnerstag, 13. August 2015, 13:03:27 schrieb gargamel704:

...

I just tested Debian testing with the same result. Boot is stuck during the "Loading ramdisk" stage.

Seems to be a bigger problem... Maybe it's a problem with the microcode update, like in https://bugzilla.opensuse.org/show_bug.cgi?id=913996 ? (AFAIK this is not openSUSE specific, and shows exactly this symptom)

Try disabling it by adding "udis_ucode_ldr" to the kernel boot options, i.e. press 'e' at the boot menu and append this to the line starting with "linux"/"linuxefi". Then press 'F10' to boot.

Hope that helps.

Kind Regards, Wolfgang

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

The same happens now if I try to boot the stick in UEFI mode. Also the dis_ucode_ldr parameter does not help there... Am 13.08.2015 um 14:14 schrieb Wolfgang Bauer:

Am Donnerstag, 13. August 2015, 14:08:38 schrieb gargamel704:

...

Could be. I have not reinstalled Tumbleweed yet. For Debian testing your suggestion did not work. Sorry, the correct option would be "dis_ucode_ldr". No idea where that superfluous 'u' came from...

Kind Regards, Wolfgang

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, 13. August 2015, 14:53:50 schrieb gargamel704:

The same happens now if I try to boot the stick in UEFI mode. Also the dis_ucode_ldr parameter does not help there...

Well, this has helped a couple of people in the recent past, so I thought it was worth a shot. I have no idea then, sorry. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org