[sle-beta] Beta 5, initial impressions

Jiri Srain jsrain at suse.cz
Wed Jan 24 05:21:40 MST 2018


Hello Joe,

On 24.1.2018 11:28, Joe Doupnik wrote:
>     Comment placed in-line below.
> 
> On 24/01/2018 10:10, Jiri Srain wrote:
>> Hello Joe,
>>
>> On 24.1.2018 10:22, Joe Doupnik wrote:
>>>      SLES 15 beta 5. My overall impression thus far is good, and the
>>> system works as an ESXi guest in my case.
>>>      A few comments about it.
>>>      A fresh installation of beta 5 would not boot: no O/S found. Some
>>> use of Recovery and Update menus to view and refresh disk partitioning
>>> and initrd brought this under control. I must have made a silly error
>>> somewhere in this familiar process. A guess is I defined a /boot
>>> partition, type EXT2 so there is no journal to be replayed, and not
>>> using the offered EFI choice. Root is XFS. Unless others encounter a
>>> similar problem this will remain as a local fluke.
>> Hard to guess from this information, anyway: As you mentioned EFI, you
>> need to have a /boot/efi partition formatted as MS-DOS, otherwise the
>> EFI firmware will not boot.
>>
>> Having (additional) /boot with ext2 should not hurt, although I don't
>> see a use for it.
>>
>> With Beta6, you should get a warning when you do a mistake in
>> partitioning that should prevent booting.
>>
>> Jiri
> ---------
> Jiri,
>     Thanks for that quick clarification.
>     I do not use, nor need, the EFI scheme. I use /boot (EXT2) to avoid
> historical problems merging everything into /. I do not use BTRFS,
> thanks. Historically that /boot partition was/is needed to accommodate
> updating the kernel, where the initrd would not be properly
> reconstructed (root set as XFS). It uses EXT2 to avoid possibly needing
> to update root from a journal during boot while root is still read-only
> (yes, I know about file systems). To avoid all that hassle I use an EXT2
> /boot partition, which works. Just what went wrong in my initial
> installation process is uncertain, but a guess points to /boot and
> initrd composition during the initial installation process because a
> following review of that area resulted in a working version. Could be a
> bug, or just a human error on my part, but I thought the problem worth
> noting while matters are still fluid. Returning "/boot" to the partition
> choice menu would be a wise move.

If you could tar-up the /var/log/YaST2 directory of your system after
installation and send it to me via email (perhaps exclude the mailing
list), I could quickly check it and possibly find what went wrong.

Separate /boot should not hurt; after your last description, it looks
more like improper location of GRUB chosen. Anyway, the logs should say
that.

>     That future "silly me" check about partitioning errors would be most
> welcomed.

As I wrote above, expect it for next Beta, you should get warned if
partitioning does not match the product's or bootloader's requirement.

Jiri
>     Thanks,
>     Joe D.
> 
>>>      Retention of various standard network utilities (say netstat,
>>> telnet
>>> etc) is much appreciated. Yet there remain problems such as xinetd not
>>> installing completely and thus not being usable. What would
>>> significantly help is a document describing the changes/shifts of
>>> direction/replacements so that sysadmins could smoothly cope with the
>>> changes. Presently we are left stranded.  Such a doc could extrapolate
>>> from say SLES11 level to that now in SLES15.
>>>      I appreciate the gradual reordering of material; that is good.
>>> However, in the process some common installation bits are becoming
>>> buried in the overall structure. Examples are setting the screen
>>> resolution and some menus now have their captions truncated and thus be
>>> nearly unusable, ntp being disabled after its usual initial setup,
>>> PackageKit refusing to get out of the way, nearly buried Cert Authority
>>> config in YaST, non-tracking of GUI keyboard language, and so forth.
>>> Thus, for the future I think a good idea would be to identify such
>>> common practice settings and make them be more visible rather than being
>>> relegated levels deep as now.
>>>      It is a bit concerning to see the Apache web server identified as
>>> basically unsupported, and its YaST section gone. There must be a good
>>> reasons for this, yet it would be beneficial for us to have Apache
>>> return as a first class item rather than a DIY item.
>>>      I am pleased to see the system brought to the Openssl v1.1 level
>>> across the board, and having the FIPS option.
>>>      Lastly, I am impressed with how well SUSE is handling the current
>>> CPU chip security issues. That measured approach is valued.
>>>      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

-- 
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