recent linux versions 44 and 45 do not start up

[Jan Kok]

Beginning of the start-up error messages:
Kernel panic - not syncing VFS: Unable to mount root fs on unknown-block(0,0)

I modified menu.lst to use version 43 (/boot/vmlinuz-4.15.0-43-generic) as its first choice, version 43 still works fine.
Thanks for your help, --Jan Kok

Description: Ubuntu 18.04.1 LTS
Release: 18.04

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-43-generic 4.15.0-43.46
ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
Uname: Linux 4.15.0-43-generic i686
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: jan 1335 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Tue Feb 5 23:05:01 2019
HibernationDevice: RESUME=UUID=5a7ff351-aa16-4ca3-afa5-53e73f6e3279
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: Dell Inc. Inspiron 530
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: root=UUID=a93c0ea6-df02-4670-83a1-94cbc22b6598 ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-43-generic N/A
 linux-backports-modules-4.15.0-43-generic N/A
 linux-firmware 1.173.3
RfKill:

SourcePackage: linux
UpgradeStatus: Upgraded to bionic on 2019-01-09 (27 days ago)
WpaSupplicantLog:

dmi.bios.date: 06/20/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.0.15
dmi.board.name: 0K216C
dmi.board.vendor: Dell Inc.
dmi.board.version: ���
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: OEM
dmi.modalias: dmi:bvnDellInc.:bvr1.0.15:bd06/20/2008:svnDellInc.:pnInspiron530:pvr:rvnDellInc.:rn0K216C:rvr:cvnDellInc.:ct3:cvrOEM:
dmi.product.name: Inspiron 530
dmi.sys.vendor: Dell Inc.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Stefan Bader (smb)]

This problem sounds like it might be related to problems in the setup but not the kernels themselves. Is /boot a separate filesystem (which possibly is out of space)? Looking into /boot, are all initrd* and vmlinux* files report a roughly similar size (du -h)? Unfortunately a bit messy to read but looking at /boot/grub/grub.cfg, do the references to the root disk (usually UUIDs) make sense?

[Jan Kok (jankok-at-uo)]

Thanks for the reply.

1. /boot is not seperate and not out of space

2. all initrd* and vmlinuz* are of similar size, nothing exceptional

3. grub.cfg : the menuentry parts for updates 45 and 43 look identical

I notice now that in menu.lst the menu part for 4.15.0-45-generic does
not have the initrd line. What could cause this? (and would this explain
the 'Start Linux' problem)

I should have mentioned that I recently upgraded tot Linux 18.04 (on
January 9) and that update '43' is most likely the version that came
with the upgrade.

On 06-02-19 09:58, Stefan Bader wrote:
> This problem sounds like it might be related to problems in the setup
> but not the kernels themselves. Is /boot a separate filesystem (which
> possibly is out of space)? Looking into /boot, are all initrd* and
> vmlinux* files report a roughly similar size (du -h)? Unfortunately a
> bit messy to read but looking at /boot/grub/grub.cfg, do the references
> to the root disk (usually UUIDs) make sense?
>

[Stefan Bader (smb)]

I missed menu.lst mentioned before. This is a grub1 file and even for a 32bit (i386) installation I would have thought everything already migrated to use grub2. The only thing which I thought were still using menu.lst were paravirt Xen guests on the Amazon cloud.
There was some pain with grub1 and menu.lst related to configuration questions (do you want to keep the current version or install a new one). Answering keep there would any future update and basically keep people from using any updated kernel.

But to the problem, if changing menu.lst helped to switch back to the previous kernel, then you are still using grub1. So the lines in there for 43 and the 45 kernel should look the same (except version numbers). Does manually running "sudo update-grub" fix this? I don't think there is a update-grub-legacy-ec2 around (that would probably only be there when using grub2) but if it is there, that normally can be used to force menu.lst to be comparable to what grub.cfg contains.

[Jan Kok (jankok-at-uo)]

I observe that menu.lst is used here for starting Linux. And I assume
that when the 'Software Updater' sends me this, it is needed and is not
obsolete. My policy is to use the most recent kernel update, provided
that I can get it working.

'sudo update-grub': I have done this and it writes a new grub.cfg ;
however, menu.lst is not modified.

Finally: I have (manually is the word?) modified menu.lst and added an
'initrd' line in the menu for the 45 kernel update, and now Linux does
start with this latest kernel update. Fine. But the question is still,
how to get the Linux system or the Software Updater to create a correct
and sound menu.lst automatically?

Thanks so far.

On 06-02-19 12:34, Stefan Bader wrote:
> I missed menu.lst mentioned before. This is a grub1 file and even for a 32bit (i386) installation I would have thought everything already migrated to use grub2. The only thing which I thought were still using menu.lst were paravirt Xen guests on the Amazon cloud.
> There was some pain with grub1 and menu.lst related to configuration questions (do you want to keep the current version or install a new one). Answering keep there would any future update and basically keep people from using any updated kernel.
>
> But to the problem, if changing menu.lst helped to switch back to the
> previous kernel, then you are still using grub1. So the lines in there
> for 43 and the 45 kernel should look the same (except version numbers).
> Does manually running "sudo update-grub" fix this? I don't think there
> is a update-grub-legacy-ec2 around (that would probably only be there
> when using grub2) but if it is there, that normally can be used to force
> menu.lst to be comparable to what grub.cfg contains.
>

[Stefan Bader (smb)]

That the old version of the boot loader was not replaced might be an oversight in the updater or a feature for those systems which where installed a very long time ago. (If you are interested, see [1]).
Reading [2] it sounds like it is necessary to remove menu.lst before it will get re-generated again:

* sudo mv /boot/grub/menu.lst /boot/grub/menu.lst.save
* sudo update-grub

If menu.lst is not re-created by the update-grub command you will have to rename the saved copy back, otherwise you should be ok.

[1] https://help.ubuntu.com/community/Grub2/Upgrading
[2] https://ubuntuforums.org/showthread.php?t=873448

[Jan Kok (jankok-at-uo)]

I am now studying the Grub2/Upgrading documentation and I intend to
perform the upgrade. Then I suppose I will not need a repair of the
menu.lst creation software, so we may close the complaint.

Removing menu.lst did not help, update-grub still did not re-create menu.lst

Thanks for your help.

On 07-02-19 08:19, Stefan Bader wrote:
> That the old version of the boot loader was not replaced might be an oversight in the updater or a feature for those systems which where installed a very long time ago. (If you are interested, see [1]).
> Reading [2] it sounds like it is necessary to remove menu.lst before it will get re-generated again:
>
> * sudo mv /boot/grub/menu.lst /boot/grub/menu.lst.save
> * sudo update-grub
>
> If menu.lst is not re-created by the update-grub command you will have
> to rename the saved copy back, otherwise you should be ok.
>
>
> [1] https://help.ubuntu.com/community/Grub2/Upgrading
> [2] https://ubuntuforums.org/showthread.php?t=873448
>