D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] 20180906 Ubuntu variants. Dell D430. Normal and recovery start up

 

On 07/09/18 09:54, Eion MacDonald wrote:
> Dear Folk.
> 20180907
> 20180906 Ubuntu variants. Dell D430. Normal and recovery start up.
> 
> What is difference between a 'normal start of Ubuntu 18.04' and
> 'recovery start of Ubuntu 18.04'? Ubuntu default windows manager/display.
> I assume recovery start (boot up) does two things:
> a) It displays the load process line by line  (not done in 'silent
> normal start')
> b) It does not load some items, but what ones?
> What is the real change?
> 
> Machine is a Dell Latitude D430 with
> 2Gb RAM, Intel Core 2 U7600, 1.2 GHz
> [Boots Knoppix 8.2 USB key OK]
> 
> Reason to ask.
> One of our Warrington U3A computer group old computers, a Dell D430,
> (Windows XP then Vista)  was reloaded with Ubuntu 16.04 for a person's
> use for browsing and copy of websites to Libreoffice for their notes for
> a literary group. This has worked very well.
> 
> I recently last week tried to upgrade the machine to Ubuntu 18.04.
> Upgrade was done, however it would not start in a normal start, locked
> and stayed static for a long time, and did not load.
> It did start in a recovery version start up choice and worked well with
> normal Ubuntu '(brownish) Beaver  display environment'
> 
> I assumed a download error in update and re-tried 4 times but this load
> only from recovery menu was consistent. No completion of boot from
> normal start or boot but always OK from recovery booting.
> 
> I replaced Ubuntu 18.04 by Xubuntu 18.04 and find it works well and
> starts normally.
> 
> I understand the Xubuntu folk use a mixture of XFCE and Gnome in this
> version and it works well.
> 
> What in normal Ubuntu desktop environment would cause the problem I saw?
> Any thoughts?
> 

Recovery boot is entirely different from a normal boot - different 
parameters are passed to the kernel and the OS is loaded in a degraded 
state for potential repairs and changes. Recovery will mount the system 
read only for a start and drop you at the 'recovery menu' in Ubuntu 
where you have a whole bunch of options, one of which  is "continue 
normal boot".

If you recovery boot and then choose "continue normal boot" it's not 
unheard of for an unwell system that otherwise won't boot cleanly to 
miraculously somehow drag itself up to a working GUI. This is because 
the operating system has taken a different route to starting up it's 
services and dependencies compared to a standard boot, for want of a 
better phrase.

The difference you notice in the boot messages isn't actually anything 
to do with recovery by the way - you're conflating quite a lot of 
different things here (not surprisingly, this is confusing stuff).

Whether or not your Ubuntu/Debian system prints boot messages to the 
screen (old fashioned linux wall of text during boot) or stays tight 
lipped and just displays a logo (modern plymouth graphical boot) is to 
do with flags passed to the system by the bootloader, specifically the 
"quiet" and "splash" options. In short, the recovery options added to 
the grub menu automatically by Ubuntu differ from the normal boot 
arguments. You can check this yourself by examining the files on any 
Ubuntu/Mint/Debian system and/or modifying them.

Here is a handy tip for the future - you can always get to the grub menu 
by holding the left shift key during power on even if the system 
normally flashes through without showing it. Navigate to the kernel 
entry you want to boot, normally the newest one of course, and hit E to 
edit the line. You'll see the grub boot stanza for your kernel on screen 
which you can edit live. If you delete the "splash" and "quiet" entries 
from the linux line and hit Ctrl+X together the system will boot using 
your modified stanza instead of the default. This is the number one way 
of figuring out why your system won't graphically boot as you'll now 
have a normal boot but with the usual old messages scrolling by - 
hopefully you'll now see where it hangs and goes wrong. See what was 
used to boot your linux box by reading this:

cat /proc/cmdline

It'll have both splash and quiet arguments present unless you've 
manually done something about it. Mine says:

ghost@failbot:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.18.0-pf4-meowski+ root=ZFS=rpool/ROOT/ubuntu ro 
scsi_mod.use_blk_mq=1

Notice I *don't* have either argument present. Personally, I dislike the 
graphical boot *SO* much (on my systems, not fussed about other peoples 
of course) that I permanently disable it as a matter of course. To do this:

# vi /etc/default/grub
Comment out: GRUB_HIDDEN_TIMEOUT=0
Remove quiet and splash from: GRUB_CMDLINE_LINUX_DEFAULT
Uncomment: GRUB_TERMINAL=console
Save and quit
Run update-grub

When setting up complex setups or particularly really new computers like 
laptops with barely supported chipsets it's common to run into all kinds 
of problems initially with modesetting not working, graphics drivers 
bombing out, etc, etc: rather than sitting staring at a blank screen and 
wondering why it doesn't work just follow the steps above to disable the 
"idiot boot" which actively hides all useful diagnostic information and 
put it back to a verbose, useful boot. Afterwards when you've got 
everything sorted out you can always reverse the operation to make a 
nice clean looking boot the default again - this is usually a good idea 
if the end user is the sort who'd be a bit intimidated by walls of text 
flashing by and would prefer a nice animated Ubuntu logo instead.

This would be the first thing I would have done with your misbehaving 
Dell to see what was happening with it. Well, maybe after installing 
sshd of course.

The main take home point from all this is if you have a system that can 
only be started up properly by booting it via the recovery mode entry 
for your kernel of choice and then choosing "resume normal boot" to get 
to GUI login reliably, it needs to be fixed. Dmesg and journalctl to the 
rescue as normal in that case. Don't kid yourself into thinking that 
it's ok just because it reaches a login screen...

XFCE runs a lot lighter than Gnome3 as well, it's not that surprising 
that Gnome wouldn't run out of the box on that creaky old Dell 430. On 
top of everything else don't forget that Gnome3 by default would have 
been trying to start a wayland session instead of a Xorg based one which 
is another massive minefield to negotiate.

Hope some of that might help.

Cheers

-- 
The Mailing List for the Devon & Cornwall LUG
https://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq