<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"> Pre-pending here the results of the
current installation process.<br>
This time I ticked the menu boot area item saying install the
boot material into the MBR, rather than the default setting of in
the /boot partition. The system has rebooted properly to complete
the installation process. Thus there appears to be some difficulty
in that area of the installation material.<br>
Thanks,<br>
Joe D.<br>
<br>
On 05/02/2018 09:58, Joe Doupnik wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1d7b9dce-c1ac-59af-8014-785d2d1a746e@netlab1.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix"> Fresh installation, found again
the new /boot message. Here are screen captures:<br>
<br>
<img src="cid:part1.2195F2D3.6342DD35@netlab1.net" alt=""
class="" height="321" width="709"><br>
<br>
And after saying No, we again see the underlying layout:<br>
<img src="cid:part2.38E13D49.95931210@netlab1.net" alt=""
class="" height="359" width="711"><br>
<br>
No UEFI choices were selected. Going to the lower right
corner "Expert" button and saying please recreate the
partitioning, and there selecting the classical non-UEFI mode,
the same /boot popup occurs.<br>
<img src="cid:part3.6AB03B91.85202021@netlab1.net" alt=""
class=""><br>
<br>
Enlarging /boot to be 256MB does not change the results.
Thus the message remains obscure.<br>
I am selecting to continue the installation to see what
happens.<br>
Thanks,<br>
Joe D.<br>
<br>
<br>
On 05/02/2018 09:08, Joe Doupnik wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6732d4ad-5186-e5dc-c88e-fb300ca62fc0@netlab1.net">On
04/02/2018 23:07, Thorsten Kukuk wrote: <br>
<blockquote type="cite">On Sun, Feb 04, Joe Doupnik wrote: <br>
<br>
<blockquote type="cite"> The second test was with one CD,
as just mentioned. The peculiar item <br>
observed thus far was when partitioning. I said please redo
the layout with <br>
the offered existing partitions, I removed all shown for the
only drive, and <br>
I created my usual three of BOOT (/boot, EXT2, 128MB), SWAP
(swap, 512MB), <br>
and ROOT (/, 6.xGB). <br>
</blockquote>
No idea why people still use this extra /boot partition. This
has not <br>
a single advantage, but a lot of disadvantages. <br>
Nobody would come to the idea to put /lib64 with libc and
everything <br>
on an extra partition, so why divide the kernel or bootloader
in two <br>
parts and put them on two different partitions? This only
makes trouble <br>
and was only necessary in the past for broken BIOS versions.
But that <br>
problem should have gone long ago. <br>
<br>
Thorsten <br>
<br>
</blockquote>
------------- <br>
To clarify matters for Thorsten and other readers. A while
ago I covered similar territory. <br>
The /boot story as I relate it goes like this. With earlier
SLES editions I created a two partition scheme, root (/, XFS)
and swap. That worked until a kernel upgrade was installed and
then the system would not boot. I infer the reason was the new
initrd did not have the XFS intelligence. Additionally, if that
root had outstanding journal entries at boot time then grub
would be unable to perform them because root was mounted
read-only at that moment. Consequently the system may not boot.
<br>
These aspects are not BIOS related, yet reaching a bootable
partition can be BIOS dependent which is why a bootable
partition should be created before other large partitions. <br>
However, if I create a boot partition, type EXT2 (no
journal, no XFS), followed by swap and root (XFS) partitions
then all is well through patches and major upgrades. My surmise
is composition of a workable initrd and relatives is the key
factor, with their understanding of XFS being an important
thread. <br>
That's been my experience. Details today may have changed
and to know would take a bunch of validation experiments. I know
this can seem to be a reactionary view, but setting aside BTRFS
the problem has been real enough for a long time and is easily
avoided by having the /boot partition. Further, using a /boot
partition ought not clobber a new SLES and certainly should not
be a notable disadvantage. <br>
<br>
For SLES 15 beta 6, there is that new /boot popup complaint
message to learn about. My memory says there could have been two
disks, sda and sdb, shown in the partition menu, even though
only one hard disk was created for the ESXi virtual machine, and
the sdb one had a boot reference. That's my vague memory. At
this moment I have restarted that test virtual machine after
removing the second CD drive. It did not boot, saying no o/s,
but I could enter Rescue mode. After poking about the boot
partition (sda1) I did not find a menu.lst file which is
normally present for SLES11 and prior. I am about to remove that
virtual machine and rebuild with only one CD drive. In any case,
the double CD drive presence during installation has led to
trouble in beta 6, plus that new /boot popup message. <br>
Thanks, <br>
Joe D. <br>
<br>
_______________________________________________ <br>
sle-beta mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:sle-beta@lists.suse.com" moz-do-not-send="true">sle-beta@lists.suse.com</a>
<br>
<a class="moz-txt-link-freetext"
href="http://lists.suse.com/mailman/listinfo/sle-beta"
moz-do-not-send="true">http://lists.suse.com/mailman/listinfo/sle-beta</a>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
sle-beta mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sle-beta@lists.suse.com">sle-beta@lists.suse.com</a>
<a class="moz-txt-link-freetext" href="http://lists.suse.com/mailman/listinfo/sle-beta">http://lists.suse.com/mailman/listinfo/sle-beta</a>
</pre>
</blockquote>
<br>
</body>
</html>