boot loop when trying to install arch iso from usb

ozooha · 2017-01-01 17:18:41

I following the installation method of using dd to install the latest Arch iso on a usb.

sudo dd bs=4M if=Downloads/archlinux-2016.12.01-dual.iso of=/dev/sdd && sync

I plug the usb and start the pc and then i run into issues. Upon booting up, it lets me go into the UEFI installer,
along with other options (see below). I press the first option annd then it

1) boot into arch
2) start uefi shell v1
3) start uefi shell v2
4) go to firmware

gives me a black screen for a second, and reboots into itself. Then, it repeats the process.

The same USB however works fine on my desktop which has no UEFI but just BIOS.

Can anyone help please.
Let me know if you require any further information.
OZooHA

loafer · 2017-01-01 21:33:08

Are you sure it's not KMS? What happens with it disabled?

Head_on_a_Stick · 2017-01-01 21:33:44

Does the ISO boot normally if you disable UEFI?

elvith32 · 2017-01-02 09:10:41

kvm has nothing to do with that issue, try booting your usb without uefi.

Shrom59 · 2017-01-02 10:41:02

I had this problem too, my one came from my motherboard setting who is protected (Windows was installed and the UEFI was protected). Hope it wil help you

ozooha · 2017-01-03 18:52:11

Forgive my tardiness.
I finally got to boot it up using the method shown in this url
http://tuxdiary.com/2013/06/22/install-archbang
and then adding acpi=off as a kernel parameter.
I noticed that it did not shutdown instead was suspended and I had to manually shut it down using the power button.
I also ensured that the BIOS was the most current version.

Its working alright but I do not want that kernel parameter as I believe it might hinder the power management features of my MoBo FM2-A85XA-G65.
Are there any suggestions, ideas etc?

I had a old arch.iso which i believe was a 4.2 kernel and it helped me boot into my PC to install.
Is this a kernel issue? Should i wait for the next one (i.e. iso with the new kernel) to come out?

A recent live Linux Mint booted fine for both and so did an old kernel (4.5 I think) of ARCHBANG.

Please advice.
Thanks.
OZooHA

Last edited by ozooha (2017-01-03 21:12:59)

ozooha · 2017-01-03 18:58:09

@elvith32 and @2Head_on_a_Stick
With the UEFI the screen went dark and into the boot loop.
With the BIOS the screen showed the first few lines and then went into the boot loop.
My Mobo (see link in the above post) has UEFI or legacy+UEFI options to boot.

Clarification:The same USB however works fine on my desktop which has no UEFI but just BIOS.
What i meant was when I used the same usb on a desktop which had no UEFI but only BIOS it booted off normally.

@Shrom59
I do not have any Windows installed on this board. I wanted to just install Arch.

I hope this helps.
OZooHA

Last edited by ozooha (2017-01-04 00:42:24)

kgtuning · 2017-01-03 21:13:51

hello, do you have a video card? or onboard video like intel hd graphics?

ozooha · 2017-01-04 00:40:27

@kgtuning
Yes its an APU: AMD A4-5300 APU 3.4Ghz Processor AD5300OKHJBOX
GPU Type: Radeon HD 7480D
I am using two monitors DVI (1680x1050) and HDMI (1920x1080).

Last edited by ozooha (2017-01-04 01:53:19)

seth · 2017-01-04 08:54:09

There's a bunch of acpi related parameters, notably quirks to deal with interesting HW - see http://lxr.free-electrons.com/source/Do … meters.txt (kernel.org link is 404)
You might try different modes, fake os/osi, force pm_good and adjust the sleep options; that's just poking around, though.

ozooha · 2017-01-04 12:28:20

@seth
Thanks but no thanks. I want to keep it simple as I suspect its a regression bug or something in the current Arch iso. The reason for my suspicion is because (see above) the Linux mint and an old ArchBang iso booted in fine without any hassles.
But thanks for you feedback, appreciate the effort and thought.
OZooHA

seth · 2017-01-04 14:02:33

If you directly move into S3, it's (if at all) more like a regression (if so) in the kernel acpi stack which will sooner or later bite you again...

ozooha · 2017-01-04 16:45:51

So my suspicion was correct it is a regression issue.
Here is how I went about finding it out:

Downloaded the archive isos for 2016-10-01, 2016-11-01 and 2017-01-01.
The 2016-12-01 iso was the current iso giving me the issue (hence this thread).
Kernel 4.8 and its variants were giving me issues which are present in isos 2016-11-01, 2016-12-01 and 2016-01-01.
The 2016-12-01 and 2016-01-01 (kernel 4.8-13 I think) isos did not work unless I used acpi=off however for the 2016-11-01 (kernel 4.8-6 I think) one I had to force radeon.dpm=1 (which should have been there by default) for it to work.
The 2016-10-01 (kernel 4.7-5 I think) worked straight up without any extra kernel parameters.

The above therefore suggests, in my limited knowledge, that this is a regression issue. Can anyone please confirm or refute my understanding?

Also, will it hurt me if after installing from the 4.7 kernel I upgraded to the 4.8 kernel (to me it seems obvious that it will but wanted to know your take)?

Thanks for your attention and please do let me know if there is anything i can do to fix my install.

OZooHA

seth · 2017-01-04 17:00:50

The point is that just as the radeon module defaults (which should autodetect DPM support) is a matter of the linux kernel. It's not arch related and unless fixed upstream, will hit you on *any* distro sooner or later. So if you're unwilling to dig into what is happening here, this is a pointless excercise.
You can either use an older install media and install the lts kernel or use some ubuntu derivate - in any case "then hope for the best"

ACPI has extensive debugging and config support because any vendor just provides his interpretation of ACPI (ie. it worked on the system he used for testing, usually some windows version)
You might face either a regression or a glitchy new feature - we don't know by some sort of magic. You really need to figure what it is, in doubt by bisecting the kernel sources.

For the beginning, google your exact board for acpi and linux, maybe it already provides an answer.

loqs · 2017-01-04 20:00:50

See Kernels#Official_packages for prebuilt kernels supplied in the official repositories.
linux currently on 4.8.13-1 tracks kernel.org's stable release currently on 4.8.15 although with the release of 4.9.1rc barring an issue with the release candidate 4.9.1 will soon be kernel.org's stable release.
linux-lts currentily on 4.4.39-1 tracks kernel.orgs newest longterm release currently on 4.4.39 the next upstream longterm release is expected to be based on 4.9 or 4.10.
You can have multiple kernel packages installed such as having both linux and linux-lts installed together space allowing.
Would recommend using linux-lts and bisect the issue between 4.7 and 4.8 and report it upstream and it may get fixed before the linux-lts is rebased onto a kernel newer than 4.7
Also are you using i686 or x86_64?

ozooha · 2017-01-04 21:16:59

seth wrote:

The point is that just as the radeon module defaults (which should autodetect DPM support) is a matter of the linux kernel. It's not arch related and unless fixed upstream, will hit you on *any* distro sooner or later. So if you're unwilling to dig into what is happening here, this is a pointless excercise.
You can either use an older install media and install the lts kernel or use some ubuntu derivate - in any case "then hope for the best"
ACPI has extensive debugging and config support because any vendor just provides his interpretation of ACPI (ie. it worked on the system he used for testing, usually some windows version)
You might face either a regression or a glitchy new feature - we don't know by some sort of magic. You really need to figure what it is, in doubt by bisecting the kernel sources.
For the beginning, google your exact board for acpi and linux, maybe it already provides an answer.

I took into account every possible acpi kernel parameter suggested by your link earlier in this thread and none of them worked barring the acpi=off and of course the radeon.dpm=0.
The latter was suggested by the MSI forum for these particular MoBos https://forum-en.msi.com/index.php?topic=260776.0
So I still think its (from what I gather by the results from your suggestions and my evidence gathering) an issue with the kernel testing since it works with the latest 4.8 kernel version of Ubuntu.
However I appreciate your thoughts and inputs and for that many thanks.
OZooHA

Last edited by ozooha (2017-01-04 21:27:47)

ozooha · 2017-01-04 21:26:18

loqs wrote:

See Kernels#Official_packages for prebuilt kernels supplied in the official repositories.
linux currently on 4.8.13-1 tracks kernel.org's stable release currently on 4.8.15 although with the release of 4.9.1rc barring an issue with the release candidate 4.9.1 will soon be kernel.org's stable release.
linux-lts currentily on 4.4.39-1 tracks kernel.orgs newest longterm release currently on 4.4.39 the next upstream longterm release is expected to be based on 4.9 or 4.10.
You can have multiple kernel packages installed such as having both linux and linux-lts installed together space allowing.
Would recommend using linux-lts and bisect the issue between 4.7 and 4.8 and report it upstream and it may get fixed before the linux-lts is rebased onto a kernel newer than 4.7
Also are you using i686 or x86_64?

I am using x86_64.
Thanks for the suggestions. Yes I will go ahead and install the most recent build with the kernel parameter and then use the other kernel variants from your link.
That's a good suggestion. Thank you.
OZooHA

seth · 2017-01-04 21:34:09

Ubuntu is at 4.8.0 - you say you had degressive behavior: 4.7.5 works, 4.8.5 needs radeon.dpm disabled and 4.8.13 fails on acpi support. did you consider an arch iso with 4.8.0? ...

ozooha · 2017-01-06 02:16:55

I am on linux-zen ver 4.8.14-1-zen without any acpi or radeon.dpm parameters and its zen!
OZMan ozzeth

arshlinux · 2017-07-18 02:47:22

I had the same issue, here is the exact steps on how I solved it (thanks to this thread). The goal is to to launch the kernel included in the Archiso with the following kernel parameter: acpi=off

Download the lastest Archiso: https://www.archlinux.org/releng/releases/2017.07.01/ to archlinux-2017.07.01-x86_64.iso

As root:

Mount the ISO to this directory (due to the nature of ISOs, the result is read-only):

mount -t iso9660 -o loop archlinux-2017.07.01-x86_64.iso /mnt

Copy the contents to another directory, where they can be edited:

cp -a /mnt ~/customiso

Change into the directory of the x86_64 system:

cd ~/customiso/arch/x86_64

Unsquash airootfs.sfs (to squashfs-root) (package squashfs-tools):

$ unsquashfs airootfs.sfs
$ cd squashfs-root/boot/grub

Add the acpi=off kernel parameter to grub.cfg:

...
        echo    'Loading Linux core repo kernel ...'
        linux   /boot/vmlinuz-linux root=UUID=ad4103fa-d940-47ca-8506-301d8071d467 acpi=off rw  quiet
        echo    'Loading initial ramdisk ...'
...
        echo    'Loading Linux core repo kernel ...'
        linux   /boot/vmlinuz-linux root=UUID=ad4103fa-d940-47ca-8506-301d8071d467 acpi=off rw  quiet
        echo    'Loading initial ramdisk ...'
...

Now recreate airootfs.sfs:

$ rm airootfs.sfs
$ mksquashfs squashfs-root airootfs.sfs

Cleanup:

# rm -r squashfs-root

Now update the MD5 checksum of airootfs.sfs:

$ md5sum airootfs.sfs > airootfs.md5

Find the original ISO disk label (ARCH_201209) required for the next step:

ls /dev/disk/by-label

Create a new EFI bootable ISO image for booting from a USB stick (package xorriso):

$ cd ~/customiso
$ xorriso -as mkisofs \
       -iso-level 3 \
       -full-iso9660-filenames \
       -volid "ARCH_201209" \
       -eltorito-boot isolinux/isolinux.bin \
       -eltorito-catalog isolinux/boot.cat \
       -no-emul-boot -boot-load-size 4 -boot-info-table \
       -isohybrid-mbr ~/customiso/isolinux/isohdpfx.bin \
       -eltorito-alt-boot \
       -e EFI/archiso/efiboot.img \
       -no-emul-boot -isohybrid-gpt-basdat \
       -output arch-custom.iso \
       ~/customiso

Times like this reminds me how precious and surprisingly up to date is the Wiki: https://wiki.archlinux.org/index.php/Re … nstall_ISO

P.S: What is the difference between a command line starting with $ or # in the ArchWiki?

Last edited by arshlinux (2017-07-18 02:57:13)

seth · 2017-07-18 06:08:37

Next time you just can do https://wiki.archlinux.org/index.php/Ke … eters#GRUB ... :-P

$ and # usually refer to the bash prompt of an unprivileged and the root user (but that's no actual standard, just a common setup.

WorMzy · 2017-07-18 12:57:53

The liveCD doesn't use grub, but you can edit the syslinux/systemd-boot kernel lines in a similar way.

Anyway, as this is an old thread, I'm going to go ahead and close it now.

Closing.

Last edited by WorMzy (2017-07-18 12:58:21)

Arch Linux

#1 2017-01-01 17:18:41

boot loop when trying to install arch iso from usb

#2 2017-01-01 21:33:08

Re: boot loop when trying to install arch iso from usb

#3 2017-01-01 21:33:44

Re: boot loop when trying to install arch iso from usb

#4 2017-01-02 09:10:41

Re: boot loop when trying to install arch iso from usb

#5 2017-01-02 10:41:02

Re: boot loop when trying to install arch iso from usb

#6 2017-01-03 18:52:11

Re: boot loop when trying to install arch iso from usb

#7 2017-01-03 18:58:09

Re: boot loop when trying to install arch iso from usb

#8 2017-01-03 21:13:51

Re: boot loop when trying to install arch iso from usb

#9 2017-01-04 00:40:27

Re: boot loop when trying to install arch iso from usb

#10 2017-01-04 08:54:09

Re: boot loop when trying to install arch iso from usb

#11 2017-01-04 12:28:20

Re: boot loop when trying to install arch iso from usb

#12 2017-01-04 14:02:33

Re: boot loop when trying to install arch iso from usb

#13 2017-01-04 16:45:51

Re: boot loop when trying to install arch iso from usb

#14 2017-01-04 17:00:50

Re: boot loop when trying to install arch iso from usb

#15 2017-01-04 20:00:50

Re: boot loop when trying to install arch iso from usb

#16 2017-01-04 21:16:59

Re: boot loop when trying to install arch iso from usb

#17 2017-01-04 21:26:18

Re: boot loop when trying to install arch iso from usb

#18 2017-01-04 21:34:09

Re: boot loop when trying to install arch iso from usb

#19 2017-01-06 02:16:55

Re: boot loop when trying to install arch iso from usb

#20 2017-07-18 02:47:22

Re: boot loop when trying to install arch iso from usb

#21 2017-07-18 06:08:37

Re: boot loop when trying to install arch iso from usb

#22 2017-07-18 12:57:53

Re: boot loop when trying to install arch iso from usb

Board footer