[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: initrd fails load with "ERROR: claim of 0xfe49172 in range 0x1340000-0x10000000 failed"

On 04/03/18 07:37 AM, Frank Scheiner wrote:
Hi Dennis,

Hi Frank and thank you for the reply. I was worried I would hear nothing
but silence on this mail list. Sometimes that happens and I think your
email has really shed light on the some issues. I think.

On 03/04/2018 04:11 AM, Dennis Clarke wrote:
I had to take a picture of the screen but really it seems to say that my
new initrd will not load into memory for some reason. Perhaps too darn
big? ...

Firstly I had to boot the Debian 8.10 PPC dvd into rescue mode to get at
the good stuff in /dev/sda3 and reverse the symlinks back to ye 4.13.0.
Boot normally, no penguins seen ( I like the penguin logos at the top )
and then ssh back in. Well, to be honest, the new initrd.img-4.15.6 has
everything in it from soup to nuts. So it is frightfully large :

nix$ pwd
nix$ ls -lapb
total 473692
drwxr-xr-x  2 root root      4096 Mar  4 22:16 ./
drwxr-xr-x 23 root root      4096 Oct 22 21:04 ../
-rw-r--r--  1 root root    167163 Nov 16 21:04 config-4.13.0-1-powerpc64
-rw-r--r--  1 root root    169228 Feb 26 14:03 config-4.15.6
lrwxrwxrwx 1 root root 29 Mar 4 22:16 initrd.img -> initrd.img-4.13.0-1-powerpc64
-rw-r--r--  1 root root  20972026 Dec 10 20:42 initrd.img-4.13.0-1-powerpc64
-rw-r--r--  1 root root 266633586 Mar  3 22:54 initrd.img-4.15.6
lrwxrwxrwx 1 root root 29 Oct 15 04:33 initrd.img.old -> initrd.img-4.13.0-1-powerpc64
-rw-r--r--  1 root root   3965638 Nov 16 21:04 System.map-4.13.0-1-powerpc64
-rw-r--r--  1 root root   4059340 Feb 26 19:18 System.map-4.15.6
lrwxrwxrwx 1 root root 26 Mar 4 22:16 vmlinux -> vmlinux-4.13.0-1-powerpc64
-rwxr-xr-x  1 root root  19956624 Nov 16 21:04 vmlinux-4.13.0-1-powerpc64
-rwxr-xr-x  1 root root 168796832 Feb 26 19:18 vmlinux-4.15.6
lrwxrwxrwx 1 root root 26 Oct 15 04:33 vmlinux.old -> vmlinux-4.13.0-1-powerpc64

How large are your initrds (for 4.13.x and 4.15.x) currently? I upgraded yaboot from 1.3.16 to 1.3.17 just now on my Mac mini G4 (w/Debian version of Linux 4.15.4) and tested with an 18 MiB (18366537 Bytes) sized initrd without an issue.

I think a 254MB initrd may be the issue. However I can not tell why given that the system has 8GB of memory and I would not have thought a large initrd would be such an issue. Then again, it is compressed and once unpacked it is a whopping 773MB in size. Wonderful to run nearly
everything I want in memory and then bring along disk based partitions
later but perhaps obscene for ye old PowerMac G5 and yaboot. Regardless
I was able to use openfirmware magic to load the whole mess into memory
and start the boot process only to see that my ext3 filesystem was not
supported? I was shocked to say the least.

see https://i.imgur.com/0EdtoGQ.jpg

Unfortunately I don't have a G5 at hand that still uses yaboot.

I really wish grub2 were the boot loader however that is an entirely
other kettle of fish.  Makes me wonder what bootloader is used in the
RHEL 7.4 product for the IBM Power servers.  Possibly yaboot.

You could first check if your initrd gets (considerably) smaller when configuring "Modules=dep" in `/etc/initramfs-tools/initramfs.conf` and rebuilding it and then try with the resulting initrd.

That is exactly where I am going to head first. However, I need to be
very aware that I saw "List of all partitions:" report exactly nothing.
Well that can't be right at all.

Or if that doesn't help, you can also limit the modules included into your initrd with `/etc/initramfs-tools/modules` and make sure that "MODULES=list" is configured in `/etc/initramfs-tools/initramfs.conf`.

That may be a more trivial path to try first.  I was giving thought to
doing a kernel build just for the purpose of booting the system with
minimal modules. Very very minimal.  In fact, all modules compiled in
and then see if I can get to a sane state.

To get the list of "needed" modules, you can boot with Linux 4.13.x and collect the list of modules from `lsmod` output. You only need the modules really required to access your root file system.

Still seems like a long list :

nix$ lsmod | awk '{ print $3 " " $1 }' | grep -v "^0"
Used Module
1 sil164
1 nouveau
1 ttm
1 snd_aoa_i2sbus
1 drm_kms_helper
2 snd_aoa_soundbus
5 drm
1 snd_pcm
2 evdev
1 i2c_algo_bit
1 snd_timer
2 snd_aoa_codec_onyx
2 snd_aoa
6 snd
1 soundcore
1 x_tables
2 autofs4
1 ext4
1 crc16
1 mbcache
1 fscrypto
1 jbd2
3 sd_mod
2 hid
1 windfarm_cpufreq_clamp
1 libphy
1 ptp
1 windfarm_smu_sensors
8 windfarm_smu_controls
1 windfarm_pid
1 windfarm_max6690_sensor
1 ohci_hcd
1 windfarm_lm75_sensor
9 windfarm_smu_sat
1 ehci_hcd
7 windfarm_core
1 firewire_core
1 crc_itu_t
5 usbcore
1 cdrom
2 sata_svw
1 usb_common
1 pps_core

I should like to jettison nouveau and everything to do with audio. I
have no idea what "windfarm" is but certainly firewire is useless to me.
However for that I need to figure out a serial port which is somewhere
inside the system and then set console as ttyS0 or similar. That won't
happen today and I don't even know if I can get a serial PCI card to
work in this box.  Would be nice. Usually the classic PCI DigiBoards
will function *everywhere* as their driver code is awesome.

On another test box I see it as :

02:05.0 Serial controller: Digi International Digi Neo 2 DB9 (rev 01) (prog-if 02 [16550])
        Subsystem: Digi International Digi Neo 2 DB9
        Flags: fast devsel, IRQ 20, NUMA node 0
        Memory at fea00000 (32-bit, non-prefetchable) [size=1K]
        Kernel driver in use: jsm
        Kernel modules: jsm

So kernel module jsm should do the trick.

Before issuing `update-initramfs [...]` for both alternatives check that no file in `/etc/initramfs-tools/conf.d` reconfigures "MODULES=" as configurations in these files have precedence over configurations in `/etc/initramfs-tools/initramfs.conf`.


Thank you so much for the info and I will go back to pecking at this and see if the real issue is the non-detection of the disk partitions OR the out right size of the initrd. Oddly enough, apples and oranges I know, but my initrd on test x86_64 platforms is massive also :

fs$ uname -r
fs$ ls -lap /boot
total 297752
drwxr-xr-x  4 root root      4096 Feb 26 15:53 ./
drwxr-xr-x 23 root root      4096 Nov 10 22:22 ../
-rw-r--r--  1 root root    196564 Nov 16 16:04 config-4.13.0-1-amd64
-rw-r--r--  1 root root    197958 Feb 26 15:52 config-4.15.6
drwxr-xr-x  5 root root      4096 Feb 26 15:54 grub/
-rw-r--r--  1 root root  20168251 Dec 31 21:52 initrd.img-4.13.0-1-amd64
-rw-r--r--  1 root root 268117455 Feb 26 15:53 initrd.img-4.15.6
drwx------  2 root root     16384 Nov 10 21:32 lost+found/
-rw-r--r--  1 root root    182704 Jun 25  2015 memtest86+.bin
-rw-r--r--  1 root root    184840 Jun 25  2015 memtest86+_multiboot.bin
-rw-r--r--  1 root root   2998208 Nov 16 16:04 System.map-4.13.0-1-amd64
-rw-r--r--  1 root root   3068245 Feb 26 15:52 System.map-4.15.6
-rw-r--r--  1 root root   4466448 Nov 16 16:04 vmlinuz-4.13.0-1-amd64
-rw-r--r--  1 root root   4929296 Feb 26 15:52 vmlinuz-4.15.6

Works fine ... with grub2 of course.


Reply to: