[WORKAROUND] Kernel panics after upgrade to 4.4.26

[mla]

'SOK, I am not going to do anything until it comes to installing Mageia 6.

Here's gdisk info for that SSD:

Code: Select all

[root@Athlon ~]# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): C3570169-3EA5-45D4-A15F-479EE78726C7
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 2048-sector boundaries
Total free space is 7084 sectors (3.5 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       234436544   111.8 GiB   8300  Linux filesystem

The total free space figure seems a bit baffling. It's actually more like 100GB at the moment. Perhaps it is the btrfs format that's confusing gdisk?

/boot/grub2 is on that SSD, but off-hand I don't remember which disk I am actually booting from -- for historical reasons it may be from sda, which is MBR-only. Any way of finding out short of rebooting the machine and looking at BIOS settings?

[gohlip]

So I take it you are saying in effect "don't use drakdisk" for the purpose.

Drakdisk can be used for making, deleting, resizing, formatting partitions.
What we need is to set up a partitioning 'scheme' (msdos/gpt) for the whole disk.

I don't use drakdisk, had always used gparted, and I don't think drakdisk can do this.
If I am wrong, I will be really happy if others can help me stand corrected.

Re: bios-legacy grub
Bios-legacy boots need an 'mbr' from a msdos disk [1] and that disk needs to be the primary disk (sda only).


[1] - some exceptions - don't apply to your case, but just to be technically accurate.
Bios-legacy can be booted from a gpt disk but that disk needs to have a 'bios-grub' partition, a separate boot partition and both needs to be flagged as such.
This is to 'fool' the 'bios' to think it is an msdos device.
Your ssd disk is not the primary device and do not have 'bios-grub' or 'boot' partitions (in fact, tecnically, no partition).

[arnesp]

'The total free space figure seems a bit baffling. It's actually more like 100GB at the moment. Perhaps it is the btrfs format that's confusing gdisk?

/boot/grub2 is on that SSD, but off-hand I don't remember which disk I am actually booting from -- for historical reasons it may be from sda, which is MBR-only. Any way of finding out short of rebooting the machine and looking at BIOS settings?

The free space listed by gdisk is from a partitioning point of view, i.e. sectors not allocated for partitions, partition tables, or Protective MBR.

As gohlip points out, a bios-grub partition is needed for booting from a GPT disk in BIOS mode (I have had no problem with /boot being in the root partition though). Seeing that you have only the root partition on the sdc, I assume that you are in fact booting from sda.

@gohlip: would such a boot configuration be a potential problem?

[gohlip]

@gohlip: would such a boot configuration be a potential problem?

A bios-legacy boot (at bios) most likely will not detect a (correct) gpt disk, and hence cannot boot it. [1]
I'm already surprised his mbr from sda can boot OS from his (incorrect) gpt disk (perhaps this 'mbr protective helps, ironically).

A uefi system does not require mbr from sda to boot.
Though it must has an $esp partition mounted as /boot/efi [2] that in rough comparison, acts as the 'mbr' and therefore grub does not need to specify sda (or sdb) in grub commands or in installation [3].


Some notes to clarify or make accurate.

[1] a uefi boot can usually detect an msdos disk and can boot OS from a msdos disk
but always good not to mix gpt and msdos and not mix uefi and bios-legacy boots.
Can be done but inadvisable.
Though bios-legacy can boot a gpt disk (through bios-grub and flagged and....),
as a rule, with msdos disk boot bios-legacy and with gpt, boot uefi.
Less hassles and headaches (2 TB notwithstanding).

[2] The $esp (fat32 format) for grub 2 requires mount point as /boot/efi
though when using rEFInd, it can be /boot (can also be /boot/efi)
and when using bootctl (systemd boot), it must be /boot only.

[3] a grub command for bios-legacy is like

Code: Select all

# grub-install /dev/sda

without specifying '/dev/sda' it will fail.
A grub command for uefi

Code: Select all

# grub-install

will work without specifying '/dev/sda' though it (now) works with specifying '/dev/sda' so as not to confuse people coming from bios-legacy; this '/dev/sda' will be ignored if specified. It is really unnecessary.
A more detailed grub-command (usually to fix grub issues) is

Code: Select all

# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=mageia --boot-directory=/boot --recheck --debug

again note '/dev/sda' is not specified.
Also linux installers for uefi do not require device to be specified for bootloader location as like 'install bootloader in - sda/sdb/.../partition' but must specify mount point /boot/efi else installation will fail.


Phew... needs so many clarification to get things.... correct.

Hope all is clear, but if I made some errors, appreciate correction.
Cheers.

[mla]

Sorry to be a pest, but I feel I ought to get to grips with this...

I'm already surprised his mbr from sda can boot OS from his (incorrect) gpt disk (perhaps this 'mbr protective helps, ironically).

I am sure you have already explained, but you'll need to do it in words of no more than two syllables for me (figuratively speaking! ). In what way is my GPT disk "incorrect"? It is GPT (something made it so, hence it either was supplied as such, or drakdisk did it for me without my realising it) and it has one partition /dev/sdc1 (formatted to btrfs) as shown on that "disk -l" output I posted earlier.

Why/how is that wrong and how is it to be fixed? (I appreciate that fixing may destroy data on that disk.)

BTW, yes, I've now confirmed that I am booting from sda which is MBR -- as has been surmised had to be the case.

[gohlip]

but you'll need to do it in words of no more than two syllables for me

Hee hee hee. I'll try, but remember I'm the non-native English speaker here.



Most likely, your ssd disk is bought as 'raw', meaning it had not been 'set' to msdos or gpt partitioning and also without a partition.
You used drakdisk to create a partition, but without 'setting' any partitioning 'scheme' (gpt or msdos), it results in 'gpt with mbr protective'.

Ah... I've found a good explanation (better than I can explain) here, but he calls it hybrid MBR's. (His gdisk looks like yours).
<But he speaks in multi-syllables - I too sometimes cannot understand.... )
http://www.rodsbooks.com/gdisk/hybrid.html

But I do want to add that you can first try gparted on some small usb's,
Use the 'device tab' and set partitioning.
But note after booting up, a uefi/gpt OS can 'see' an msdos disk and a bios-legacy/msdos OS can 'see' a gpt disk.
Just that at boot, the bios-legacy 'bios system' cannot detect a gpt device.

Personally, I think it's best we use a 'proper partitioned' (sorry, cannot find a better word here, using my non-native excuse... ) and I repeat
use uefi for gpt
use bios-legacy for msdos

Use the same partitioning (gpt or msdos) throughout
Use the same boot (uefi or bios-legacy) throughout
(if there's windows and we want to keep it, follow the windows scheme (uefi/gpt or bios-legacy/msdos) - may (or with difficulty) not boot windows if otherwise)

Hope my English here is comprehensible.
Cheers again.

[arnesp]

In what way is my GPT disk "incorrect"? It is GPT (something made it so, hence it either was supplied as such, or drakdisk did it for me without my realising it) and it has one partition /dev/sdc1 (formatted to btrfs) as shown on that "disk -l" output I posted earlier.

Why/how is that wrong and how is it to be fixed? (I appreciate that fixing may destroy data on that disk.)

BTW, yes, I've now confirmed that I am booting from sda which is MBR -- as has been surmised had to be the case.

I am still not sure your GPT disk is incorrect. I did an install on a couple of external USB disks, trying to mimic your configuration and have found no problems booting it. Unfortunately, it does not reproduce your link problem, but that wouldn't be expected either, if your assumption about a timing issue is correct.

Here is an excerpt from running parted -l

Code: Select all

Model: ST380011 A (scsi)
Disk /dev/sdb: 80,0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  80,0GB  80,0GB  btrfs


Model: Packard Bell Carbon (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  52,4GB  52,4GB  primary   ext4            boot
 2      52,4GB  1244GB  1192GB  extended
 5      52,4GB  69,2GB  16,8GB  logical   linux-swap(v1)
......


I installed mga5 to the brtfs partition on sdb and told the installer to write the (stage 1) bootloader to sdc.

[mla]

gohlip: Thanks for the link. Much there to digest! Let me see if I got it straight...

Essentially, my sdc on which I have Mageia 5 installed is fine as it is -- GPT present and MBR protective is, according to that website (http://www.rodsbooks.com/gdisk/walkthrough.html) the correct state for a GPT disk; and it has one partition (sdc1) formatted as btrfs. If I understand you correctly, what may be dodgy is the fact that the initial boot is from sda, which is an MBR disk. Since my somewhat elderly machine is a BIOS one, I should stick with MBR for all disks. Is that right? (You must be right that the sdc SSD arrived already GPT-formatted and I just replaced its single Windows partition with the btrfs one.)

arnesp: Thanks for trying! Another possibility perhaps is that grub2 fails to understand symlinks on btrfs in -- at least not in the context of the MBR -> GPT boot.

[gohlip]

A bios-legacy 'bios' cannot 'see' a normal gpt partitioned device, otherwise we won't have to 'fool' the bios with a flagged 'bios-grub' partition, much less boot an OS there.

To both @mia and @arnesp,
Instead of talking 'academically' about this issue, I have an idea.
Grub takes its device-mapping from what the bios sees.
And we can see exactly that by the command 'ls' in the grub prompt.

Code: Select all

grub> ls
grub> ls (hdx,y)

For a device it sees, it will print out device and partitions in it. (hdx) followed by partitions like.. (hdx) (hdx,4) (hdx,3) (hdx,2) (hdx,1) - {actually (hdx,gpty) or (hdx,msdosy)}
For a device that it cannot see, it will print out just (hdx) without listing its partitions (because it cannot see).

I'm sure your 'gpt' device partitions can be listed (because it boots).

So what I'm suggesting is that you take a small usb thumb drive, use gparted to create a 'proper' (sorry for the phraseology) gpt device ('device tab' at gui - 'create partition table' --> select 'gpt') then create some (or 1) partitions.
Then similarly plug in the usb thumb, boot up with usual bootloader, go to grub prompt and then use 'ls' as above and see it the bios list its partitions.

Let us know, ya. Copy down (and let us know) the grub 'ls' command output too. Thanks.

[edit] - Just to be very sure (because it is highly unlikely to be UEFI because of the input here) but just in case, when booted up to Mageia, can both of you let us know the output of terminal command

Code: Select all

test -d /sys/firmware/efi && echo UEFI || echo BIOS

Thanks...

[mla]

No UEFI

Code: Select all

[root@Athlon ~]# test -d /sys/firmware/efi && echo UEFI || echo BIOS
BIOS

But now I have a silly problem. How do I get to the grub command line prompt? If I just type "grub" I get the old grub (GNU GRUB 0.97), which has no "ls" command. There is no grub2 command and all grub2* executables appear to have specific purposes, nothing to do with the command line interface. Reading through "info grub" also offers no clues -- it just blithely assumes that one knows how to get to the grub2 command prompt.

What am I missing?

[arnesp]

Reboot and press c when the boot menu shows.

The output on my system is

(hd0) (hd1) (hd2) (hd2,gpt1)

Have you tried running a filesystem check on the btrfs partition?

[mla]

Ah! (Bane of my life -- system developers know sod all about usability; at least have a /usr/bin/grub2 executable which simply says "hit 'c' at the grub2 menu on boot".)

Anyway, ls gives

(hd0) (hd1) (hd2) (hd2,gpt1)

"ls (hd2,gpt1)" gives file system type as btrfs and lists partition label , UUID, start sector and total length -- all correctly.

Taking my spare flashstick, I followed the instructions using gparted. The result is given by gdisk as follows:

Code: Select all

root@Athlon ~]# gdisk -l /dev/sdd
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdd: 7802880 sectors, 3.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): E03AE73A-3B1B-471D-8960-80CD7DA68591
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7802846
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         7800831   3.7 GiB     8300

That looks just like my (hd2). And indeed, grub's "ls" command now shows, in addition to the above:

(hd3) (hd3,gpt1)

and "ls (hd3,gpt1)" again shows all details correctly. After lunch I'll try installing Mageia 5 on that flashstick, just to see whether the symlinks would work on that for me.

[gohlip]

Thanks for testing it out guys.
My grub ls command in bios-legacy boot won't show for gpt devices. Just (hdx).
My grub ls command in uefi boot shows all including from msdos devices.

But as everything works for you (won't for me - bios-legacy booting gpt), I'm with arnesp - let it be, why mess it if it works.
If your bios-legacy can boot gpt, great.
It may be that UEFI implementation may differ between motherboard manufacturers.

Cheers, take care, I'm calling it a day.
"A day!"

[mla]

The upgrade to kernel 4.4.30 restored the old arrangement with vmlinuz etc as symlinks to the actual files, and the machine boots with no problem. There was something very odd about 4.4.26.

[mla]

New kernel -- old problem. After kernel upgrade to 4.4.32 my main machine once again fails to boot with exactly the same symptoms as experienced with kernel 4.4.26 (but not with 4.4.30). Once again, the problem is cured by replacing symlinks in /boot with the relevant files. Hey-ho...

[doktor5000]

FWIW, only your installation seems to be affected, so this may very well be a local configuration issue.

[arnesp]

Could this be the same issue: https://bugs.mageia.org/show_bug.cgi?id=19460 ?
The affected kernels are not a perfect match, but on the other hand, if it is timing related.
Common factors are root file system on BTRFS, and probably also BIOS mode boot. Maybe not so common a configuration.