[sle-beta] SLES15 beta 6, initial observation

Joe Doupnik jrd at netlab1.net
Mon Feb 5 09:07:04 MST 2018


Jiri and the group,
     The choice of using the MBR was just an experiment. Normally I 
would choose to put the boot code in /boot, which is the default. But 
there seems to be some current difficulty with even the concept of /boot 
partition itself existing. Nonetheless, the new /boot warning popup 
exists at partition time, and I do not know why it is appearing.
     Thanks,
     Joe D.

On 05/02/2018 13:01, Jiri Srain wrote:
> Hello Joe,
>
> as I'm reading from the screenshots (you can confirm that): You selected
> the MS-DOS partition table and bootloader installation into MBR.
>
> This is scenario which really _usually_ works; GRUB's code can be put
> into the ext2 partition (in your case as /boot), which may not be always
> reliable.
>
> That's why we better show a warning; if you know what you are doing, you
> can override it and continue installation - and in many cases it will
> work, we just cannot guarantee that.
>
> Adding the additional BIOS Boot partition is a safer solution, you don't
> need to put the GRUB code into the ext2 filesystem and reference it via
> block numbers.
>
> Jiri
>
> On 5.2.2018 11:42, Joe Doupnik wrote:
>>      Pre-pending here the results of the current installation process.
>>      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.
>>      Thanks,
>>      Joe D.
>>
>> On 05/02/2018 09:58, Joe Doupnik wrote:
>>>      Fresh installation, found again the new /boot message. Here are
>>> screen captures:
>>>
>>>
>>>
>>>      And after saying No, we again see the underlying layout:
>>>
>>>
>>>      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.
>>>
>>>
>>>      Enlarging /boot to be 256MB does not change the results. Thus the
>>> message remains obscure.
>>>      I am selecting to continue the installation to see what happens.
>>>      Thanks,
>>>      Joe D.
>>>
>>>
>>> On 05/02/2018 09:08, Joe Doupnik wrote:
>>>> On 04/02/2018 23:07, Thorsten Kukuk wrote:
>>>>> On Sun, Feb 04, Joe Doupnik wrote:
>>>>>
>>>>>>       The second test was with one CD, as just mentioned. The
>>>>>> peculiar item
>>>>>> observed thus far was when partitioning. I said please redo the
>>>>>> layout with
>>>>>> the offered existing partitions, I removed all shown for the only
>>>>>> drive, and
>>>>>> I created my usual three of BOOT (/boot, EXT2, 128MB), SWAP (swap,
>>>>>> 512MB),
>>>>>> and ROOT (/, 6.xGB).
>>>>> No idea why people still use this extra /boot partition. This has not
>>>>> a single advantage, but a lot of disadvantages.
>>>>> Nobody would come to the idea to put /lib64 with libc and everything
>>>>> on an extra partition, so why divide the kernel or bootloader in two
>>>>> parts and put them on two different partitions? This only makes trouble
>>>>> and was only necessary in the past for broken BIOS versions. But that
>>>>> problem should have gone long ago.
>>>>>
>>>>>     Thorsten
>>>>>
>>>> -------------
>>>>      To clarify matters for Thorsten and other readers. A while ago I
>>>> covered similar territory.
>>>>      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.
>>>>      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.
>>>>      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.
>>>>      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.
>>>>
>>>>      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.
>>>>      Thanks,
>>>>      Joe D.
>>>>
>>>> _______________________________________________
>>>> sle-beta mailing list
>>>> sle-beta at lists.suse.com
>>>> http://lists.suse.com/mailman/listinfo/sle-beta
>>>
>>>
>>> _______________________________________________
>>> sle-beta mailing list
>>> sle-beta at lists.suse.com
>>> http://lists.suse.com/mailman/listinfo/sle-beta
>>
>>
>> _______________________________________________
>> sle-beta mailing list
>> sle-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sle-beta
>>



More information about the sle-beta mailing list