Vanilla Dpup will not boot (several versions tried) (solved)

[dimkr]

@bigpup Can you share the output of lsmod, lspci and dmesg, with both kernels? I want to understand the difference between them.

EDIT: what file system do you have there? Can you share the output of probepart with the old 5.4.x kernel?

[wiak]

I was just about to post that it may be same issue I had in different context, which I briefly mentioned on Aug 24, but didn't follow up since too busy to submit any more detailed reports when not myself concerned about it and not booting via normal Pup mechanisms anyway, which meant not a valid Puppy boot report, sorry:

https://forum.puppylinux.com/viewtopic. ... 200#p65200

Note: latest weedogit vdpup ver 9.2.11 doesn't boot on my machine. A kernel-related issue (I notice it is a much smaller kernel btw) - I swapped kernel/modules/firmware with previous 9.2.10 version and then booted fine.

[dimkr]

I think the culprit is CONFIG_USB_UAS=m, rather than CONFIG_USB_UAS=y.

@wiak Firmware is unrelated here, sorry. initrd doesn't use any firmware when it searches for Puppy files.

[bigpup]

@bigpup Can you share the output of lsmod, lspci and dmesg, with both kernels? I want to understand the difference between them.

EDIT: what file system do you have there? Can you share the output of probepart with the old 5.4.x kernel?

The original kernel dmesg is attached to the first post in this topic.

The output of lsmod, lspci
I cannot boot to a place to do this with the original kernel.

The kernel 5.4.53 results:

demsg.txt

(55.04 KiB) Downloaded 21 times

lsmod.txt

(3.9 KiB) Downloaded 25 times

lspci.txt

(1.74 KiB) Downloaded 24 times

.
The partition Vanilla Dpup is on is sdb3 format ext3.
As you can see sdb has a few partitions.

Code: Select all

~$ probepart
/dev/nvme0n1p1|vfat|204800
/dev/nvme0n1p2|none|32768
/dev/nvme0n1p3|ntfs|336808788
/dev/nvme0n1p4|ntfs|1146880
/dev/nvme0n1p5|ntfs|1024000
/dev/nvme0n1p6|ntfs|637508484
/dev/sda1|none|32734
/dev/sda2|ntfs|1000179712
/dev/sdb1|ntfs|207073280
/dev/sdb2|vfat|412162048
/dev/sdb3|ext3|413628416
/dev/sdb5|ext4|206227456
/dev/sdb6|ext3|205754368
/dev/sdb7|ext4|508669952
/dev/sdc1|vfat|11720704
/dev/sdc2|ext3|411111424
/dev/sdc3|ext4|553938944
~$

As you see, I have 4 drives connected to this computer.
Two internal SSD drives and two external USB drives.

Also I am using the original Grub4dos boot menu entry.

title Puppy vanilladpup 9.2.14 (sdb3/vanillapup9.2.14)
find --set-root uuid () 24a14d90-6d75-4276-a6a0-ef026f8d07cf
kernel /vanillapup9.2.14/vmlinuz pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf psubdir=/vanillapup9.2.14 pmedia=atahd pfix=fsck
initrd /vanillapup9.2.14/initrd.gz

[dimkr]

[ 1.639942] scsi host6: uas
[ 1.650536] scsi 6:0:0:0: Direct-Access Seagate Expansion+ 0706 PQ: 0 ANSI: 6
[ 1.652219] sd 6:0:0:0: [sdb] 1953525167 512-byte logical blocks: (1.00 TB/932 GiB)

Bingo, 9.2.15 should work in your setup.

[bigpup]

I think the culprit is CONFIG_USB_UAS=m, rather than CONFIG_USB_UAS=y.

I could tell you what it is set to, in this 5.4.53 kernel, if you could tell me where I could find the info?

[bigpup]

[ 1.639942] scsi host6: uas
[ 1.650536] scsi 6:0:0:0: Direct-Access Seagate Expansion+ 0706 PQ: 0 ANSI: 6
[ 1.652219] sd 6:0:0:0: [sdb] 1953525167 512-byte logical blocks: (1.00 TB/932 GiB)

Bingo, 9.2.15 should work in your setup.

Ok, but where is the download for v9.2.15?

[wiak]

I think the culprit is CONFIG_USB_UAS=m, rather than CONFIG_USB_UAS=y.

@wiak Firmware is unrelated here, sorry. initrd doesn't use any firmware when it searches for Puppy files.

I didn't suggest firmware caused it - I said it was kernel-related (meaning likely missing driver within the huge kernel...) - I changed all of kernel, modules, and firmware at the same time, just because they came together as a set in previous vdpup. WeeDogLinux initrd doesn't care about external addon firmware on booting either.

[dimkr]

Ok, but where is the download for v9.2.15?

In the future

[dimkr]

I didn't suggest firmware caused it

AFAIK the only difference between the kernels is the firmware that comes with them. As you can see in https://github.com/puppylinux-woof-CE/w ... .60-x86_64, the kernel configuration hasn't changed.

[wiak]

I think the culprit is CONFIG_USB_UAS=m, rather than CONFIG_USB_UAS=y.

I didn't suggest firmware caused it

AFAIK the only difference between the kernels is the firmware that comes with them. As you can see in https://github.com/puppylinux-woof-CE/w ... .60-x86_64, the kernel configuration hasn't changed.

No, not the firmware, but the kernel...

As you said earlier quoted above, the mistake you now identify was to have "CONFIG_USB_UAS=m, rather than CONFIG_USB_UAS=y"

The first of these relies on an external to the kernel MODULE, whereas PUPPY of course requires the driver INSIDE the kernel (which is why we refer to it as a huge kernel). The kernel linux, without that driver inside it could not see the boot device - grub could because it has its own drivers so kernel and Puppy initrd would get loaded, but thereafter the initrd could not see the sfs files it needed to...

I'm sure you know this.

[dimkr]

No, not the firmware, but the kernel...

https://github.com/puppylinux-woof-CE/w ... .60-x86_64

I see no changes in between 9.2.10 and 9.2.11, what can I say.

[wiak]

No, not the firmware, but the kernel...

https://github.com/puppylinux-woof-CE/w ... .60-x86_64

I see no changes in between 9.2.10 and 9.2.11, what can I say.

Then you are missing something, because one worked and one didn't on my computer, so at least on my system the 9.2.10 kernel had appropriate driver built in for booting on my system. Might be another driver built into the kernel, or maybe another issue involved - I can't now recall if I was booting it from usb stick or internal nvme harddisk, so maybe best you double-check that too; I have long since scrubbed the installation on my machine, but if all now boots for everyone then the problem is solved and can be forgotten about anyway. Mistakes happen, devices needs can change, no crime. Time will tell.

[bigpup]

I marked this solved.

But I will try v9.2.15 when it comes out.

Will report on results good or bad.

[dimkr]

when it comes out.

Done

[one]

The problem is therefore in the USB Attached SCSI protocol (UASP), which is used to access (external) HDDs/SSDs. It was introduced as an optional part of the USB 3.0 specs but can also be used with USB 2.0 host controllers when hardware/drivers are compatible.
For reliable operation it's recommended to use UASP only with mainline kernel. You've to set CONFIG_USB_UAS=m or CONFIG_USB_UAS=y in your kernel config and you need an USB-to-SATA bridge in your disk enclosure that implements UAS correctly (and therefore isn't blacklisted -- in the latter case an automatic fallback to BOT (Bulk-Only Transport) should happen).

I had the same difficulty as @bigpup with my setup and vanilladpup, but also with @peebee 's voidpup32 (k5.10.101/117). voidpup64 (k5.15.24/41) and jammypup32 (k5.10.113). All 4 failed to boot from my external SanDisk SSD 240 GB, connected via a USB-to-SATA adapter (USB 2.0 in my case). All other pups/dogs on the SSD booted flawlessly with this setup.

I swapped the kernels: (5.4.190) on jammypup32/voidpup32, (5.16.2) on voidpup64, these three puppys boot ok with it.

I reported about it in this thread:

https://forum.puppylinux.com/viewtopic. ... 914#p50914

peace

[one]

Hi @dimkr,

I had some spare time so I tested your 9.2.15 build - it now boots fine in the setup I described earlier. Thank you ...

peace

[bigpup]

My test results.
Using Vanilla Dpup 9.2.15

This version boots OK on my computer.
No problems.

Thanks!

[dimkr]

Cheers

[williwaw]

My test results.
Using Vanilla Dpup 9.2.15

This version boots OK on my computer.
No problems.

Thanks!

are you using the

Code: Select all

pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf 

kernel line parameter with the successful boot?

[bigpup]

Yes.

This is the Grub4dos boot loader menu entry that is booting Vanilla Dpup 9.2.15 with no problem.

title Puppy vanilladpup 9.2.15 (sdb3/vanilladpup9215)
find --set-root uuid () 24a14d90-6d75-4276-a6a0-ef026f8d07cf
kernel /vanilladpup9215/vmlinuz pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf psubdir=/vanilladpup9215 pmedia=atahd pfix=fsck
initrd /vanilladpup9215/initrd.gz

The menu entry was never the problem.

The kernel was never loading access to the USB drives.

I assume, the needed kernel config option, was changed, in the kernel now in Vanilla Dpup 9.2.15

[williwaw]

The menu entry was never the problem.

The kernel was never loading access to the USB drives.

I assume, the needed kernel config option, was changed, in the kernel now in Vanilla Dpup 9.2.15

I understand kernel config was problematic.

would you be kind enough to test boot without the pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf ?
I am wondering if having the
find --set-root uuid () 24a14d90-6d75-4276-a6a0-ef026f8d07cf
is all thats neccessary
thanks

[bigpup]

True, the latest version of Puppies Grub4dos, can work with several different menu entries, but why make it do that.
Let it use the best one Grub4dos Config produces, that has all the shortcut and feature options.

Well, now you are asking to modify a Grub4dos menu entry, to make it into one that Grub4dos is not setup to use so well.

The entries are that way, because Grub4dos is coded to use this info provided in the entry.

Also the info is for the Puppy boot process, that Grub4dos turns over control to.

pdrv= and psubdir= are mainly shortcut info, so the Puppy boot process does not have to search so much, for the files needed during the boot process.

It only needs to look on this partition, and in this specific directory.

[williwaw]

Bigpup

the pdrv error you reported at the beginning of this thread is often seen when troubleshooting failed boots.
for example https://forum.puppylinux.com/viewtopic. ... 284#p66284

perhaps the error has nothing to do with the actual causes for failures to boot. a false positive that makes diagnosis of boot failures more difficult?

Looking at few old USBs with different versions of grub4dos installed, I find various stanzas. some with the pdrv=uuid, some without. Of course, its hard to tell if these stanzas were generated by grub4dos or edited after the fact. Often, when experiencing failures to boot, we try different parameters until something just works. A parameter suggested by someone on the forum or from a different installation etc.

Can you confirm whether your inclusion of pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf is an edit or actually generated by grub4dos?
I presume the find --set-root uuid () 24a14d90-6d75-4276-a6a0-ef026f8d07cf parameter is a valid grub4dos config, but am still curious where the pdrv=uuid kernel line parameter originated.

In the opening post, you attached your bootinit.log when the boot failed. Would you attach the file as it stands now for comparison, now that you are able to boot with the new kernel?
tx again

[bigpup]

Yes, the boot menu entry was made by using Grub4dos Config v1.9.3.
It made the entry.
Nothing is edited by me.

History of Grub4dos and really a lot of the earlier versions of boot loaders.
Specific drive identification was done using example: (hd1,1) to indicate drive 1 and 2nd partition on it. first partition would be (hd1,0)
But not always 100% that (hd1,1) would always identify the same dive/partition, at all times, during the boot process.

Then they developed the idea of a specific identifier that a partition will have, the UUID.
This UUID never changes or can be used by another partition on the drive.

Older versions of a boot loader do not use UUID.
UUID was not around to use, when they were developed, or they still decided to keep using the old way to identify.

Reported errors are a language of it's own.
In general they are reporting that something asked to be done, is not able to be done.
Using pdrv=, to give shortcut information to the boot search process, to say only find the drive with this specific partition on the drive, could not be done.
Keep in mind this USB has 6 partitions on it.
Same for a lot of the other error messages.
Just telling you you asked to do this and it could not be done.

Main error indicated, by all the errors, was the USB drive was not being accessed.

Not on Vanilla Dpup right now.
I will post later the working bootinit.log.

[bigpup]

Not on Vanilla Dpup right now.
I will post later the working bootinit.log.

@williwaw

Well, if it boots OK, there is no bootinit.log made.

From the normal messages file, that tells all about the boot process.
This is the part about the USB sdb drive.
I think this is info you are asking about:

Run /init as init process
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980534] with arguments:
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980535] /init
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980535] with environment:
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980535] HOME=/
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980536] TERM=linux
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980536] pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980536] psubdir=/vanilladpup9215
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980537] pmedia=atahd
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.980537] pfix=fsck
Sep 15 22:10:04 puppypc11118 user.info kernel: [ 1.981589] scsi host6: uas
Sep 15 22:10:04 puppypc11118 user.notice kernel: [ 1.992119] scsi 6:0:0:0: Direct-Access Seagate Expansion+ 0706 PQ: 0 ANSI: 6
Sep 15 22:10:04 puppypc11118 user.notice kernel: [ 1.993387] sd 6:0:0:0: [sdb] 1953525167 512-byte logical blocks: (1.00 TB/932 GiB)
Sep 15 22:10:04 puppypc11118 user.notice kernel: [ 1.993388] sd 6:0:0:0: [sdb] 4096-byte physical blocks
Sep 15 22:10:04 puppypc11118 user.notice kernel: [ 1.993530] sd 6:0:0:0: [sdb] Write Protect is off
Sep 15 22:10:04 puppypc11118 user.debug kernel: [ 1.993531] sd 6:0:0:0: [sdb] Mode Sense: 53 00 00 08
Sep 15 22:10:04 puppypc11118 user.notice kernel: [ 1.993798] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 15 22:10:04 puppypc11118 user.warn kernel: [ 1.994026] sd 6:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Sep 15 22:10:04 puppypc11118 user.info kernel: [ 2.084348] sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 >

[williwaw]

Bigpup,
thanks for your patience, I have pick up a few good pointers about troubleshooting boot failures in this thread.

[geo_c]

Bigpup,
thanks for your patience, I have pick up a few good pointers about troubleshooting boot failures in this thread.

This topic was quite a read, as I just set up a brand new PNY 512GB USB thumb drive with several different pups and kennel distros, upon attempting to boot VanillaDpup I got the same error found in the early posts of this thread, that being that after grub4dos loaded the initrd the rest of the files could not be found.

So perusing through all this info it looks like I might need to change the kernel. Should I use the fossapup huge kernel linked earlier in this discussion?

And an addtional question, since I copied files from the iso onto my usb stick, I decided to leave the one called ucode.cpio. Should that one be there?

[williwaw]

I got the same error found in the early posts of this thread, that being that after grub4dos loaded the initrd the rest of the files could not be found......
...... I might need to change the kernel......

And an addtional question, since I copied files from the iso onto my usb stick, I decided to leave the one called ucode.cpio. Should that one be there?

Partition 24a14d9........ not found. was the error from bigpups bootinit.log tho

is init looking for a partition or files in your case? if you have a bootinit.log generated it might shed more light.

also grub4dos stanza in question?

[geo_c]

I got the same error found in the early posts of this thread, that being that after grub4dos loaded the initrd the rest of the files could not be found......
...... I might need to change the kernel......

And an addtional question, since I copied files from the iso onto my usb stick, I decided to leave the one called ucode.cpio. Should that one be there?

Partition 24a14d9........ not found. was the error from bigpups bootinit.log tho

is init looking for a partition or files in your case? if you have a bootinit.log generated it might shed more light.

also grub4dos stanza in question?

I did two things, I swapped out the kernel with the fossapup huge kernel, and it booted just fine, but the display resolution was stretched, not correct, none of the settings changed it. However the system booted and ran correctly for the short time I used it.

The second thing I did was download vanilladpup.10.0.25_plinej, and that booted fine out-of-the-box using the 5.15 kernel.

I don't see a bootinit.log on the drive from the first attempt. So to recap, changing the kernel in vanilladpup-9.2.8 to the fossapup 5.4.53 kernel gave me a successful boot.

The reason I say the first attempt didn't find the files is because that's the message it gave, and it also indicated it was looking on sda1 as opposed to sdb2. I have grub4dos located on sdb1 and vanillapup begins it's sequence but can't find the files on sdb2 because it appears to be trying sda1. So it seems like the problem bigpup was talking about. That's why I used his solution and it worked, but as I said, monitor resolution was a little screwy. This laptop has a 1920x1080 monitor and setting it with xorg resolution didn't change it for some reason. Maybe the driver isn't there. Separate issue, not worried about that now, just playing around with my USB stick and all my boots are successful now except VoidPup and KLV, so I'll take a look at those next.