(OLD) (ARCHIVED) Puppy Linux Discussion Forum Forum Index (OLD) (ARCHIVED) Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info

This forum can also be accessed as http://oldforum.puppylinux.com
It is now read-only and serves only as archives.

Please register over the NEW forum
https://forum.puppylinux.com
and continue your work there. Thank you.

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups    
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 19 Sep 2020, 06:50
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
How to install Bionicpup64 8.0 on UEFI?
Moderators: Flash, Ian, JohnMurga
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
Page 9 of 12 [180 Posts]   Goto page: Previous 1, 2, 3, ..., 7, 8, 9, 10, 11, 12 Next
Author Message
foxpup

Joined: 29 Jul 2016
Posts: 1141

PostPosted: Sun 26 Jan 2020, 05:38    Post subject:  

Okay. Thanks for making the effort to explain.

Point is, the links in /sys/ should be there.

In Easy (and probably in old Puppys as well) the device nodes where all static, that means the builder had to preview them.
But in Puppy now they have to be created on boot (dynamically), just like the links in /sys/blk/.
So something is not working as it should. Something fails.
I don't think filling up the links in /sys/blk manually does solve it.
(Adding static device nodes may solve it, because it is a proper way of adding device nodes, but it does not solve the failure.)

Have you tried a Easy kernel yet?
Back to top
View user's profile Send private message 
enrique

Joined: 09 Nov 2019
Posts: 601
Location: Planet Earth

PostPosted: Sun 26 Jan 2020, 10:03    Post subject:  

Two month ago I wrote in this forum: where are the people? So many projects should have so many experts. I called them master builders. But close to none post outside their own thread. Now I know. I come from forums where users behave very different. I guess I have to adapt here. What I learn; I have to read all posted info from the OP on his thread before writing a word. Post only a single post insinuating possible solution. Never post detail help procedures, where such help is not wanted. Why I write this? Because I am sad, I will be seen this thread day after day, when I know I could had help to resolve it in hours. But instead here I am, apologizing for wasting op time by sending him to a blind alley. OP has prove he does not stop, I know that at some point he will get it.

Last advice. /proc & /sys will not fill missing /dev, I am no expert on /proc and /sys. But I know the answer is not there. The useful information of /proc & /sys get populated at the same time as /dev. Since I do not seems to convince you, then instead, find out who populate /dev and you may be in the right direction. Good luck my friend.
Back to top
View user's profile Send private message 
foxpup

Joined: 29 Jul 2016
Posts: 1141

PostPosted: Mon 27 Jan 2020, 05:02    Post subject: try kernel change  

foxpup wrote:
Have you tried a Easy kernel yet?

Look in your PM.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1799
Location: Brisbane, Australia

PostPosted: Mon 27 Jan 2020, 07:04    Post subject:  

3guesses wrote:
gyro wrote:
@3guesses,

For what it's worth,
my suggestion would be to place the Puppy files, i.e. the Puppy ".sfs" files etc..., in a sub-directory on a Linux partition on the internal drive.
BUT, boot it from a usb stick, e.g. install grub2 on a fat32 usb stick.

gyro


In the case of the T100TA this wouldn't help because the Puppy 8.0 kernel can't see the .sfs files if stored on the internal eMMC.
So, it actually started to boot, with some messages on the screen, and then it spat out a few red lines on the screen, that implied it could not find the puppy...sfs file?
If that is what happened, then it failed in the "init" script in the 'initrd.gz'.

One possible way for this to happen is that during the "init" environment, the usb stick becomes "ready" before the mmc partitions become ready. If that happens "init" will not know about any mmc partitions, and then not find any ".sfs" files on sda1 (the usb stick).

If I you are interested, I could make a "test" 'initrd.gz' with a patched "init" which may fix this issue.
I developed the patch when trying to boot a frugal Puppy stored on a card in the SD slot, from a usb stick. The patch worked for me. (The machine cannot boot directly from the SD card slot.)

gyro
Back to top
View user's profile Send private message 
3guesses

Joined: 30 Sep 2014
Posts: 172

PostPosted: Mon 27 Jan 2020, 20:00    Post subject:  

enrique wrote:
Two month ago I wrote in this forum: where are the people? So many projects should have so many experts. I called them master builders. But close to none post outside their own thread. Now I know. I come from forums where users behave very different. I guess I have to adapt here. What I learn; I have to read all posted info from the OP on his thread before writing a word. Post only a single post insinuating possible solution. Never post detail help procedures, where such help is not wanted. Why I write this? Because I am sad, I will be seen this thread day after day, when I know I could had help to resolve it in hours. But instead here I am, apologizing for wasting op time by sending him to a blind alley. OP has prove he does not stop, I know that at some point he will get it.

Last advice. /proc & /sys will not fill missing /dev, I am no expert on /proc and /sys. But I know the answer is not there. The useful information of /proc & /sys get populated at the same time as /dev. Since I do not seems to convince you, then instead, find out who populate /dev and you may be in the right direction. Good luck my friend.


@enrique,

It was not my intention to cause offence, and I apologise if I have done so. It was very late and I was very tired (I have not much experience of Linux and none of its low-level operation, so all of this has been a fairly steep learning curve for me), and providing all the information you asked for was less than convenient for me to do - and it came after I had had to spend a day repairing the boot system of the T100TA which had been trashed by Frugal Pup (again, another steep learning curve as I have little experience/knowledge of Grub2 and none of UEFI/GPT). I was simply trying to make it very clear to you what the issue was that I was trying to address as you seemed to have got the wrong end of the stick.

As I said previously, all contributions are welcome and you clearly have more knowledge about the low-level operation of Puppy than I do so your input would no doubt prove valuable in trying to resolve this issue.
Back to top
View user's profile Send private message 
3guesses

Joined: 30 Sep 2014
Posts: 172

PostPosted: Mon 27 Jan 2020, 20:17    Post subject:  

gyro wrote:
3guesses wrote:
gyro wrote:
@3guesses,

For what it's worth,
my suggestion would be to place the Puppy files, i.e. the Puppy ".sfs" files etc..., in a sub-directory on a Linux partition on the internal drive.
BUT, boot it from a usb stick, e.g. install grub2 on a fat32 usb stick.

gyro


In the case of the T100TA this wouldn't help because the Puppy 8.0 kernel can't see the .sfs files if stored on the internal eMMC.
So, it actually started to boot, with some messages on the screen, and then it spat out a few red lines on the screen, that implied it could not find the puppy...sfs file?
If that is what happened, then it failed in the "init" script in the 'initrd.gz'.

One possible way for this to happen is that during the "init" environment, the usb stick becomes "ready" before the mmc partitions become ready. If that happens "init" will not know about any mmc partitions, and then not find any ".sfs" files on sda1 (the usb stick).

If I you are interested, I could make a "test" 'initrd.gz' with a patched "init" which may fix this issue.
I developed the patch when trying to boot a frugal Puppy stored on a card in the SD slot, from a usb stick. The patch worked for me. (The machine cannot boot directly from the SD card slot.)

gyro


Hi gyro,

Sure, I'd be happy to give that a go - or I could construct the initrd myself if you give me instructions - although I'm not entirely sure what USB stick is becoming ready as this issue is occurring when trying to boot entirely from the eMMC (which contains a standalone frugal install of Puppy). Do you know what process populates the /devices/, /sys/ and /dev/ directory trees? It seems to me that that is the root cause of the problem and I'm guessing it's the kernel that does so - and the Puppy kernel does not have the drivers for the T100TA eMMC so does not populate those directory trees with appropriate entries to provide the necessary low-level support for the eMMC.

Actually, re-reading your post I don't think it's a timing issue "readying" the eMMC - if it were, I'm pretty sure I would be able to see mmc* entries in /proc/ and/or /sys/ and/or /dev/ when the boot process drops out to the initrd shell.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1799
Location: Brisbane, Australia

PostPosted: Wed 29 Jan 2020, 08:58    Post subject:  

3guesses wrote:
Actually, re-reading your post I don't think it's a timing issue "readying" the eMMC - if it were, I'm pretty sure I would be able to see mmc* entries in /proc/ and/or /sys/ and/or /dev/ when the boot process drops out to the initrd shell.
You are probably correct.

Short answer:
Looks like Puppy kernel needs to load a module to access the emmc drive, the required module is contained in a file 'zdrv...sfs' in a partition on the emmc drive.
Catch 22.

Long answer:
I just did some research on a machine with an internal emmc drive, that contains windows, an sd card slot and of course usb.
If I boot Puppy wholly from a usb stick, the "init" script never knows about the sd card, but if I get the "init" script to dropout to the console, I can see that the kernel does in fact know about the sd card, but the emmc drive remains unknown.
Yet if I allow the boot to continue to the desk top, the emmc drive and it's partitions are available.
The explanation for my machine is that the Puppy kernels I am using are compiled with emmc support as a module.
So, in order to "see" the emmc drive Puppy needs to load a module, which is contained in a file with a name like 'zdrv...sfs'. But if you have installed Puppy to the emmc drive, then that 'zdrv...sfs' file is there. You need to read the 'zdrv...sfs' from the emmc drive before the kernel can access the emmc drive.

Possible solutions:
Either recompile the kernel and get the emmc support included instead of being a module,
of create a custom initrd.gz that contains that module and does an "insmod" of it early in the "init" script.

Not simple.

gyro
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1874
Location: Connecticut, United States

PostPosted: Wed 29 Jan 2020, 12:04    Post subject:  

would a kernel 4.19.23 with emmc support built in at compile time suffice?
It is EOL in 2020 but I could maybe get a 4.14+ kernel with LTS until 2024 to compile with the emmc support enabled.

Could also try a 5+ kernel. I would need to look into setting up the configuration for kernel compile correctly in the kernel-kit
Back to top
View user's profile Send private message Visit poster's website 
3guesses

Joined: 30 Sep 2014
Posts: 172

PostPosted: Thu 30 Jan 2020, 15:27    Post subject:  

rockedge wrote:
would a kernel 4.19.23 with emmc support built in at compile time suffice?
It is EOL in 2020 but I could maybe get a 4.14+ kernel with LTS until 2024 to compile with the emmc support enabled.

Could also try a 5+ kernel. I would need to look into setting up the configuration for kernel compile correctly in the kernel-kit


If you can build one for me to test on my T100TA then I'd be happy to use that. I don't personally need LTS for it, but eMMC is becoming more and more prevalent in low-powered modern laptops/chromebooks/etc so I would have thought eMMC support should be included in the kernel as standard going forward?

BTW I would be quite interested in being able to build a kernel myself - is there a tutorial anywhere for doing so?

Thanks.
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1874
Location: Connecticut, United States

PostPosted: Thu 30 Jan 2020, 17:16    Post subject:  

Hello 3guesses,

you would be able to build all types of kernels using the kernel-kit in woof-CE.

I would recommend getting woof-CE and run merge2out to create an output directory as you were setting up to create an OS.
Enter the /kernel-kit and set up the build.conf file to begin.

look up the aufs3, aufs4, or aufs5 that you will need to insert the correct version into the build.conf and run build.sh

after some practice you will be able to build some good kernels the way you need them in your Puppy Linux.
Back to top
View user's profile Send private message Visit poster's website 
3guesses

Joined: 30 Sep 2014
Posts: 172

PostPosted: Fri 31 Jan 2020, 18:16    Post subject:  

rockedge wrote:
Hello 3guesses,

you would be able to build all types of kernels using the kernel-kit in woof-CE.

I would recommend getting woof-CE and run merge2out to create an output directory as you were setting up to create an OS.
Enter the /kernel-kit and set up the build.conf file to begin.

look up the aufs3, aufs4, or aufs5 that you will need to insert the correct version into the build.conf and run build.sh

after some practice you will be able to build some good kernels the way you need them in your Puppy Linux.


OK, thanks, although I'll have to find out what woof-CE is first - any hints?

BTW I've just booted the T100TA from the Bionic Puppy 8.0 x64 live CD (on USB flash drive - where, once booted, it does support the eMMC no problem) and run HardInfo: under Computer->Kernel Modules it doesn't list any named aufs* and I can't actually see any module that looks like a likely candidate for providing support for the eMMC. The only modules that look like potential candidates to me are tpm*, dw_dmac, intel_soc_dts_iosf and intel_int0002_vgpio. Should this be where I can see the kernel module that is providing support for the eMMC, or is the support provided in another way?
Back to top
View user's profile Send private message 
3guesses

Joined: 30 Sep 2014
Posts: 172

PostPosted: Fri 31 Jan 2020, 19:06    Post subject: Re: try another kernel  

3guesses wrote:
foxpup wrote:
I got another answer from Barry.
BarryK wrote:
You could try one of my kernels. for example, Buster 64-bit linux
kernel PETs are here:

http://distro.ibiblio.org/easyos/amd64/packages/pet/pet_packages-buster/


Thanks, I'll give that a go when I get a chance.

*** STOP THE PRESS *** STOP THE PRESS *** STOP THE PRESS ***

Both the Buster 64 5.4.6 and 5.4.12 kernels work!!!

And the reboot action in Puppy also works (rather than the system hanging). So I think that demonstrates pretty conclusively that it is a kernel issue. Now it's just a question of what needs to be done to fix the Puppy kernel...
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1874
Location: Connecticut, United States

PostPosted: Fri 31 Jan 2020, 21:15    Post subject:  

Quote:
although I'll have to find out what woof-CE is first - any hints?


https://github.com/puppylinux-woof-CE/woof-CE
Back to top
View user's profile Send private message Visit poster's website 
gyro

Joined: 28 Oct 2008
Posts: 1799
Location: Brisbane, Australia

PostPosted: Mon 03 Feb 2020, 01:50    Post subject:  

In typical Puppy kernels, most drivers for mmc are configured as "m", which means they are compiled as modules, external to the kernel itself, and stored in "zdrv".
This poses no problem it they are not required until after the "init" script is completed. Hence the mmc partitions are available in the running system.

The appropriate mmc kernel config variables need to be set to "y" so the corresponding driver is compiled into the kernel itself.

On the small laptops that I have access too, the appropriate kernel module is '/lib/modules/4.4.187/kernel/drivers/mmc/host/sdhci-acpi.ko', I'm not sure what the corresponding kernel config variable is.

gyro
Back to top
View user's profile Send private message 
foxpup

Joined: 29 Jul 2016
Posts: 1141

PostPosted: Tue 04 Feb 2020, 12:42    Post subject: Re: try another kernel  

3guesses wrote:
*** STOP THE PRESS *** STOP THE PRESS *** STOP THE PRESS ***

Both the Buster 64 5.4.6 and 5.4.12 kernels work!!!.
Thank you Barry!

From a PM:
BarryK wrote:
Sometime ago, I examined the configure options when compiling the
kernel, and tried to choose the card reader drivers to be built-in to
the kernel, not as modules.

My guess would be that is the situation, you are using a kernel that
does not have them built-in.
...
The easiest fix is to use a kernel with all required drivers built-in.

3guesses wrote:
Now it's just a question of what needs to be done to fix the Puppy kernel...
You cannot 'fix' the kernel. You have to compile another one.
You could recommend on woofCE to configure the standard compilation of the kernel such that required drivers for mmc are built-in.
But I guess that a lot of builders build their own kernel with their own preferences.

When you have found a kernel that is good for your machine, stick to it as long as you can for that machine.
It is easy to swap kernels in Puppys nowadays.
I have a machine that really likes a kernel from norgo's Slacko6.9.9.9.
Fast startup, snappy and reliable.
So on that machine, I run DpupBuster from josejp2424, and pretty much anything else, with that kernel! Smile
That kernel is in the toolbox for that machine.
.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 9 of 12 [180 Posts]   Goto page: Previous 1, 2, 3, ..., 7, 8, 9, 10, 11, 12 Next
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1757s ][ Queries: 12 (0.0510s) ][ GZIP on ]