[sle-beta] SLES15 beta 6, initial observation
Jiri Srain
jsrain at suse.cz
Mon Feb 5 06:01:28 MST 2018
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
>
--
Regards,
Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: jsrain at suse.com
Krizikova 148/34 tel: +420 284 084 659
186 00 Praha 8 fax: +420 284 084 001
Czech Republic http://www.suse.com
More information about the sle-beta
mailing list