Can't get repaired laptop to boot with my SSD

[Lady Fitzgerald]

My System 76 Serval WS laptop died recently and I had to ship it off to the factory for warranty repair (the diagnostics System 76 had me try suggested that the problem was hardware related, which was my guess from the get go; I haven't heard back from them yet what was repaired).

I when I first bought the machine replaced the factory boot SSD with Ubuntu installed with my own SSD (Samsung 970 Pro 512GB) and installed Linux Mint 19x Cinnamon 64bit (it had 19.3 when the laptop died). Before I shipped off, I removed all four of the SSDs, including the boot SSD, and replaced my boot SSD with the factory one.

After I got it back yesterday, I fired it up on battery power and it booted into Ubuntu as expected. I was too tired and sore from waddling errands during the day so I waited until a little while ago to swap out the factory boot SSD with my SSD and that was when the problems began.

Most of the time, it would take around 30 second or so to get what I believe is the grub screen (I'm still a bit hazy on what that is called) instead of a log in screen:

(Sorry for the fuzzy photo)

I clicked on the top line, which is for Mint 19.3, then after a few seconds, the round LM logo popped up and homesteaded on the screen for around a minute or so, then went to an error screen:

Not knowing what else to do (other than to cry), I shut down the computer by using SysRq + ALT and slowly typing R E I S U O (I had to do it twice every time to get it to shutdown).

So what do I do now to get this overpriced paperweight to properly boot?

[rene]

It's likely a matter of the UEFI entry needing to be restored. You could do so manually, but although I've no experience with it, boot-repair probably automates it for you. I.e., see https://www.fosslinux.com/1521/boot-rep ... issues.htm and boot from a Linux Mint Live USB/DVD to do so from.

[EDIT] Actually, looking better, the decipherable picture seems to imply it wouldn't be the UEFI entry as such, but still; reinstalling GRUB will no doubt do to fix it anyway, and this is what boot-repair will do for you.

[RollyShed]

Does the BIOS need to be changed from UEFI to Legacy?

It looks similar to the laptop I was working on last night, trying to find someone's password for Windows on an easy to change disks on laptop. I gave up and put my Linux Mint SSD back in and no boot - Oops, change the BIOS back to Legacy.

[Lady Fitzgerald]

It's likely a matter of the UEFI entry needing to be restored. You could do so manually, but although I've no experience with it, boot-repair probably automates it for you. I.e., see https://www.fosslinux.com/1521/boot-rep ... issues.htm and boot from a Linux Mint Live USB/DVD to do so from.

[EDIT] Actually, looking better, the decipherable picture seems to imply it wouldn't be the UEFI entry as such, but still; reinstalling GRUB will no doubt do to fix it anyway, and this is what boot-repair will do for you.

I want to ruminate on this a bit since I'm still recovering from waddling errands yesterday (and dealing with stupid people every step of the day) but I'll give it a shot later (probably tomorrow). I had to read that link several times before it started making sense (my fault, not the article's). I'll also have to physically horse around with my cables (involving moving some furniture around) to get things hooked up to where I access the internet on the machine and have power for the machine and still access this one.

[Lady Fitzgerald]

Does the BIOS need to be changed from UEFI to Legacy?

It looks similar to the laptop I was working on last night, trying to find someone's password for Windows on an easy to change disks on laptop. I gave up and put my Linux Mint SSD back in and no boot - Oops, change the BIOS back to Legacy.

On my machine, the BIOS is UEFI so I do not see why I would need to change it to Legacy, especially since the SSD, despite being only 512GB, is formatted GPT, not MBR.

[rene]

On my machine, the BIOS is UEFI so I do not see why I would need to change it to Legacy, especially since the SSD, despite being only 512GB, is formatted GPT, not MBR.

It depends on the mode, UEFI or Legacy, in which that Mint 19.x copy was installed originally --- but even though Legacy with GPT is not impossible, certainly normally GPT implies the system having been installed in UEFI mode so indeed you'd not need to switch/check. I also quite doubt that System76 will have reinstalled its OS in Legacy mode so "vice versa" is also quite unlikely, but since it's free and easy to check if something boots if you flip the BIOS mode...

But likely not, and boot-repair probably works easiest.

[RollyShed]

On my machine, the BIOS is UEFI so I do not see why I would need to change it to Legacy,

Having had to change all sorts of odd things in BIOSs of a range of various laptops, I'd certainly try it as it should be a quick and easy change. No fix, change back.

[Lady Fitzgerald]

The blasted POS is still not working correctly. I had one heck of a time just getting into my Live USB because the GPU fan sound like a B-17 starting up and it would occasionally shut down, apparently due to the CPU overheating. It took two tries to get the Boot-Repair Program installed (again, due to the CPU overheating and shutting down), then the darned program wouldn't work. It would not respond at all. I've sent a nastygram to System 76.

[rene]

Fan-control is (or, well, was historically) not necessarily well-defined and/or standard over systems. As such I'd say you absolutely need to test with the OS as supplied by System76 first: they (should) make sure that their own software offering runs well on their hardware --- that's in fact perhaps the largest part of their niche --- and if all's well with their own Ubuntu and/or Pop OS! install, it's going to need to be on you for running/installing Mint instead.

Which is not to say that I think it's likely Mint specific, but you're still going to have to test before the nastygram is allowed to get really nasty.

[Lady Fitzgerald]

Fan-control is (or, well, was historically) not necessarily well-defined and/or standard over systems. As such I'd say you absolutely need to test with the OS as supplied by System76 first: they (should) make sure that their own software offering runs well on their hardware --- that's in fact perhaps the largest part of their niche --- and if all's well with their own Ubuntu and/or Pop OS! install, it's going to need to be on you for running/installing Mint instead.

Which is not to say that I think it's likely Mint specific, but you're still going to have to test before the nastygram is allowed to get really nasty.

I did test first with the OS supplied by System 76. All I did was to see if it would boot, then shut it down. I guess I should have let it run for a while on Ubuntu.

Frankly, I'm mad enough right now to chew nails and spit out thumbtacks and sick and tired of fooling around with this POS. I'm going to let them fix it (this time, I'll send it back with my SSD; I have a backup SSD if they screw this one up) or tell me how to fix it (although, in the past, their directions have been so halfarsed, they must get twice the wear from toilet seats).

This was the nastygram I sent them:

Something is still wrong. When I first booted up the machine after getting it back, it seemed to boot ok. But, when I replaced the factory SSD with My SSD with Mint 19.3 installed on it, it wouldn't boot. According to the Mint forums, the boot loader was broken and it was suggested I use a program called Boot-Repair to fix it (https://www.fosslinux.com/1521/boot-rep ... issues.htm).

I had one heck of a time getting into my live USB (which as worked just fine in the past) because the CPU fan would rev up like a B-17 at start up and occasionally the computer would shut down, probably because the CPU was overheating. Once I got in, when I was trying to add the PPA, the computer again shut down. I managed to get the PPA and the program installed on the next attempt but the program wouldn't start. I finally got the program to start but when I clicked on Recommended Repair, nothing happened. After waiting five minutes. Still nothing. All this time, the GPU fan sounds like the computer is going take off and fly.

Now what?

[rene]

If I were to find that nasty I'd have to turn myself in to the police most days; looks fine to me. What I anyways can still only suggest is restore the SSD the machine came back with and boot/test with it. Admittedly, the USB having worked fine before says something, but step 1 still needs to be checking with their own OS, on which they may have for example installed a specific driver (-version) for the new GPU which that Mint live system doesn't have --- or something.

It's more the vice versa thing: if the system under their own OS does not behave, certainly you know it's their responsibility to fix.

[rene]

By the way, looking at https://github.com/system76/docs/blob/g ... manual.pdf it seems that the SSD is right below the GPU fan, so while you're in there, check if they e.g. managed to miss plugging it in (*) causing the CPU fan (on the right) to try and cool things down all by itself (and failing). Personally I'd just turn on the thing with that cover removed and actually look for fanspin.

(*) or you managed to drop the SSD retainer screw in the GPU fan, of course...

[Lady Fitzgerald]

I got a reply from System 76 suggesting I first try putting the factory SSD with Ubuntu installed back in to make sure the problem wasn't mechanical. I did and, other taking a long time to boot (almost a minute), it worked fine. I even played around on the internet to make sure it wasn't a flash in the pan.

I then put my Mint SSD back in and tried to follow the directions they suggested on their website. Bupkis. I'm guessing the packages that were supposed to download are no more or have been moved. I'm really getting fed up with bad directions.

Here are the results from the terminal:

Code: Select all

mint@mint:~$ sudo mount /dev/nvme0n1p2 /mnt
mount: /mnt: /dev/nvme0n1p2 already mounted on /mnt.
mint@mint:~$ sudo mount /dev/nevme0n1p1 /mnt/boot/efi
mount: /mnt/boot/efi: special device /dev/nevme0n1p1 does not exist.
mint@mint:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
mint@mint:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
mint@mint:~$ sudo cp -n /etc/resolv.conf /mnt/etc/
mint@mint:~$ sudo chroot /mnt
bash-4.4# apt install --reinstall grub-efi-amd64 linux-generic linux-headers-generic
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package linux-headers-generic is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

W: Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such file or directory)
W: Unable to read /etc/apt/sources.list.d/ - DirectoryExists (2: No such file or directory)
W: Unable to read /etc/apt/sources.list - RealFileExists (2: No such file or directory)
W: Unable to read /etc/apt/preferences.d/ - DirectoryExists (2: No such file or directory)
E: Unable to locate package linux-generic
E: Package 'linux-headers-generic' has no installation candidate
bash-4.4# update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-5.4.0-66-generic
/usr/sbin/mkinitramfs: 66: .: Can't open /etc/initramfs-tools/initramfs.conf
update-initramfs: failed for /boot/initrd.img-5.4.0-66-generic with 2.
bash-4.4# sudo update-grub
sudo: unknown uid 0: who are you?
bash-4.4# 

Right now, I'm mad enough to chew rebar and spit out sewing needles. I sent a polite nastygram (no, really, it was polite) to System 76 with the results and asking, "What now?" Most likely. I'm going to have to ship the POS back again.

[MurphCID]

I got a reply from System 76 suggesting I first try putting the factory SSD with Ubuntu installed back in to make sure the problem wasn't mechanical. I did and, other taking a long time to boot (almost a minute), it worked fine. I even played around on the internet to make sure it wasn't a flash in the pan.

I then put my Mint SSD back in and tried to follow the directions they suggested on their website. Bupkis. I'm guessing the packages that were supposed to download are no more or have been moved. I'm really getting fed up with bad directions.

Here are the results from the terminal:

Code: Select all

mint@mint:~$ sudo mount /dev/nvme0n1p2 /mnt
mount: /mnt: /dev/nvme0n1p2 already mounted on /mnt.
mint@mint:~$ sudo mount /dev/nevme0n1p1 /mnt/boot/efi
mount: /mnt/boot/efi: special device /dev/nevme0n1p1 does not exist.
mint@mint:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
mint@mint:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
mint@mint:~$ sudo cp -n /etc/resolv.conf /mnt/etc/
mint@mint:~$ sudo chroot /mnt
bash-4.4# apt install --reinstall grub-efi-amd64 linux-generic linux-headers-generic
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package linux-headers-generic is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

W: Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such file or directory)
W: Unable to read /etc/apt/sources.list.d/ - DirectoryExists (2: No such file or directory)
W: Unable to read /etc/apt/sources.list - RealFileExists (2: No such file or directory)
W: Unable to read /etc/apt/preferences.d/ - DirectoryExists (2: No such file or directory)
E: Unable to locate package linux-generic
E: Package 'linux-headers-generic' has no installation candidate
bash-4.4# update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-5.4.0-66-generic
/usr/sbin/mkinitramfs: 66: .: Can't open /etc/initramfs-tools/initramfs.conf
update-initramfs: failed for /boot/initrd.img-5.4.0-66-generic with 2.
bash-4.4# sudo update-grub
sudo: unknown uid 0: who are you?
bash-4.4# 

Right now, I'm mad enough to chew rebar and spit out sewing needles. I sent a polite nastygram (no, really, it was polite) to System 76 with the results and asking, "What now?" Most likely. I'm going to have to ship the POS back again.

Ugh, that stinks. Sometimes I think they got too cute with the Coreboot thing.

[rene]

Most likely. I'm going to have to ship the POS back again.

Nah. Try it again as below. In the same manner as their own advise, from a terminal on the Live system,

Code: Select all

$ sudo -s
# mount /dev/nvme0n1p2 /mnt
# mount /dev/nvme0n1p1 /mnt/boot/efi
# mount --bind /dev /mnt/dev
# mount --bind /sys /mnt/sys
# mount --bind /proc /mnt/proc
# chroot /mnt
# grub-install /dev/nvme0n1
# update-grub
# exit
# exit
$

Note; the "$" and "#" are prompt signs; you don't type them, just the actual commands. If you reboot after this you could have a bootable Mint 19 SSD again. It's in fact the thing I posted a number of times on this forum before and wanted to as such suggest to you originally as well until I thought... nah... let's not have her do that; boot-repair will be easier for her. Guess not. Note also; if that last update-grub step complains (I don't believe it would), never mind, should not be necessary anyway.

[Lady Fitzgerald]

Most likely. I'm going to have to ship the POS back again.

Nah. Try it again as below. In the same manner as their own advise, from a terminal on the Live system,

Code: Select all

$ sudo -s
# mount /dev/nvme0n1p2 /mnt
# mount /dev/nvme0n1p1 /mnt/boot/efi
# mount --bind /dev /mnt/dev
# mount --bind /sys /mnt/sys
# mount --bind /proc /mnt/proc
# chroot /mnt
# grub-install /dev/nvme0n1
# update-grub
# exit
# exit
$

Note; the "$" and "#" are prompt signs; you don't type them, just the actual commands. If you reboot after this you could have a bootable Mint 19 SSD again. It's in fact the thing I posted a number of times on this forum before and wanted to as such suggest to you originally as well until I thought... nah... let's not have her do that; boot-repair will be easier for her. Guess not. Note also; if that last update-grub step complains (I don't believe it would), never mind, should not be necessary anyway.

It didn't work. I got a grub screen that was for Ubuntu. Obviously, that got me nowhere. Here's what was in the terminal when booted into my Live Disk:

Code: Select all

mint@mint:~$ sudo -s
root@mint:~# mount /dev/nvme0n1p2 /mnt
root@mint:~# mount /dev/nvme0n1p1 /mnt/boot/efi
root@mint:~# mount --bind /dev /mnt/dev
root@mint:~# mount --bind /sys /mnt/sys
root@mint:~# mount --bind /proc /mnt/proc
root@mint:~# chroot /mnt
root@mint:/# grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
Installation finished. No error reported.
root@mint:/# update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/50_linuxmint.cfg'
Sourcing file `/etc/default/grub.d/60_mint-theme.cfg'
Generating grub configuration file ...
Found theme: /boot/grub/themes/linuxmint/theme.txt
Found linux image: /boot/vmlinuz-5.4.0-66-generic
Found initrd image: /boot/initrd.img-5.4.0-66-generic
Found linux image: /boot/vmlinuz-5.4.0-65-generic
Found initrd image: /boot/initrd.img-5.4.0-65-generic
Found linux image: /boot/vmlinuz-5.4.0-64-generic
Found initrd image: /boot/initrd.img-5.4.0-64-generic
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
grub-probe: error: cannot find a GRUB drive for /dev/sda2.  Check your device.map.
Adding boot menu entry for EFI firmware configuration
done
root@mint:/# exit
exit
root@mint:~# exit
exit
mint@mint:~$

[rene]

The "Ubuntu" nomer is just a display issue; it's normal that kernel entries are named that until Mint's adjustments infrastructure has had the change to adjust it, which is to say after booting it once. Also the terminal output seems to be saying all went completely fine. I take it the issue ended up being you after picking one of the entries from the Grub menu on reboot being again dumped into the same "emergency mode" as per your original screenshot?

If yes and if you in fact hit <enter> there and run journalctl -xb as it advises (arrow keys or page-up/down to scroll to the end) you may be informed of an issue. It's usually in fact you needing to run a manual fsck (even though I seem to remember it would be more vocal about that by default) and as such, you might be helped by from the command line prompt that you get there running

Code: Select all

e2fsck -fy /dev/nvme0n1p2

That should check your root filesystem and automatically repair inconsistencies. Use exit after it finishes to continue the boot if its appears to have done something.

If that by the way works the issue was unrelated to System76's repair but caused by you not having shut down the system cleanly the last time it ran before you removed that drive from it to ship it out.

[Lady Fitzgerald]

The "Ubuntu" nomer is just a display issue; it's normal that kernel entries are named that until Mint's adjustments infrastructure has had the change to adjust it, which is to say after booting it once. Also the terminal output seems to be saying all went completely fine. I take it the issue ended up being you after picking one of the entries from the Grub menu on reboot being again dumped into the same "emergency mode" as per your original screenshot?...

Forgive me from sounding dense but I don't understand the question.

...If yes and if you in fact hit <enter> there and run journalctl -xb as it advises (arrow keys or page-up/down to scroll to the end) you may be informed of an issue. It's usually in fact you needing to run a manual fsck (even though I seem to remember it would be more vocal about that by default) and as such, you might be helped by from the command line prompt that you get there running

Code: Select all

e2fsck -fy /dev/nvme0n1p2

That should check your root filesystem and automatically repair inconsistencies. Use exit after it finishes to continue the boot if its appears to have done something...

I'm still not getting the computer to boot into Mint. After the grub screen, it just display the LM logo and does nothing. Am I supposed to run those commands in a terminal from Mint loaded from my Live Disk?

...If that by the way works the issue was unrelated to System76's repair but caused by you not having shut down the system cleanly the last time it ran before you removed that drive from it to ship it out.

When the computer died, it died suddenly; the screen went black, the power button light went out, and the power button would not respond.

[MurphCID]

Wow that is really odd. I wonder why this is happening? Send it back, and send your Mint installation with it. Demand they fix it. I did, and I got a personal phone call from System 76! They were very nice on the phone.

[rene]

Forgive me from sounding dense but I don't understand the question.

I was asking if you again found yourself back in the situation as depicted in the second screenshot of your original post, i.e., the "You are in emergency mode" textmode screen; you had yourself only specified that things "got you nowhere" which doesn't provide enough information.

You have now however specified that you are hanging on a graphical Linux Mint logo screen. If you hit <Esc> when you are, you might be shown something useable for someone to further help with but I'm afraid I'll myself have to excuse myself from the thread: haven't been around due to not in fact often being on Mint currently and/because otherwise occupied, and although I thought my quick "boot-repair" advise would be useful, I can't be part of a long issues thread at the moment.

Do in any case note that System76 had you do basically the same as I did wrt. reinstalling Grub, and that it's now confirmed to not work. Not why but you may need to take care shipping it off again because they may in a fundamental sense feel it not their problem if their own Ubuntu install worked fine: Mint seems to now start booting with some specific issue keeping it from finishing booting. What I'd personally advise is if <Esc> doesn't reveal something useful and/or no one else is available to assist is to reinstall Mint; 20.x in that case so as to possibly sidestep the temperature/fan issue that you are for some unfathomable reason also experiencing on the 19.x Mint Live system.

When the computer died, it died suddenly; the screen went black, the power button light went out, and the power button would not respond.

... and, by the way, yes, that would certainly do as to needing a manual fsck now, but if you are not currently getting the option to do so from that "emergency" mode screen I'll have to excuse myself from the thread: originally thought quick boot-repair advise would be useful but can't be here currently.