[sle-beta] Beta 5, initial impressions

[Joe Doupnik]

     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.
     That future "silly me" check about partitioning errors would be 
most welcomed.
     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