LM 17.3 Boot bug - boot repair fails [SOLVED]
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
LM 17.3 Boot bug - boot repair fails [SOLVED]
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
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
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: LM 17.3 Boot bug - boot repair fails
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
(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.
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
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.
Re: LM 17.3 Boot bug - boot repair fails
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:
What else could I try ?
Girafon
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
Girafon
Re: LM 17.3 Boot bug - boot repair fails
(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
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
(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.
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
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 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.
Re: LM 17.3 Boot bug - boot repair fails
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 :
What could we conclude from this ?
Girafon
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
Girafon
Re: LM 17.3 Boot bug - boot repair fails
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
3 ) Edit the fstab to deactivate the mounting of the USB stick and "Documents" partition
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
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
6 ) From your paste.ubuntu report, your kernel seems to be 3.16.0-38-generic. But let's check this to be sure :
it should give something like this
(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)
In my case this gives
(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
this will take some minutes, depending on the speed of your internet connection
9 ) Now we exit the chroot and clean up
10 ) Reboot, cross your fingers
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
Code: Select all
sudo nano /mnt/etc/fstab
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
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
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]
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
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]
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
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
Re: LM 17.3 Boot bug - boot repair fails
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 :
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
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
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
Re: LM 17.3 Boot bug - boot repair fails
Hello again,
I confirm that when I try to boot Linux, it refers to boot/vmlinuz-3.16.0-38-generic.
Girafon
I confirm that when I try to boot Linux, it refers to boot/vmlinuz-3.16.0-38-generic.
Girafon
Re: LM 17.3 Boot bug - boot repair fails
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
if all goes well you should get something like
(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
(I want to check you got chrooted into the good partition)
4 ) Let's use another tool to see if the kernel is installed :
(in the previous post, I used
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 :
(note I use apt-get now, to be sure it works on Mint 17)
If you get something like this
then slap a --reinstall option :
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
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
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
4 ) Let's use another tool to see if the kernel is installed :
Code: Select all
dpkg --get-selections | grep linux-image
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
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.
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
Re: LM 17.3 Boot bug - boot repair fails
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 :
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 :
What do you think of this result ?
Girafon
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"
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
Girafon
Re: LM 17.3 Boot bug - boot repair fails
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
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
Re: LM 17.3 Boot bug - boot repair fails
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.
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.
Re: LM 17.3 Boot bug - boot repair fails
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
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
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 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.Re: LM 17.3 Boot bug - boot repair fails
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
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
Re: LM 17.3 Boot bug - boot repair fails [SOLVED]
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
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.
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.
Re: LM 17.3 Boot bug - boot repair fails [SOLVED]
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
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
Re: LM 17.3 Boot bug - boot repair fails [SOLVED]
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)
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)
Re: LM 17.3 Boot bug - boot repair fails [SOLVED]
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
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