Unable to start USB ISO, Watchdog CPU lockup

Hi there,

I used to run Archlinux on my laptop back when I still had time to fiddle with everything day after day. After quite a long break I felt like giving ArchLabs a try and get back into linux once more.
Unfortunately, I didn’t get too far…

I run a Dell XPS 15 9560 and read up about it on the archlinux wiki. I disabled SafeBoot, enabled the SATA AHCI and turned FastBoot to thorough, just as adviced. I then created the USB medium with Rufus according to the wiki, as well.
After booting the ISO, I select ArchLabs and it starts running just fine until it gets to the automatic user login line… it then basically halts and says “watchdog: BUG: soft lockup - CPU# stuck for 23s!” and a similar error msg with hard lockup instead. It repeats these error lines but doesn’t go on after that.

Any ideas on what could cause this error in such an early stage of running the ISO? Any help would be appreciated as I couldn’t find a solution in the arch wiki/forums or here in the forums.

Thanks a lot, cheers

1 Like

Hi @xsme I have ran into this situation before myself. I had found that the issue was using Rufus to burn the iso. Try using win32 or etcher instead. I am guessing that while Rufus is burning the iso onto the USB that it adds something that the iso doesn’t like.

1 Like

Thanks a lot for your reply, @sevenday4.
I tried setting up the USB boot drive with win32ImageWriter as well as etcher but unfortunately the same error appeared so that does not seem to be the issue.

Thanks @anon37345411. Yeah, trying to dual boot with Win10. Backed up all my documents before and Dell laptops have a built in Fall-Back Partition.
Out of interest I just tried running Manjaro off a USB ISO and it worked like a charm without changing any more settings. Weird (at least to me)…

Wonder if it s on the bios s settings side, don t have anything microsoft so can t validate.

1 Like

That might very well be the case. Thing is, I configured my BIOS according to the Arch wiki already and it still doesn’t work which bothers me because as far as I can see, noone else with my laptop model had that issue… at least not with vanilla Arch. So yeah… don’t really know where to start, to be honest.

1 Like

Please post your inxi -Fxz results from Terminal , it will help allot on pinpointing issues also.

There you go, hope it helps. From what I gathered, in the end it’s probably either BIOS related or because of the dedicated nvidia graphics card… but let’s see what the experts have to say!

[inxi Output cropped as it was unneccessary]

Good, I ve read that nVidia can be a pain sometimes with Linux, but let see what they ll have to say.

I doubt this is an issue related to a bad burn or anything like that, currently a watchdog module is blacklisted but it isnt supposed to have unwanted downsides for most.

I’m currently away from home till midweek but at that point I can push out a testing iso without the module blacklisted. You can also build yourself if you have access to an Arch based computer, simply follow the instructions on our bitbucket iso readme and remove archlabs/airootfs/etc/modprobe.d/blacklist.conf before building, or just wait till later this week.

Cheers

Thanks @natemaia , appreciate your help. I am in no particular hurry so I will wait for your next post whenever you have time!
Cheers

@xsme do you have the same issue with this iso?
https://drive.google.com/open?id=16oD96tcm4Hjzu-DXPrxJo7hB_3sbOqHp

1 Like

Thanks a lot for getting back to me @natemaia, appreciate it!
Downloading the *.iso now, will give it a try later tonight when I am home.

Alright, so I just gave it a spin. Unfortunately it causes the same error. I also tried unplugging all peripherals, etc. No solution, yet.
Any other ideas @natemaia ?

Sorry to hear that wasn’t a simple solution.

Have a read here and see if any of it is relevant for your situation
https://wiki.archlinux.org/index.php/Dell_XPS_15_9560

I’m at work currently and will be on later

Thanks, as I said in my first post, I did all those preparatory steps mentioned in the arch wiki regarding Dell XPS 9560. Everything else, it seems to me, is only relevant once you actually at least have the installer running…
I will go over it again but I do not expect any new insights.

edit: One thing I found under Troubleshooting is: “lspci causes CPU lockups”
Looks like I have to set certain kernel parameters to try and fix this.

edit2: ha! Gotta love the arch wiki. The following (as described in the wiki as well, just mentioning for completeness’ sake) worked:
Boot the live-iso, before selecting ArchLabs to boot, press e on the keyboard (whilst keeping the first entry of the list active) and add to the end of the line nouveau.modeset=0 then press enter and voila.

@natemaia thanks for making me have a look at the wiki again!

2 Likes

Very nice, I thought it may have something to do with lspci when having a browse around google for answers.

Glad you worked it out, let me know if you face any other issues during/after install

Cheers :slight_smile:

Just thought I’d share my experience with AL so far in this thread, as it is probably kind of related:

Install was quite painful, had to re-install like 5-6 times. First time was a corrupt install although I did not get any error messages during the install. Booted up fine, then had a hangup during the al-hello script (actually happened again and again, hard reboot required) and then everything was pretty much fcked up, did not start properly afterwards. At one time it just for the sake of it did not recognize my root pw anymore… changing root via live-boot with passwd --root did not work because of some segmentation error, so had to re-install again - and on and on it went.
Finally the install went through without a hitch, then the al-hello script froze again. After a hard-restart I recalled it via terminal and this time it worked. Shortly afterwards the system froze again. I rebooted and added acpi_rev_override=1 to the kernel line as well (additionally to nouveau.modeset=0).
Now everything seems to work fine… until the next freeze probably but I will report back then :wink:

Update 1: It keeps on giving!
Couldn’t get a dual boot with windows working, checked the EFI/Windows/Boot folder: no bootmgfw.efi in there. But I did not format the partition as there is lots of files still on there (dell, Windows, etc.) just not the required boot loader file. So booted up the Windows recovery medium, did bcdboot c:\windows -> fixed the issue but now automatically boots into Windows again. Will have to re-fix grub now…

Update 2: Light at the end of the tunnel…
Alright so I tried a few different things to determine the mount point of my efi partition and to convince grub that it can actually be found there. Just when I thought I had the solution, I put it in my custom.cfg and ran grub-mkconf only to see that it - somehow miraculously by itself - had now found the windows bootmgfw.efi without the help of my meticulously crafted code… and hear hear, after a reboot, dual boot now works fine with a completely obsolete additional grub boot menu entry, courtesy of me. gg.

RIP…

Sorry to hear it was that much of a struggle for you, myself and other members of the team/community do our best to test release ISOs on the hardware we have available, unfortunately that doesn’t seem to be enough as there are always cases like this pop up where people have difficult (at best) installs.

The iso I linked earlier in this thread had not been tested what so ever and after discovering the issue was boot level related I would always recommend using the release iso from our sourceforge page, though to be honest there is probably no real difference aside from a few package versions so I wouldn’t expect much.

At least grub and os-prober were able to find windows for you, generally all you would need to do is upon first boot run grub-mkconfig -o /boot/grub/grub.cfg as root and it should be able to find all the available bootloaders.

Until the next one :wink:

2 Likes

The iso I linked earlier in this thread had not been tested what so ever and after discovering the issue was boot level related I would always recommend using the release iso from our sourceforge page, though to be honest there is probably no real difference aside from a few package versions so I wouldn’t expect much.

That’s why I used the regular 2018-07 iso for the final install after finding out the testing iso did not work either :slight_smile:

Sorry to hear it was that much of a struggle for you, myself and other members of the team/community do our best to test release ISOs on the hardware we have available, unfortunately that doesn’t seem to be enough as there are always cases like this pop up where people have difficult (at best) installs.

Thanks so much, I immensely appreciate the work of the linux community with all the different distributions and super helpful communities. There hardly can be a system that’s working for everybody right out of the box, I guess.

At least grub and os-prober were able to find windows for you, generally all you would need to do is upon first boot run grub-mkconfig -o /boot/grub/grub.cfg as root and it should be able to find all the available bootloaders.

I guess it would have… but as the files were somehow missing I thought I had to do it manually. But as everything works fine now, no more hard feelings towards grub, haha!

Anyway, doing my best to set up a fully operational system now. Figured the bumblebee/bbswitch situation out this morning and now have a turned off dedicated gpu. Thing is, the gpu fan is still spinning but it looks like that’s a common problem for the XPS 9560s and Arch.
Also set up tlp and adapted polybar as well as some keybinds. It’s always so fun so set things up once the big chunk works!

1 Like