[solved] Re: Trying to deug initramfs boot delay
Hi, thanks, Andrew and Charles for the replies. I finally managed to (sort of) fix the issue with the delayed boot. First, for the record, in case someone comes here via the archives: the ".enuineIntel.align.0123456789abc" file in the initrd appears to be quite normal (strange as it sounds - at least to me), as well as the many lines in the initramfs.debug file looking like + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue followed by a return value of 1. I checked with an ancient Dell Latitude X1 laptop with bullseye 32-bit installed I have here (I don't know why it never occured to me to look there before starting to asking dumb questions on the list). On Tue, 22 Feb 2022 09:45:34 + "Andrew M.A. Cater" wrote: (...) > I have one of these: I found that the multi-arch .iso worked better. > The UEFI in these is 32 bti, the processor is 64 bit - that might > have something to do with it, particularly if there's some alignment > issue. > > Mine doesn't stop for many seconds - but that's only one datum point. You are right, of course! Out of my usual stupdity I spent a few hours with fruitless attempts before the simplest solution came to my mind. In fact all I had to do was to turn my 32-bit installation into multiarch with # sudo dpkg --add-architecture amd64 followed by # apt-get update # apt-get install linux-image-amd64 which here replaced the 32-bit apparmor with its amd64-counterpart and installed a number of 64-bit libraries along with the amd64 kernel. Then reboot into the amd64 kernel, and voilà! Loading the initrd now for unknown reasons is still a bit slow (9-10 sec. compared to 2-3 sec. with the otherwise considerably slower Latitude X1), but this certainly doesn't bother me enough to go into "debug mode" again :-) (...) > I used the unofficial .iso including non-free firmware. Oh yes, I forgot to mention. Of course I used that one, too. I don't think I'd get far with this laptop without the non-free firmware... Thanks again, and have a nice day, Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7 (when reading the news these days, unfortunately one might feel tempted to contradict the Captain's statement)
Re: Trying to deug initramfs boot delay
On Tue, Feb 22, 2022 at 09:19:14AM -0700, Charles Curley wrote: > On Tue, 22 Feb 2022 09:45:34 + > "Andrew M.A. Cater" wrote: > > > I think Charles Curley is also installing on one, too. > > I am installing on an Ideapad, a "Lenovo IdeaPad Yoga 13". I have not > seen anything like what the OP, Michael Lange , > describes. Indeed, my beastie boots very quickly. > > > > > I used the unofficial .iso including non-free firmware. > > As did I. According to /etc/apt/sources.list, "Debian GNU/Linux 11.2.0 > _Bullseye_ - Unofficial amd64 NETINST with firmware 20211218-11:12" > > Note that I went full Amd64. I wonder if the OP might be better off > with that. > The Ideapad 100S is one of the Bay Lake Intels with 32 bit UEFI and 64 bit processor - hence the suggestion for multi-arch. These and similar were deliberately released on cut down hardware to fill a market niche - I think Windows 7 S - one application at a time, essentially, and were designed down to a price point in terms of limited memory. All the very best, as ever, Andy Cater > -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ >
Re: Trying to deug initramfs boot delay
On Tue, 22 Feb 2022 09:45:34 + "Andrew M.A. Cater" wrote: > I think Charles Curley is also installing on one, too. I am installing on an Ideapad, a "Lenovo IdeaPad Yoga 13". I have not seen anything like what the OP, Michael Lange , describes. Indeed, my beastie boots very quickly. > > I used the unofficial .iso including non-free firmware. As did I. According to /etc/apt/sources.list, "Debian GNU/Linux 11.2.0 _Bullseye_ - Unofficial amd64 NETINST with firmware 20211218-11:12" Note that I went full Amd64. I wonder if the OP might be better off with that. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Trying to deug initramfs boot delay
On Tue, Feb 22, 2022 at 12:50:13AM +0100, Michael Lange wrote: > Hi, > > I installed bullseye (32-bit) onto a Lenovo IdeaPad 100S laptop. The > system generalliy runs fine, however there is a minor nuisance with a > delay of about 40 sec. at the begining of the boot process at the > "Loading initial ramdisk..." stage. > I have one of these: I found that the multi-arch .iso worked better. The UEFI in these is 32 bti, the processor is 64 bit - that might have something to do with it, particularly if there's some alignment issue. Mine doesn't stop for many seconds - but that's only one datum point. I think Charles Curley is also installing on one, too. I used the unofficial .iso including non-free firmware. > available hard drive partitions, which somehow at some point seems to > fail. > I don't really know what the function that is responsible here tries to > do, but it looks like a lot of lines to me for the three partitions on the > laptop's drive (output of lsblk: > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > mmcblk2 179:00 29,1G 0 disk > ├─mmcblk2p1 179:10 100M 0 part /boot/efi > ├─mmcblk2p2 179:20 3,4G 0 part [SWAP] > └─mmcblk2p3 179:30 22,9G 0 part / > mmcblk2boot0 179:256 04M 1 disk > mmcblk2boot1 179:512 04M 1 disk > > cont. of /etc/fstab: > > # / was on /dev/mmcblk1p3 during installation > UUID=ba9bd08f-5a25-4e42-95a4-ce0fa41be38d / ext4 > errors=remount-ro 0 1 > # /boot/efi was on /dev/mmcblk1p1 during installation > UUID=78BA-12AF /boot/efi vfatumask=0077 0 1 > # swap was on /dev/mmcblk1p2 during installation > UUID=e1016bf0-5a98-4269-9e94-01ec54f1d541 noneswap > sw 0 0 > > ) > > Does anyone have a clue if either of these two things might be the > problem here, or -if not- what else I could try to identify the problem's > source? > > Thanks in advance, and have a nice day, > > Michael > With every good wish, as ever, Andrew Cater > .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. > > It is a human characteristic to love little animals, especially if > they're attractive in some way. > -- McCoy, "The Trouble with Tribbles", stardate 4525.6 >
Re: Trying to deug initramfs boot delay
On 2022-02-22 00:50 UTC+0100, Michael Lange wrote: > First, when I run lsinitramfs on the initrd in use, the first items of > the command's output are: > > kernel > kernel/x86 > kernel/x86/microcode > kernel/x86/microcode/.enuineIntel.align.0123456789abc > kernel/x86/microcode/GenuineIntel.bin > > Now, ".enuineIntel.align.0123456789abc" looks odd to me, can this > possibly be normal? Or is it possible that somehow this file name is > malformed and causes trouble while trying to apply the microcode? This seems to be normal, I get the same output. -- http://www.cb-fraggle.de
Trying to deug initramfs boot delay
Hi, I installed bullseye (32-bit) onto a Lenovo IdeaPad 100S laptop. The system generalliy runs fine, however there is a minor nuisance with a delay of about 40 sec. at the begining of the boot process at the "Loading initial ramdisk..." stage. Trying to debug this I found two things that seemed suspicious to me, but I do not know, if these might really be responsible for the delay. First, when I run lsinitramfs on the initrd in use, the first items of the command's output are: kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/.enuineIntel.align.0123456789abc kernel/x86/microcode/GenuineIntel.bin Now, ".enuineIntel.align.0123456789abc" looks odd to me, can this possibly be normal? Or is it possible that somehow this file name is malformed and causes trouble while trying to apply the microcode? Second, when I add the "debug" option to the kernel command line and look at the /run/initramfs/initramfs.debug file, I find the following: + '[' -f /root/etc/fstab ] + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + '[' / '=' /usr ] + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + '[' /boot/efi '=' /usr ] + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + continue + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + '[' none '=' /usr ] + read -r MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK + return 1 I guess this has something to do with the system trying to detect the available hard drive partitions, which somehow at some point seems to fail. I don't really know what the function that is responsible here tries to do, but it looks like a lot of lines to me for the three partitions on the laptop's drive (output of lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk2 179:00 29,1G 0 disk ├─mmcblk2p1 179:10 100M 0 part /boot/efi ├─mmcblk2p2 179:20 3,4G 0 part [SWAP] └─mmcblk2p3 179:30 22,9G 0 part / mmcblk2boot0 179:256 04M 1 disk mmcblk2boot1 179:512 04M 1 disk cont. of /etc/fstab: # / was on /dev/mmcblk1p3 during installation UUID=ba9bd08f-5a25-4e42-95a4-ce0fa41be38d / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/mmcblk1p1 during installation UUID=78BA-12AF /boot/efi vfatumask=0077 0 1 # swap was on /dev/mmcblk1p2 during installation UUID=e1016bf0-5a98-4269-9e94-01ec54f1d541 noneswap sw 0 0 ) Does anyone have a clue if either of these two things might be the problem here, or -if not- what else I could try to identify the problem's source? Thanks in advance, and have a nice day, Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, "The Trouble with Tribbles", stardate 4525.6
