Puppy Linux Discussion Forum

I have a number of Puppies all frugally installed on a portable hard drive. Not too important which Puppies they are as this issue affects all of them.

Irrespective of which Puppy I'm booting, when the boot process starts a line appears that begins "Linux-bzImage". I then get a significant delay until the next line, "Linux-initrd" appears. Once booted they all run and function as they should.

Now I only get this delay when I plug the drive into one of my laptops. No delay when I plug it into my other laptop. So naturally I'm assuming it's a laptop problem, and not a Puppy issue.

I was wondering if anyone could explain to me exactly what is happening at this point in the boot process? Then it may give me some idea as to whether or not this is something that can be fixed, or if it's just some quirk I've got to put up with.

Thanks

My guess would be that the USB ports on the affected laptop are older, slower USB specification as compared to the other laptop. Those
messages probably appear on the unaffected laptop BUT are processed so much faster as to make them virtually unnoticeable. That, and
the CPUs doing the processing may have enough differences to each other that you see a delay in one but not the other.
Wiz

Stevie, do you see 'linux-bzimage' on the second desktop but it disappears right away, or do you never see it at all?

@Wiz57 Thanks for the reply. The USB ports are the same spec on both laptops, although the processor is a little slower on the problem one. I don't think there's a massive difference though.

One other thing, that I should perhaps have mentioned in my original post. That is, this issue only arises with frugal installs. If I burn a Puppy iso to a USB stick with, for example Rufus, or if I use a Ventoy stick, there is no delay.

Don't know which of the mods changed the title, but people will think it's to do with USB sticks. So I've removed "USB" from it.

Flash wrote: Sun Jul 14, 2024 5:59 pm

Stevie, do you see 'linux-bzimage' on the second desktop but it disappears right away, or do you never see it at all?

Yes I see it, but then "Linux-initrd" appears within a couple of seconds. On the problem one it can sit there for 45 seconds or even longer until the next line appears.

@stevie pup This sounds like a delay caused by loading many kernel modules or looking for partitions and kernel modules.

This is indicated by the symptoms that on some machines it is snappy booting and on the other it is 45+ seconds or more.

Here's a little of what I found when I googled 'linux-bzimage'

vmlinux is the uncompressed kernel code, vmlinuz, and vmlinux. bin are compressed versions for booting. zimage is an older compressed format, and bzImage is an improved version...

The bzImage located in arch/x86/boot/bzImage must be copied to the EFI System Partition (ESP) and renamed with the extension “. efi”. Without the extension the EFI firmware loader will refuse to execute it....

bzImage , on the other hand, is really a description of the file's format. It stands for "big compressed image". The "big" part of this indicates the kernel is too large to fit into conventional memory, below 640 KiB, and would instead need to be decompressed into high memory above 1 MiB...

Also a very long description of the Linux booting process here: https://www.star.bnl.gov/~liuzx/lki/lki-1.html

'linux-bzimage' ... Yes I see it, but then "Linux-initrd" appears within a couple of seconds. On the problem one it can sit there for 45 seconds or even longer until the next line appears.

The boot loader copies vmlinuz and initrd to ram memory.
then passes execution to the kernel, vmlinuz.
The boot loader has finished running.

The kernel only runs for a few seconds,
then init in the initrd starts executing.
The kernel is not causing the pause.
init is causing the pause.
Probably waiting for usb module to initialize
(because no pause when booting from usb)

Most vmlinuz files are really bzimage format.

Flash wrote: Mon Jul 15, 2024 3:38 am

Here's a little of what I found when I googled 'linux-bzimage'

vmlinux is the uncompressed kernel code, vmlinuz, and vmlinux. bin are compressed versions for booting. zimage is an older compressed format, and bzImage is an improved version...

The bzImage located in arch/x86/boot/bzImage must be copied to the EFI System Partition (ESP) and renamed with the extension “. efi”. Without the extension the EFI firmware loader will refuse to execute it....

bzImage , on the other hand, is really a description of the file's format. It stands for "big compressed image". The "big" part of this indicates the kernel is too large to fit into conventional memory, below 640 KiB, and would instead need to be decompressed into high memory above 1 MiB...

This refers to EFI. Both of my laptops are quite old and both are BIOS only, no EFI.

williams2 wrote: Mon Jul 15, 2024 5:30 am

The boot loader copies vmlinuz and initrd to ram memory.
then passes execution to the kernel, vmlinuz.
The boot loader has finished running.

The kernel only runs for a few seconds,
then init in the initrd starts executing.
The kernel is not causing the pause.
init is causing the pause.
Probably waiting for usb module to initialize
(because no pause when booting from usb)

I think I've got my head around that, but it doesn't explain why one is an issue and the other one isn't.

I'm assuming it's a laptop problem, and not a Puppy issue.

It's possible that the hardware driver modules work better with one machine than the other.

Even if the two machines are identical, they may not be in the same condition. One might be slightly broken.

You might see something in bootsysinit.log or in bootkernel.log in /tmp/

@stevie pup

Further search shows:

Why does Linux-bzImage appear on one laptop but not another when using portable hard drive?

Sources
reddit.com favicon
linuxquestions.org favicon

Answer
Based on the search results, there are a few key points that may explain why Linux-bzImage appears on one laptop but not another when using a portable hard drive:

Hardware differences: The delay in loading Linux-bzImage on one laptop but not another is likely due to hardware differences between the two laptops.

Newer hardware may be more compatible with recent kernel versions.

Firmware/BIOS: Ensuring the firmware/BIOS is up-to-date on the problematic laptop may help resolve issues with loading the Linux kernel.

iPXE compatibility: If using network booting, issues with iPXE and the target computer's network hardware could prevent the Linux kernel (bzImage) from loading properly.

Kernel version: Older hardware may have issues with newer kernel versions. Using an older LTS kernel version could potentially improve compatibility.

Secure Boot: If Secure Boot is enabled on one laptop but not the other, it could prevent an unsigned kernel image from loading.

Signing the kernel image may be necessary for Secure Boot systems.

Boot loader configuration: Differences in GRUB or other boot loader configurations between the laptops could affect how the kernel image is loaded.

To troubleshoot, you could try:

Updating firmware/BIOS on the problematic laptop
Using an older LTS kernel version
Disabling Secure Boot temporarily to test
Checking boot loader configurations
Ensuring the kernel image is properly signed if using Secure Boot

If the issue persists, it may be worth investigating hardware-specific incompatibilities between the problematic laptop and the kernel/drivers on the portable drive.

Some of the above may not apply as in Network Booting and Secure Boot.

Hope this might help.

@Chelsea80 Thanks for the response, you've given me a few things to think about there. You're right, Network booting, Secure boot, EFI, and all that stuff doesn't apply.

A couple of the Puppies that are installed are comparatively old and using (I believe) 4.19 Kernel, so I don't think that's the problem either. The hard drive of this laptop has the latest version of MX linux installed, which has the 6.1 kernel, and that boots without any issues.

Can I assume that when booting a USB stick made with, for example, Rufus, that the boot process is different in some way? And that is why they're not affected?

As for the hardware, well there has been one or two unrelated incidents where the troublesome laptop has exhibited some very oddball behaviour.

Could the portable hard drive itself be playing some part in all this? I have Fossa 9.5 frugally installed to a different portable hard drive, and that is unaffected. Whichever laptop I plug it into there is only a 5 second difference in boot time. Mind you, that wouldn't explain why it's only a problem with one laptop. If there was a fault with the HD you would expect it to be there all the time. Or am I being too simplistic?

As I've said on a few previous occasions, computers were only invented to give people headaches.

Here is something you really need to worry about.
.

As for the hardware, well there has been one or two unrelated incidents where the troublesome laptop has exhibited some very oddball behavior.

I think you just provided the answer.

I've done some experiments over last couple of days, wiped all the frugal installs off the drive. Then dusted the cobwebs off my Windows 7 laptop and installed YUMI to the drive, along with a dozen Puppy iso's. A mix of modern Pups, some older Pups, and a couple of unofficial Pups. Mostly 64 bit but included a couple of 32 bit.

Firstly plugged the drive into the trouble free laptop. All except one (S15 64 bit) booted ok. S15 wouldn't boot at all so I removed it. I didn't really expect every Puppy to be compatible with YUMI. As for the other 11, I booted each one in turn, made the initial settings, and created a save file.

Then plugged the drive into the troublesome laptop and booted each Puppy in turn to do some comparisons. ABSOLUTELY NO PROBLEMS! No more than 5 seconds difference in boot time for any Puppy, and certainly no delays in boot process.

Over the last year or so I've also had 3 or 4 mainline Linux distros installed on this drive, and I don't remember having any boot problems with any of those either. All of which is further evidence that the issue only affects frugal installs and nothing else.

Might just leave it with YUMI. I'll have a further play with it all over the weekend, just to see if any issues do arise.

If the slowness is during the boot loader stage, this has nothing to do with kernel modules, and it won't get logged anywhere.

Maybe the problem is just a big xz-compressed kernel that takes more time to read from slow boot media, and more time to decompress on a computer with a really slow CPU?

@dimkr Thanks for the reply. The processor is a Pentium T4200, dual core, 1.2Ghz, I don't know if that's classed as very slow. By today's standards maybe.

As the issue only affects frugal installs I can't help thinking there's some difference in the boot process between a frugal and booting an iso from Rufus, Ventoy, whatever. But I don't know what, not that clever.

If I understand. You totally deleted everything on the drive and started over with a clean drive.
Nothing on it.

It is one thing that can fix a lot of strange things.

I always go one step better.

Make a new partition table on a drive.
This deletes everything at one time.
Replacing the partition table, makes sure there is no left over stuff, that could be in the old partition table.

Then make partitions and format them.

Any format, other than Linux ext 3 or 4, can and do get fragmented file system, over time.
Especially fat32 or ntfs format.

There are a few other formats, that are good about not fragmenting, but not all Puppy versions support them.
For sure, support is for fat32, ntfs, ext 3 or 4 format (file system).

Booting from a ISO is basically the same as a live install.
The boot loader that is in the ISO is being used.

With frugal installs you have to also install a boot loader to do the booting.

The boot loader being used can affect booting.
Having the 100% correct entry in it to boot the Puppy frugal install.

Boot loader install programs, specific to Puppy, are best to use to install a boot loader.

Right now in Puppy Linux, a good boot loader for booting frugal installs.

Grub2config
viewtopic.php?t=3360

Frugalpup Installer program, the boot loader it can install.
viewtopic.php?t=337

stevie pup wrote: Thu Jul 18, 2024 12:44 pm

@dimkr Thanks for the reply. The processor is a Pentium T4200, dual core, 1.2Ghz, I don't know if that's classed as very slow. By today's standards maybe.

Other computers that don't have this issue have a different CPU?

Does BookwormPup64 boot faster on this particular computer?

@bigpup When the frugals were on the drive there was just the one partition, formatted Ext3. I had installed Grub4DOS as the bootloader, never had any problems with it in the past.

Might experiment with some alternative bootloaders over the weekend, depends what else I've got to do and how idle I'm feeling. Then again I might just leave YUMI on the drive. After all, it works without issue.

dimkr wrote: Thu Jul 18, 2024 5:03 pm

Other computers that don't have this issue have a different CPU?

Does BookwormPup64 boot faster on this particular computer?

The trouble free laptop also has dual core processor, but it's an i3, 1.4Ghz. So a little faster but not a massive difference.

I don't remember specific details regarding Bookworm64, but it's boot time wasn't significantly different to other Pups. Basically it behaved the same as all the others. That is, booted fine on one laptop but about 45 seconds delay on other.

stevie pup wrote: Thu Jul 18, 2024 10:02 pm

@bigpup When the frugals were on the drive there was just the one partition, formatted Ext3. I had installed Grub4DOS as the bootloader, never had any problems with it in the past.

Might experiment with some alternative bootloaders over the weekend

Changing boot loader will make no difference at all. If it boots it is booting. All a bootloader does is find vmlinuz and initrd; so if it boots the boot loader has already finished it job successfully so nothing to do with it. The init in initrd takes over next and once finished setting up layered filesystem and so on, passes what happens next onto the init system in main root filesystem. During these initrd/init and main root filesystem init system kernel modules and firmware are involved and boot delays can result if kernel combination with modules/firmware doesn't work well with particular computers.

What file systems do you use with distros that don't boot slowly from the same portable hard drive? The Puppy forum is the only place where people still recommend ext3 over ext4, because they think it's more stable. ext3 is old, unpopular, slower than ext4, and maybe it's a bug in the boot loader's implementation of it.

stevie pup wrote: Thu Jul 18, 2024 12:44 pm

@dimkr Thanks for the reply. The processor is a Pentium T4200, dual core, 1.2Ghz, I don't know if that's classed as very slow. By today's standards maybe.

As the issue only affects frugal installs I can't help thinking there's some difference in the boot process between a frugal and booting an iso from Rufus, Ventoy, whatever. But I don't know what, not that clever.

This seems to indicate entries in the boot loader have an affect on this.

Booting using a ISO is using the boot loader in the ISO and it's entries.
Same for a live install.

On the drive with frugal installs are Grub4dos boot loader files.
How about posting the contents of the Grub4dos menu.lst file, which is the file that contains the boot loader menu entries, used to boot with.

Note:
Not knowing exactly what you have in each of the frugal install directories. (it could have all the files that were in the ISO)
The menu.lst we need to see should be just on the partition and not inside any directory(folder).

That will tell us what version of Grub4dos it is.

Maybe something in the entries is not correctly placed or used.

Puppy Linux has a lot of optional commands that could be used in a boot menu entry.

Thank you everyone for your replies and suggestions. Must admit I'm still scratching my head though, as I still can't see a specific reason why the issue only affects frugal installs and only happens on one laptop. Unless there's been some disagreement between that particular laptop and the bootloader? Which all seems rather odd to me.

Not to worry. I'm not going to have the time to do much experimenting this weekend after all. so I'm going to continue using the YUMI set up for next couple of weeks and see what happens. It's all working fine at the moment but I need to do a few more tests and checks before I'm fully confident.

If it turns out to be all ok I'll keep that set up and won't bother with frugal installs. If something works I can't really be bothered to spend that much time on something that doesn't work. As I mentioned previously when I originally did the YUMI set up I put a dozen Puppy iso's on it. As 11 of them booted up fine guess how much time I spent on the one that didn't? The 2 seconds it took to delete it!

Most, but not all, frugal installs rely at boot time on an initrd that doesnt contain any modules or firmware for initial stage of booting. Instead, these frugal installs use a kernel that has drivers concerned with booting compiled in. But if a system has hardware that needs a driver that wasnt compiled in to the kernel you wont be able to boot. A full install distro tend to come with tons more modules and firmware built in so is more likely to boot successfuly.