[Bug 411068] New: opensuse 11.0 fails to install from network
https://bugzilla.novell.com/show_bug.cgi?id=411068
Summary: opensuse 11.0 fails to install from network
Product: openSUSE 11.0
Version: Final
Platform: PowerPC-64
OS/Version: All
Status: NEW
Severity: Blocker
Priority: P5 - None
Component: Installation
AssignedTo: bnc-team-screening@forge.provo.novell.com
ReportedBy: bugproxy@us.ibm.com
QAContact: jsrain@novell.com
Found By: Third Party Developer/Partner
Partner ID: LTC 46592
=Comment: #0=================================================
Carlos Roberto Do Nascimento Costa
https://bugzilla.novell.com/show_bug.cgi?id=411068
Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c1
--- Comment #1 from Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c2
LTC BugProxy
ideally, firmware should automatically rebase itself, based on the NOTE content.
The firmware 'rebasing' should be done in the addnote program, I guess. Is it enough to patch addnote.c to update the real-base value with the inst64 file size? The attachment #37961 gives an idea of the necessary modifications to the addnote.c code. Suggestions and comments are welcome. Regards, Luiz Fernando. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c3
--- Comment #3 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c4
--- Comment #4 from LTC BugProxy
------- Comment From olh@novell.com 2008-07-22 06:54:34 MDT------- I have changed the link address to 64MB in the meantime, so 11.0alpha1 and later should boot if the real-base is set manually.
Does this mean you have taken the patch at: http://patchwork.ozlabs.org/linuxppc/patch?id=19152 ?
but ideally, firmware should automatically rebase itself, based on the NOTE content.
With the patch above OF will relocate itself based on the NOTE in the zImage, as long as the image can be successfully loaded. Sadly this is a chicken and egg situation, were the OF design (which is to process the ELF section after loading the first 2k of the binary) isn't replicated in real-world testing. ------- Comment From tbreeds@au1.ibm.com 2008-07-22 21:19 EDT------- (In reply to comment #10)
The attachment #37961 [edit] gives an idea of the necessary modifications to the addnote.c code.
Suggestions and comments are welcome.
The patch doesn't take into account load-base nor alignment constraints of OF. Better to just change the value on desc[2] from 12Mb to 32Mb unconditionally. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c5
--- Comment #5 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c6
--- Comment #6 from LTC BugProxy
As you mentioned, I must take into account the load-base value and the OF alignment constraints when changing the real-base value. But, as far as I could understand, the crucial point here is to ensure that the reserved space for loading the bootloader is enough, or, in other words, it must be ensured that ($real-base - $load-base) > $bootloader_size.
Sure, but the patch didn't adjust for load-base, I wanted that pointed out to prevent it being used in the short term. IIRC load-base isn't set by addnote (yet), so you can't know how far to offset to accommodate it. You can guess (or override the default with the NOTE) but at that point you're no better off than the mainline patch.
In the 'pseudo-patch' I've sent, I really didn't take into account any OF alignment constraint or load-base value (that I think it must stay unchanged). I just shifted the real-base pointer in order to increase the space for loading the bootloader correctly. What kind of alignment must I take into consideration when changing the real-base pointer? Is there an upper limit up to where I can shift the real-base value? Modifying the real-base value isn't enough?
In theory 4k alignment is adequate, but I think in practice you'd be best to align to a 1Mb boundary. You can set load-base to (IIRC) any address that is: * 1Mb aligned * Inside the RMR (usually 128Mb) * Allows room for real-size, RTAS and the decompressed kernel, above OF and below RTAS. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c7
--- Comment #7 from LTC BugProxy
IIRC load-base isn't set by addnote (yet), so you can't know how far to offset to accommodate it. You can guess (or override the default with the NOTE) but at that point you're no better off than the mainline patch.
In the addnote code, load-base is set to 0x4000 (16kB): --- #define N_DESCR 6 unsigned int descr[N_DESCR] = { 0xffffffff, /* real-mode = true */ 0x00c00000, /* real-base, i.e. where we expect OF to be */ 0xffffffff, /* real-size */ 0xffffffff, /* virt-base */ 0xffffffff, /* virt-size */ 0x4000, /* load-base */ }; .. for (i = 0; i < N_DESCR; ++i, ns += 4) PUT_32BE(ns, descr[i]); .. /* write back */ lseek(fd, (long) 0, SEEK_SET); i = write(fd, buf, n); --- The PUT_32BE fills up the buf array, that is, then, used to write the information to the bootloader file. So, unless it is also set in another place, the load-base value is manipulated at addnote.
In theory 4k alignment is adequate, but I think in practice you'd be best to align to a 1Mb boundary.
In fact, load-base is 4k aligned in addnote.c.
You can set load-base to (IIRC) any address that is: * 1Mb aligned * Inside the RMR (usually 128Mb) * Allows room for real-size, RTAS and the decompressed kernel, above OF and below RTAS.
Here, I have some questions. RMR is the total amount of memory available for the partition? How can I know the RMR total size? How memory is partitioned here? I mean, in what order things are positioned? OF -> bootloader -> RTAS -> uncompressed kernel? How can I get/manipulate the limits of each of them? Regards, Luiz. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=411068
User hannsj_uhl@de.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c8
Hanns-Joachim Uhl
https://bugzilla.novell.com/show_bug.cgi?id=411068
User stbinner@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c9
Stephan Binner
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c10
--- Comment #10 from LTC BugProxy
In the addnote code, load-base is set to 0x4000 (16kB):
Ahh cool. I don't recall that being there but it clearly is. so: desc[1] = REAL_BASE_ALIGN(size + desc[5]); were you can decide on the defn. of REAL_BASE_ALIGN() is up to you.
In fact, load-base is 4k aligned in addnote.c.
We're talking about real-base not load-base. As I said I expect 4k is probably adequate but 1Mb is safer.
Here, I have some questions. RMR is the total amount of memory available for the partition? How can I know the RMR total size? How memory is partitioned here? I mean, in what order things are positioned? OF -> bootloader -> RTAS -> uncompressed kernel? How can I get/manipulate the limits of each of them?
RMR is /usually/ 128Mb but that's not a rule, to the best of my knowledge. The typical layout looks like: 0 -> interrupt_data -> space1 -> OF(@real-base) -> space2 -> RTAS -> End of RMR The kernel is normally tftp'd into space1 (load-base), and then decompressed into space2. The size of OF is available in real-size (IIRC). I don't think the location of RTAS, or it's size are obtainable. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c11
Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c12
--- Comment #12 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c13
--- Comment #13 from Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c14
--- Comment #14 from Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c15
--- Comment #15 from Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c16
--- Comment #16 from LTC BugProxy
------- Comment From olh@novell.com 2008-09-09 01:41:39 MDT------- Any news here? What did the firmware team say about the firmware expectations?
Sorry for the slow reply. Tony was working this from our side, but I forgot his wife is having a baby and that he will thus be unavailable for awhile. Ultimately the belief is that the yaboot from SLES10 (SP2) will not as a practical matter suffer from this problem on Power5 or Power6 machines. The yaboot in use by OpenSUSE will. If SLES11 keeps the yaboot from SLES10 (SP2) everything should (crosses fingers) continue working even with the larger image sizes. Longer term we should make sure the support in yaboot to tftp boot from split images is functional and see if any changes need to be done in the way the kernel is packaged. Tony was looking into that, and will probably pick that up when he returns. I don't claim to know all the details of that investigation myself. But for the SLES11 timeframe I'd suggest just running with the SLES10SP2 yaboot. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c17
Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c18
--- Comment #18 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c19
--- Comment #19 from Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c20
--- Comment #20 from LTC BugProxy
openSUSE installation program v3.3.3 (c) 1996-2008 SUSE Linux Products GmbH <<<
Starting udev... sd 0:0:1:0: [sda] Assuming drive cache: write through sd 0:0:1:0: [sda] Assuming drive cache: write through ok Loading basic drivers... ok Starting hardware detection... ok (If a driver is not working for you, try booting with brokenmodules=driver_name.) IBM Virtual SCSI 0 drivers: ibmvscsic* IBM Virtual Ethernet card 0 drivers: ibmveth* Sending DHCP request to eth0... *** Could not find the openSUSE Repository. Activating manual setup program.
Linuxrc v3.3.3 (Kernel 2.6.27-rc6-7-ppc64) <<<
Main Menu 1) Start Installation 2) Settings 3) Expert 4) Exit or Reboot
I hope that was useful. I will open a new bug for sles11, and post our 'workaround' for the issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c21
--- Comment #21 from Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c22
--- Comment #22 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c23
--- Comment #23 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c24
--- Comment #24 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c25
--- Comment #25 from Olaf Hering
https://bugzilla.novell.com/show_bug.cgi?id=411068
User bugproxy@us.ibm.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c26
--- Comment #26 from LTC BugProxy
https://bugzilla.novell.com/show_bug.cgi?id=411068
User olh@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411068#c27
Olaf Hering
participants (1)
-
bugzilla_noreply@novell.com