LM 17.3 Boot bug - boot repair fails [SOLVED]

[Girafenaine]

Hello,

I have a dual boot Linux Mint 17.3 32 bits and Mac OS 10.6.8 on my black Macbook 2.1 (blocked to 32 bits EFI, even if it has a 64 bits kernel). I use reFind to choose on which OS I boot. It used to work well on both OS.

Now I've got a problem, Linux Mint can't boot. When I try, the process starts up and in the last lines I can read :
apic_timer_interrupt+0x34/0x3c
? panic+0x16a/0x1a5
(...)
kernel_init+0x10/0xe0
ret_from_kernel_thread+0x21/0x30
? rest_init+0x70/0x70
---(end track 17b86bbd1efad9a9)---

And the process stops, I have to force shutdown.
Mac OS can start up without problem.
I tried to launch boot repair from a live session, it didn't succeed and told me "you may want to use a 64 bits Linux Mint", and didn't make any repair. I edited a boot file : paste.ubuntu.com/=Y3Mr62d5S9/

Can you please help me to make my Linux Mint to work again ?

Thanks,

Girafon

[fabien85]

Hi,
the problem is not at the bootloading stage so it's not something that boot-repair can fix.
What you see are kernel errors. So refind correctly gives control to the kernel, bootloading is finished, but later the kernel fails.
Unfortunately I am not a kernel expert, far from it, so I dont know what the error means nor how to debug it.

Do you have another kernel to try and/or more booting options for Mint ?
From refind this is accessed by F2. If you have any other kernel try booting it. If you have any recovery option, try booting it. Otherwise try getting manually in recovery mode : highlight the Mint entry in refind, press F2 twice to get to the editor, you should have something like "ro root=UUID=blabla ..." (maybe with quiet splash), remove quiet splash if any and add the option "recovery nomodeset" so that you now have "ro root=UUID=blabla recovery nomodeset", then try to boot this.

Did you make any change to your partition layout lately ?
In your paste.ubuntu report some tools report 4 partitions while other report 5.
Please boot your live USB, open a terminal, issue

Code: Select all

sudo gdisk -l /dev/sda

(best to copy-paste it, but if you type, the option is a lowercase L)
Then report here the result by putting it between code tags (button </>)

Also you have a fstab entry to mount a USB stick in your /etc/fstab, so you would better boot with it plugged in.

[Girafenaine]

Hello,

Thanks for your help.

I tried to add 'recovery nomodeset' at the end of the boot command manually, but it ends with the same result.

Here is the requested result:

Code: Select all

mint@mint ~ $ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

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

Found valid GPT with hybrid MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9D37B812-7731-4501-BACA-5FBE283AD1D9
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 2069 sectors (1.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640        61962704   29.4 GiB    AF00  
   3       895170560       970756095   36.0 GiB    8300  
   4       970756096       976771071   2.9 GiB     8200  
   5        61962705       895170559   397.3 GiB   AF00 

What else could I try ?

Girafon

[fabien85]

(we can correspond in french if you prefer, though other forumer may then not understand and hop in with advice)

Hum you have a hybrid MBR, as seen on your gdisk output.
That's what I feared, and it may be the source of the problem.
There was one forumer who knew all about this, Rod Smith the maintainer of refind and author of the hybrid MBR page I linked. Unfortunately it seems he doesnt come anymore on this forum. Maybe you will get better luck if you write on the ubuntu forum.

Did you recently make any change to your partitions ?
Did you use macOS Disk Utility to check the disk or anything ?

Let's check whether the hybrid MBR is not corrupted : from a live USB (or from macOS if you install gdisk on it), open a terminal and issue

Code: Select all

sudo gdisk /dev/sda
r
o
q

the first "r" gets you to the recovery/transformation menu, then "o" print the MBR data, then "q" quits without writing any change to your disk (so the whole operation does not do anything to your data, it's safe).
Report here the result after the "o" command, should be something starting like

Code: Select all

Disk size is 1953525168 sectors (931.5 GiB)
MBR disk identifier: 0x27E0C391
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
...

(if you run gdisk from macOS, instead of /dev/sda you need to put /dev/disk0, because macOS uses a different drive naming convention)

If the MBR is uncorrupted, then my fears are unfunded which is great, and the problem probably lies in the kernel, which we may fix by reinstalling it.

[Girafenaine]

Hello Fabien,

Thanks for your help. It seems better to continue with english on this part of the forum.

I had no known recent change on my partitions. Here is the result of the command line :

Code: Select all

mint@mint ~ $ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.8

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

Found valid GPT with hybrid MBR; using GPT.

Disk size is 976773168 sectors (465.8 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                     1       409639   primary     0xEE
   2      *         409640     61962704   primary     0xAF
   3             895170560    970756095   primary     0x83
   4             970756096    976771071   primary     0x82

What could we conclude from this ?

Girafon

[fabien85]

Hi,
my hybrid MBR fears seem unfounded. From the output you just gave, the start and end sectors of nearly all partitions coincide with that given in the GPT table in your second post.
Except the "Documents" partition which is not present in the MBR, but I dont think that should make the kernel panic like what's happening.

How exactly are you booting from refind ? do you directly boot the kernel (the entry would be called something like "Boot /boot/vmlinuz-3.16.0-38-generic from 38.7GB ext4 volume") ? or do you boot grub EFI (the entry would be called something like "Boot EFI/ubuntu/grubia32.efi from EFI") ? or do you boot legacy mode (I'm not sure how the entry would be called, maybe something with "Legacy")
From your paste.ubuntu report it seems it's the first solution (the simplest one in my opinion). (In that case, the whole hybrid MBR thing is useless and later you may want to get rid of it and go back to pure GPT.)

Ok so I dont think the problem is with partitions. Do you have any clues to give me : what were the last things you did in Linux (or macOS) that could have induced the problem ? Any important update ? Did you install any hardware driver ? That "Documents" partition, did you put it up recently, in particular the edit of the fstab to mount it in Linux ? Did you have it working in Linux in the past ?

One guess is that your kernel may have gotten corrupted somehow.
So let's try reinstalling it, and at the same time we will deactivate temporarily some mounting in the fstab :
1 ) Boot the live USB, connect to internet
2 ) Mount the Linux partition on /mnt

Code: Select all

sudo mount /dev/sda3 /mnt

3 ) Edit the fstab to deactivate the mounting of the USB stick and "Documents" partition

Code: Select all

sudo nano /mnt/etc/fstab

Put a # in front of the line "LABEL="Documents" /mnt/Documents hfsplus force,rw,user,uid=501,umask=022 0 0"
and another # in front of the line "UUID="085E-5590" /media/etienne/DJENA vfat rw,user,noauto,nosuid,nodev,uid=501,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2 0 0"
do ctrl+o to save and ctrl+x to exit
4 ) We will now chroot into the system, basically following some of the instructions of this link

Code: Select all

for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc/
sudo chroot /mnt

5 ) The terminal prompt should now change to a # instead of a $, on my system the text before the prompt also becomes red instead of green, indicating that you are root (which you can check with whoami) : you are now chrooted into the installed system, i.e. all commands you now issue in this terminal are commands from the installed Linux and affect it (and not the live USB). (this works only in this terminal)
6 ) From your paste.ubuntu report, your kernel seems to be 3.16.0-38-generic. But let's check this to be sure :

Code: Select all

apt list --installed  | grep linux-image

it should give something like this

Code: Select all

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux-image-4.13.0-32-generic/xenial-updates,xenial-security,now 4.13.0-32.35~16.04.1 amd64 [installed]
linux-image-extra-4.13.0-32-generic/xenial-updates,xenial-security,now 4.13.0-32.35~16.04.1 amd64 [installed]

(here it's on my system with Mint 18.3 and kernel 4.13.0-32, so numbers etc will be different for you). If there are only two lines, then it means you have a single kernel (which is simpler).
Note down the version of the latest kernel. In the following I am going to assume it is 3.16.0-38
7 ) Let's check all the packages related to this kernel (again, just to be sure)

Code: Select all

apt list --installed | grep 3.16.0-38

In my case this gives

Code: Select all

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux-headers-4.13.0-32/xenial-updates,xenial-updates,xenial-security,xenial-security,now 4.13.0-32.35~16.04.1 all [installed]
linux-headers-4.13.0-32-generic/xenial-updates,xenial-security,now 4.13.0-32.35~16.04.1 amd64 [installed]
linux-image-4.13.0-32-generic/xenial-updates,xenial-security,now 4.13.0-32.35~16.04.1 amd64 [installed]
linux-image-extra-4.13.0-32-generic/xenial-updates,xenial-security,now 4.13.0-32.35~16.04.1 amd64 [installed]

(again, I have kernel 4.13.0-32 not 3.16.0-38)
so there are 4 packages to reinstall
8 ) Let's now reinstall all these 4 kernel packages

Code: Select all

apt install --reinstall linux-headers-3.16.0-38 linux-headers-3.16.0-38-generic linux-image-3.16.0-38-generic linux-image-extra-3.16.0-38-generic

this will take some minutes, depending on the speed of your internet connection
9 ) Now we exit the chroot and clean up

Code: Select all

exit
for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
sudo umount /mnt

10 ) Reboot, cross your fingers

[Girafenaine]

Hello Fabien,

Thank you very much for your last message. I just tried the process : I went in my installed linux as a root thanks to the command lines. But the "apt list --installed | grep linux-image" doesn't give anything at all, neither does the next one. I get :

Code: Select all

mint / # whoami
root
mint / # apt list --installed  | grep linux-image
mint / # apt list --installed  | grep linux-image
mint / # apt list --installed | grep 3.16.0-3

Does it mean that I have no more installed kernel, or that it is too much damaged ?

I cannot tell you what break my kernel or the installed linuxmint. It used to work well alongside MacOS. The fstab lines are to share the documents partition, which is hfsplus formatted. It has never be very stable (sometimes documents files disappear in nemo, and I have to reboot with MacOS to get the partition work again), but I have used it for 2 years and it is the first time I cannot boot linuxmint.

I think it booted directly the kernel like your first option. It seems to me that a full GPT option will be clearer, but I had some pain to install linuxmint on my MacBook, and this may explain that the boot process is not the best.

Girafon

[Girafenaine]

Hello again,

I confirm that when I try to boot Linux, it refers to boot/vmlinuz-3.16.0-38-generic.

Girafon

[fabien85]

Hi,

side note: when I had a macbook, I was using a FAT32 or exFAT partition to share docs between macOS and Linux. I tried a hfs+ partition, but permissions were a nightmare. In FAT32, a single file cannot be larger than 4GiB ; which is most of the time not a problem.

So it seems indeed that your kernel is not recognised as installed.
There is the possibility that you have a hardware problem, and linux not booting is just a symptom of it. I would run a apple hardware test (AHT) to be sure. If your macOS is not too recent, the AHT is installed in macOS and you can access it from refind (in the option menu if you press F2 on the macOS entry). If you have one of the recent version, they dont provide AHT anymore, you are supposed to run it through internet (booting with option-D), but in my experience that doesnt work. Also check the hard drive : from the linux live USB, launch Menu > Preferences > Disks, select the internal drive, then in the menu in the upper bar go to "SMART data & self tests", start a self test, wait a bit till it ends, then check that you have "Overall assessment : Disk is OK" and that in the list below the column "assessment" is always OK.
Finally, let's perform a filesystem check on the linux partition : from the live USB, launch

Code: Select all

sudo fsck /dev/sda3

if all goes well you should get something like

Code: Select all

fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
/dev/sda3: clean, 18117/944000 files, 1665597/3840000 blocks

(numbers will be different)

If hardware is ok, the simplest and quickest is most probably to backup your data and reinstall linux. You could take the occasion to upgrade to Mint 18. I can guide you to reinstall.

Otherwise, if you feel adventurous and want to fix the system, we can try to debug :
1 ) backup your data (in fact I wonder why I have forgotten that until now)
2 ) redo steps 1-2-4) of my previous post, i.e. re-chroot into the system
3 ) Issue the following commands and post the outputs

Code: Select all

mount
blkid

(I want to check you got chrooted into the good partition)
4 ) Let's use another tool to see if the kernel is installed :

Code: Select all

dpkg --get-selections | grep linux-image

(in the previous post, I used apt, which works on Mint 18, but I dont remember if it works on Mint 17 and with all the same options)
5 ) If you are sure you are chrooted on the good partition (if you are not sure, post here the outputs of steps 4-5 and I will check), let's install the kernel :

Code: Select all

apt-get install linux-headers-3.16.0-38 linux-headers-3.16.0-38-generic linux-image-3.16.0-38-generic linux-image-extra-3.16.0-38-generic

(note I use apt-get now, to be sure it works on Mint 17)
If you get something like this

Code: Select all

Reading package lists... Done
Building dependency tree       
Reading state information... Done
blabla
linux-image-3.16.0-38-generic is already the newest version (3.16.0-38.somenumber).
blabla
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

then slap a --reinstall option :

Code: Select all

apt-get install --reinstall linux-headers-3.16.0-38 linux-headers-3.16.0-38-generic linux-image-3.16.0-38-generic linux-image-extra-3.16.0-38-generic

[Girafenaine]

Hello Fabien,

I felt adventurous. However I had no "AHT" option in my refind menu when selecting MacOS. As MacOS (10.6. boots without any difficulty, I guess there is no heavy hardware problem. I ran fsck and disk "autotest" and it seemed OK.

So here is what your suggested command lines gave :

Code: Select all

mint@mint ~ $ sudo fsck /dev/sda3
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sda3: clean, 271732/2362864 files, 4226487/9448192 blocks
mint@mint ~ $ sudo mount /dev/sda3 /mnt
mint@mint ~ $ for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
mint@mint ~ $ sudo cp /etc/resolv.conf /mnt/etc/
mint@mint ~ $ sudo chroot /mnt
mint / # mount
/dev/sda3 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /sys/firmware/efi/efivars type efivarfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/sda5 on /mnt/Documents type hfsplus (rw,noexec,nosuid,nodev,force,uid=501,umask=022)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
/mnt/Documents/Users/Etienne/Documents on /home/etienne/Documents type none (rw,bind)
/mnt/Documents/Users/Etienne/Music on /home/etienne/Musique type none (rw,bind)
/mnt/Documents/Users/Etienne/Pictures on /home/etienne/Images type none (rw,bind)
/mnt/Documents/Users/Etienne/Movies on /home/etienne/Vidéos type none (rw,bind)
/mnt/Documents/Users/Etienne/Downloads on /home/etienne/Téléchargements type none (rw,bind)
gvfsd-fuse on /run/user/501/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=etienne)
mint / # blkid
/dev/loop0: LABEL="Linux Mint 17.2 Cinnamon 32-bit" TYPE="iso9660" 
/dev/loop1: TYPE="squashfs" 
/dev/sda1: LABEL="EFI" UUID="70D6-1701" TYPE="vfat" 
/dev/sda2: UUID="f07169e0-e9ab-3d4c-ba5e-4ad629623c0f" LABEL="Systeme" TYPE="hfsplus" 
/dev/sda3: UUID="f91f3779-fb9b-4fe2-be5a-6eca89240f40" TYPE="ext4" 
/dev/sda4: UUID="ec03909e-c435-48da-976c-dbe6c684bee9" TYPE="swap" 
/dev/sda5: LABEL="Documents" TYPE="hfsplus" 
/dev/sdb1: LABEL="MINT" UUID="65B1-1B12" TYPE="vfat"

Then I tried with the apt-get install command. It did not behave in the expected way, and asked me to run dpkg -configure, and so did I :

Code: Select all

mint / # dpkg --get-selections | grep linux-image
linux-image-3.16.0-38-generic			install
linux-image-3.19.0-32-generic			deinstall
linux-image-extra-3.16.0-38-generic		install
linux-image-extra-3.19.0-32-generic		deinstall
mint / # apt-get install linux-headers-3.16.0-38 linux-headers-3.16.0-38-generic linux-image-3.16.0-38-generic linux-image-extra-3.16.0-38-generic
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. 
mint / # sudo dpkg --configure -a
Setting up initramfs-tools (0.103ubuntu4.9) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for ca-certificates (20170717~14.04.1) ...
Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate Go_Daddy_Class_2_CA.pem
WARNING: Skipping duplicate certificate Go_Daddy_Class_2_CA.pem
17 added, 42 removed; done.
Running hooks in /etc/ca-certificates/update.d....
Adding debian:AC_RAIZ_FNMT-RCM.pem
Adding debian:Amazon_Root_CA_1.pem
Adding debian:Amazon_Root_CA_2.pem
Adding debian:Amazon_Root_CA_3.pem
Adding debian:Amazon_Root_CA_4.pem
Adding debian:Certplus_Root_CA_G1.pem
Adding debian:Certplus_Root_CA_G2.pem
Adding debian:Certum_Trusted_Network_CA_2.pem
Adding debian:Hellenic_Academic_and_Research_Institutions_ECC_RootCA_2015.pem
Adding debian:Hellenic_Academic_and_Research_Institutions_RootCA_2015.pem
Adding debian:ISRG_Root_X1.pem
Adding debian:LuxTrust_Global_Root_2.pem
Adding debian:OpenTrust_Root_CA_G1.pem
Adding debian:OpenTrust_Root_CA_G2.pem
Adding debian:OpenTrust_Root_CA_G3.pem
Adding debian:SZAFIR_ROOT_CA2.pem
Adding debian:TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.pem
Removing debian:AC_Raíz_Certicámara_S.A..pem
Removing debian:ApplicationCA_-_Japanese_Government.pem
Removing debian:Buypass_Class_2_CA_1.pem
Removing debian:CA_Disig.pem
Removing debian:ComSign_CA.pem
Removing debian:EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem
Removing debian:Equifax_Secure_CA.pem
Removing debian:Equifax_Secure_Global_eBusiness_CA.pem
Removing debian:Equifax_Secure_eBusiness_CA_1.pem
Removing debian:IGC_A.pem
Removing debian:Juur-SK.pem
Removing debian:Microsec_e-Szigno_Root_CA.pem
Removing debian:NetLock_Business_=Class_B=_Root.pem
Removing debian:NetLock_Express_=Class_C=_Root.pem
Removing debian:NetLock_Notary_=Class_A=_Root.pem
Removing debian:NetLock_Qualified_=Class_QA=_Root.pem
Removing debian:RSA_Security_2048_v3.pem
Removing debian:Root_CA_Generalitat_Valenciana.pem
Removing debian:S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.pem
Removing debian:Sonera_Class_1_Root_CA.pem
Removing debian:Staat_der_Nederlanden_Root_CA.pem
Removing debian:StartCom_Certification_Authority.pem
Removing debian:StartCom_Certification_Authority_2.pem
Removing debian:StartCom_Certification_Authority_G2.pem
Removing debian:SwissSign_Platinum_CA_-_G2.pem
Removing debian:TC_TrustCenter_Class_3_CA_II.pem
Removing debian:UTN_USERFirst_Email_Root_CA.pem
Removing debian:Verisign_Class_1_Public_Primary_Certification_Authority.pem
Removing debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.pem
Removing debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
Removing debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.pem
Removing debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem
Removing debian:Verisign_Class_3_Public_Primary_Certification_Authority.pem
Removing debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem
Removing debian:Verisign_Class_3_Public_Primary_Certification_Authority_2.pem
Removing debian:WellsSecure_Public_Root_Certificate_Authority.pem
Removing debian:WoSign.pem
Removing debian:WoSign_China.pem
Removing debian:CA_WoSign_ECC_Root.pem
Removing debian:Certification_Authority_of_WoSign_G2.pem
Removing debian:S-TRUST_Universal_Root_CA.pem
Removing debian:TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H6.pem
done.
done.
Processing triggers for initramfs-tools (0.103ubuntu4.9) ...
update-initramfs: Generating /boot/initrd.img-3.16.0-38-generic
Warning: No support for locale: fr_FR.utf8

What do you think of this result ?

Girafon

[Girafenaine]

And you rock !

I am writing from my newly working LM session : thank you very much. The last lines have made it to work again.

Do my last post give you some clues about what happened ?

And I note your idea to use FAT32 instead of HFSplus for a shared partition. I wanted to keep hfsplus to have a home fully working with MacOS. My emails are share with thunderbird working with LM as well as with MacOS (same user file opened form both session). It is not very stable. So I will try FAT32.

Thanks,

Girafon

[fabien85]

Congrats ! I saw your previous message and was writing the reply below before you posted your second message. As I have to leave now, I keep the message as is, and will reply further tomorrow.

Hi,

maybe the apple hardware test was already removed in macOS 10.6. Look at this page for a possible way to reinstall it.

Things look better when using dpkg instead of apt as in my previous advice.
So it seems the kernel is correctly installed, but somehow your system was interrupted while it was updating the init ram disk image (that's why it's asking you to dpkg --configure -a and the first thing coming is update-initramfs). A corrupted initrd is probably a good reason for the kernel to panic (I'm no expert here, I just know that the initrd is the first thing the kernel loads and that it contains many low-level utilities to be put in ram)
You ran the correct command, and it executed without error (the 'No support for locale: fr_FR.utf8' is a basic usual warning, it just means that the keyboard will be detected as qwerty at first by the kernel, so that's what you will get if it drops you in recovery mode or busybox shell). So all seems good.
Did you try rebooting into Linux ?

I would think Mint now has a chance to work. If that fails, then try reinstalling the kernel with the command of my previous post.

[fabien85]

Re,
I mostly said it in my previous message, but my guess is that the initial ram disk was being updated on your system, eg after an update of the kernel or of some hardware driver or some other system utility ; then something stopped the process, leaving the initrd corrupted or in a poor state.

One workaround to avoid these kinds of problems in the future, is to have a second, backup, kernel installed.
In fact it is a good idea to upgrade your kernel anyway, since the 3.16 series is not updated anymore and is vulnerable to the Spectre/Meltdown vulnerabilities. See the following thread for info : viewtopic.php?f=90&t=261343
So I advise you to install a newer kernel. Following the instructions in the Spectre/meltdown thread, you can either install a 4.4 kernel (4.4.0-111 or newer) or a 3.13 one (3.13.0-141 or newer)
Refind will then provide the possibilities to boot both kernels installed. By default it will propose the newest installed, but if you press F2 on the linux entry, you will see options to boot the older kernel.

For the hybrid MBR stuff, now that we know you boot everything in EFI mode using the GPT partition table, you can easily correct it if you want. You can simply erase the MBR to come back to a pure GPT disk.
This is done with gdisk from linux or macOS (after installing gdisk in macOS. In this case substitute sda for disk0 in the command below) :

Code: Select all

sudo gdisk /dev/sda
x
n
p
w
Y

the first x gets you in the expert menu of gdisk, then n erases the MBR and gets the disk back to pure GPT, p prints the partition table so that you can check that everything looks good ie you still have the 5 partitions, finally w writes the changes to disk with Y needed for confirmation. (before that, nothing was yet written to disk)
The reason you got a hybrid MBR is most probably that when you installed linux, you used macOS's Disk Utility to create the future partitions for Linux. Indeed when one creates non-hfs partitions with Disk Utility, it automatically makes the disk hybrid MBR. This is (poorly imho) designed as it thinks that you are going to install windows via bootcamp, and windows 7 and older require a MBR disk. Nowadays this is useless (and ugly) since windows and linux can be installed in EFI mode, as macOS. Still, Disk Utility does it everytime you create a non hfs partition with it.

For the shared partition between macOS and linux, I used FAT32 for sharing of simple files, I didnt try to share the thunderbird emails etc so I dont know if it will work.I remember I had to set some mounting options so that all files would have full permissions, I think the options were : users,uid=username,gid=username,exec so that the fstab line would be something like
UUID=the-uuid /path/to/mount vfat users,uid=username,gid=username,exec 0 0
where you can find the uuid with blkid from command line or with gparted in a GUI.

[Girafenaine]

Hello,

I tried the command lines you suggested to boot on EFI mode. It resulted in :
- with gdisk, the "n" command was to get a "protective MBR" (there was no mention no erase it. I saw no command to do something like that)
- when I launch again gdisk, it first explain there is EFI with protective MBR
- when the MacBook boots on LM, it seems to be with the same file "/boot/vmlinuz-3.16.0-38-generic"

So I am not sure the process was successful. Should I try something else ?

I will try to install another kernel as you told me.

Girafon

[fabien85]

Everything is perfect now.

Indeed the "n" command in gdisk creates a protective MBR, which means it gets your disk back to pure GPT.
Quoting the words of the creator of gdisk (and refind) : "the normal state for a GPT disk is MBR: protective and GPT: present.". See this link for more explanations.

Yes you should still boot the 3.16.0-38 kernel, that's normal.
When you issued the command sudo dpkg --configure -a and it launched Setting up initramfs-tools (0.103ubuntu4.9) ... etc is that the system rebuilt the initrd image, which is a file needed by the kernel when it starts booting. Somehow this file must have been corrupted before, and after rebuilding it you have allowed the kernel to be able to boot once again.

I advise to install an updated kernel, preferably in the 4.4 series, both for protection from Spectre/Meltdown, and so as to have two kernels available (keeping the 3.16.0-38) so that you can fall back on one if you have problems with the other.

[Girafenaine]

Hello Fabien,

Ok, thanks for the explanations.

I installed 4.4.116, which was the kernel put forward by the update manager itself. I keep the old one, in case of emergency.

The link you gave tells that LM 32 bit are not well protected against Meltdown. But it seems that I have no choice, since my old MacBook (2.1, 2007) with a 64 bit kernel but a 32 bits EFI cannot boot a 64 bits OS.

May I ask you by PM question about dualboot without Refind on a Macbook ?

Girafon

[fabien85]

Ah indeed, patches agains meltdown are no yet available for 32-bit.
I assume they will arrive at some point.

If your CPU is 64-bit (following the specs here), then in principle it's possible to boot a 64-bit kernel.
This is a bit complicated, and I haven't had the occasion to try the procedure personally. In that case you would use grub (the 32-bit EFI version) as your boot manager instead of refind.
You can PM me if you want to discuss this. However note that this is a complex undertaking for which I have no direct experience, and with no big advantage over your current situation.
(just two possible small advantages : (i) performance may be slightly increased, and (ii) you will be able to have a kernel patched against meltdown, however I have not yet seen attacks reported for this, and the main attack vector, the web browser, is anyway patched since firefox 57.0.4)

[Girafenaine]

Hello,

Thanks for your advice.

Actually a 64bit OS could let me use Darktable (Raw photos development), that doesn't work on a 32bit LM.

But my Macbook has not yet a long time to live (no battery anymore, broken frame, hesitating screen, after more than 10 years of daily use) ... so I am not going to try such a procedure.

Girafon