Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 12 Dec 2019, 11:58
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Fatdog64-710 Final [4 Dec 2016]
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 22 of 44 [646 Posts]   Goto page: Previous 1, 2, 3, ..., 20, 21, 22, 23, 24, ..., 42, 43, 44 Next
Author Message
disciple

Joined: 20 May 2006
Posts: 6995
Location: Auckland, New Zealand

PostPosted: Sun 26 Mar 2017, 21:01    Post subject:
Subject description: re USB installation
 

Hi guys,
I've been using Fatdog a little lately, pretty much for the first time - good job with it.

I'd be surprised if someone hasn't mentioned this before, but here goes:

I followed the instructions to install to a usb stick and use fix-usb.sh*
I used the remaining space on the drive to create a VFAT partition.
But it turns out "Windows... won't recognize more than one partition on a USB drive unless it has a certain bit set declaring it a USB-HDD".
So I should have just created an linux filesystem.
I'm a bit lost on why this install method works the way it does though. Why not just have one filesystem on the USB stick? Is it a necessary consequence of trying to just use an iso image?

*Incidentally, the first time around the stick wasn't bootable, so, wondering if there was a step missing from the instructions, I erased it, used Gparted to create a new partition and make that bootable, then started again. This seemed to work.

_________________
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER
Back to top
View user's profile Send private message 
LateAdopter

Joined: 27 May 2011
Posts: 321
Location: Reading UK

PostPosted: Mon 27 Mar 2017, 04:19    Post subject:  

Hello disciple
Windows gives you the first partition in the partition table, but it doesn't have to be first on the disk. If you can edit the partition table to reverse the order of the partitions, Windows would give you the FAT partiton.

When I put fatdog 710 on a new SD card I did a manual frugal install. so I don't have that problem:

write mbr.bin to the MBR using "cat"
mark the original partition as active
install G4D to the PBS
Copy fatdog files various including with fd64 and kernel modules pulled out
Add various fatdog entries to menu.lst.

Boot times over USB3:
34 seconds boot time with homogeneous initrd
16 sec with fd64.sfs and kernel-modules.sfs pulled out
22 sec with fd64.sfs out and loaded into ram, kernel-modules out.
Back to top
View user's profile Send private message 
_gg


Joined: 21 Jan 2009
Posts: 10

PostPosted: Mon 27 Mar 2017, 05:45    Post subject:  

jamesbond wrote:

step 4) how much memory does the Acer has?

This one has 4GB RAM.

jamesbond wrote:

step 5 and 6) ... The resulting ISO is a triple-hybrid ISO like the original and boots on BIOS and UEFI

I think it's some bug as fdisk doesn't see it properly as original:
Remastered:
Code:

$ losetup -f remaster-2017-03-23.iso
$ fdisk -l /dev/loop3

Disk /dev/loop3: 547 MiB, 573571072 bytes, 1120256 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x08f0e4e1

Device       Boot Start     End Sectors  Size Id Type
/dev/loop3p1 *       64 1120255 1120192  547M 17 Hidden HPFS/NTFS

(size is bigger as I also included devx sfs)

Original:
Code:

$ losetup -f Fatdog64-710.iso
$ fdisk -l /dev/loop4

Disk /dev/loop4: 360 MiB, 377487360 bytes, 737280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x705b87c5

Device       Boot Start    End Sectors  Size Id Type
/dev/loop4p1 *        0 737279  737280  360M  0 Empty
/dev/loop4p2        116  20595   20480   10M ef EFI (FAT-12/16/32)


jamesbond wrote:

step 9) ... there are tons of reason why this search can fail.

The one like below was working with my 2 flash drives.
Code:

search.fs_label FATDOG_LIVE --set
linux /vmlinuz waitdev=5 basesfs=label:FATDOG_LIVE:fd64.sfs savefile=none
initrd /initrd


LateAdopter wrote:

i915.preliminary_hardware_support=1

thanks. will try

prehistoric wrote:

I have a problem with Fatdog 710 networking

Also, about my using Fatdog I encountered 2 basic problems with networking:

1) when wired cable is replugged, IP is sometimes reset and DHCP doesn't automatically bring it back. using `dhcpcd eth0` helps.

2) when laptop is resumed from power suspend, it got the IP of last successful WIFI connection sticky and if you wake up in different wireless network it doesn't change IP until you manually reset it with `ifconfig wlan0 inet 0.0.0.0`.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Mon 27 Mar 2017, 07:34    Post subject:  

@prehistoric:
Thanks for the book recommendation. I'll check it out.

Quote:
In order to follow your instructions I had to delete not just 70-persistent-net.rules, but also 80-oldpersistent-net.rules. To avoid problems from doing this from a running system, I booted into tahrpup64 6.0.6 and deleted the files in the inactive Fatdog 710 save folder "/etc/udev/rules.d". When I rebooted, the wired network was reconfigured as eth0. I didn't have to tell it to use DHCP, it just came up working.

It is safe to do so from running Fatdog. You just need to reboot afterwards.
Even without deleting those stuff, you should already get DHCP. The fact that you don't, is curious.
I have an inkling of what happens, but I will need to do further checks.

Btw I'm not sure where you get that "80-oldpersistent-net.rules" from.

Quote:
I'm still not clear on what the damn Network Wizard is telling me. What difference does it make if an interface is "associated" or "activated" if it is impossible to send network traffic across it?

"Assosciated" is for Wifi only. It means the wifi adapter has connected to the wifi router.
"Activated" is for Network Setup only - it means that the network configuration chosen has been activated.

There are many other reasons why the network fails to connect.
---
"Associated" but no IP address (DHCP fails) => no connection.
"Activated" with static IP address but wrong IP range => no connection
IP good but router bad ==> can only ping to router, but not to Internet, etc.

Quote:
How can I tell if the system does or does not have a kernel module for the interface device?

No network interface will show up.

Quote:
Suppose everything in Fatdog is correct, but the device on the other end of the line is having trouble with DHCP. How do you isolate the problem? These are not hypothetical concerns, I've been there.

The usual tools. Ping, etc. How do you detect if your network cable has a kink which sometimes connect and sometimes not (assuming you don't have network cable tracer)?

Quote:
To avoid ticking off any number of people who do not spend all their free time solving puzzles please consider at least a button that resets everything to do with networking. It should not even require a reboot.

Yes, that's a good idea. Suggestion is being considered.

@Sage:
Quote:
Wondering how general this fix is for other distros? I occasionally find a phantom network show up. I think it can happen if I install on e.g. a machine with a wifi connection and then transfer the HD to a machine with a wired NIC. Can dynamically delete one of the alleged connections but it's never persistent.

It is general in its idea, but not necessarily in the details. See: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Different version of udev/systemd requires different names for disabling certain stuff.
In eudev it is 80-net-name-slot.rules. Or you can use net.ifnames=0 on boot parameter.
But only when compiled in a certain way.
Deleting 70-persistent-net.rules is another way, when compiled with rule generator.
I'm confusing you, aren't I?

@disciple:
Quote:
I followed the instructions to install to a usb stick and use fix-usb.sh*

That's the quick install method, yes.

Quote:
I used the remaining space on the drive to create a VFAT partition.

This is so we still use the remaining space.

Quote:
But it turns out "Windows... won't recognize more than one partition on a USB drive unless it has a certain bit set declaring it a USB-HDD".
In fact, this is a good way to hide data from Windows Smile

Quote:
I'm a bit lost on why this install method works the way it does though. Why not just have one filesystem on the USB stick? Is it a necessary consequence of trying to just use an iso image?

This is because the "image" is an triple-hybrid ISO image.
1. It's an ISO, and will boot when burned to a CD/DVD.
2. It's a harddisk image, with MBR. The MBR has 2 partitions:
a) 1st partition representing the ISO itself. Used for booting on BIOS systems
b) 2nd partition represents the efiboot.img, containing UEFI boot files.

Quote:
*Incidentally, the first time around the stick wasn't bootable, so, wondering if there was a step missing from the instructions, I erased it, used Gparted to create a new partition and make that bootable, then started again. This seemed to work.

Really? If you dd-it straight away, it should work.

Anyway, if you want to create a USB that can share data with Windows, there are a few ways you can do that:
a) Create one big FAT32 partition covering the whole drive.
b) Create first FAT32 partition which you can use to share data with Windows, and create a 2nd partition where you install Fatdog.

@LateAdopter: thanks for the additional information.

@_gg:
Quote:
I think it's some bug as fdisk doesn't see it properly as original:

That's definitely a bug. It could be that your're running out of space when creating the remaster?

Also, I see that your remaster is 547M in size. If you use UEFI, this **WILL NOT WORK** due to a silly bug: http://www.murga-linux.com/puppy/viewtopic.php?t=109891.

Quote:
1) when wired cable is replugged, IP is sometimes reset and DHCP doesn't automatically bring it back. using `dhcpcd eth0` helps.
Did you use network-setup to do this, or did you depend on auto-DHCP (that is, no configuration at all?)

Quote:
2) when laptop is resumed from power suspend, it got the IP of last successful WIFI connection sticky and if you wake up in different wireless network it doesn't change IP until you manually reset it with `ifconfig wlan0 inet 0.0.0.0`.
I never suspend. Suspend doesn't work on my laptop, so I can't test this. Which wifi manager do you use, WPA GUI or network setup?
_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1747

PostPosted: Mon 27 Mar 2017, 09:17    Post subject:  

@jamesbond

At the risk of antagonizing you, which I am not trying to do, I want to point out that a considerable part of your explanation depends on knowing the code which implements networking. (Myself, I'm deliberately staying out of code.) Nothing visible to a user dependent on the GUI will tell them that "associated" means the wifi adapter has connected to the wireless router. Even knowing that "activated" applies only to the network wizard and a particular configuration chosen still leaves me at the point of learning that "activated" means "activated".

(This kind of explanation is typical of what people whose minds inhabit the world of code produce under the impression they are conveying information. I know because I've been there and done this when I was a young whippersnapper. When people think you are a genius because they have no idea what you are talking about you should take that as a warning.)

I'm not arguing that I can't (eventually) figure this out, I'm trying to tell you what will happen when someone who does not read code runs into problems. You need to run user interface behavior by naive users who do not code. If your default is to do everything from the command line when there is a problem, then you need to document that first, before you simplify some matters with convenient user interfaces.

(I'll confess that this is a technique I used when managing programmers. They hated documentation so much that I often got much improved code as a result of requiring documentation for problems the code could not handle.)

Other parts of your explanation depend on dropping down to the command line to debug network problems, which is not really acceptable to most people. Even the clunky old Dougal network set up could tell me the failure was at the level of DHCP without using the command line. Such failures are surprisingly common in practice. (Ever get the wrong cable plugged in?)

When it comes to kernel modules, simply having no interface appear is hardly adequate feedback. I'm used to seeing a list of modules, and the name of the module used when the system finds a networking device. This makes it much easier to isolate the offending code when asking for help, even from someone who did not build this system. Knowing that the system is trying to use an RTL8139C produces much better searches than "something wrong with Fatdog networking." The problem may have nothing to do with Fatdog and James, and you do not want to become a clearinghouse for problems caused by others. Believe me, there are many, many obscure bugs in network interfaces that only show up under some peculiar conditions, as I suspect you know.

Like you, I don't understand why I could not connect using eth1 and DHCP after I switched machines. I suspect the problem is that some piece of code decided this was really eth0, since there was only one such device on the machine, while others called it eth1, but that is only a guess.
Back to top
View user's profile Send private message 
Sage

Joined: 04 Oct 2005
Posts: 5503
Location: GB

PostPosted: Mon 27 Mar 2017, 11:29    Post subject:  

Yes! But thanks.
Back to top
View user's profile Send private message 
LateAdopter

Joined: 27 May 2011
Posts: 321
Location: Reading UK

PostPosted: Mon 27 Mar 2017, 12:57    Post subject:  

Hello _gg

I had brain failure... It should be:
Code:
i915.preliminary_hw_support=1
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Mon 27 Mar 2017, 13:24    Post subject:  

@Sage:

In the past all device names were detected and set by kernel.
First disk detected is hda (or sda), second one is sdb, etc.
You can't change their names.

Recently, one kind of device supports renaming: network interface.
Some people want to use a unique network interface name (the Predictable Network Name I gave you above).
As far as I know, Linus doesn't want to know about it, so these guys they implemented the change in udev.

___

PS: If you want to see how your network interface will be named under the "new policy", run this in terminal:

"udevadm test-builtin net_id $(readlink -f /sys/class/net/eth0)"

Replace eth0 with wlan0, etc. And you'll see for yourself the grand new names they have planned for us, hehehe.

___

A lot of people dislike the new names, so to appease them, udev authors comes with support to disable the grand new name.

The usual way to disable these, is by creating an empty file (or just symlink to /dev/null) in /etc/udev/rules.d, with the same filename as the system rule file that you want to disable.

(Udev system rules lives in /lib64/udev/rules.d; local rules lives in /etc/udev/rules.d; if you have two rule files with same filename in both location, the one in /etc/udev/rules.d takes precedence).

As usual for udev authors, they change stuff from versions to versions and the empty file you need to create in /etc/udev/rules.d keeps changing. Also, they invented yet another way to disable this new grand scheme, by passing boot parameter "net.ifnames".

All these doesn't concern end-users; it only concerns distro builders who want to disable it.

Recently, there is a 3rd way to give name to network interface - by using rule generator.
Rule generator works by generating a randome, yet unique, name, for a network interface, then keeping a record of that name.
This name is kept in an udev rule file which is /etc/udev/rules.d/70-persistent-net.rules (for Fatdog).

The idea is, once this rule has been generated automatically for you, you can always change it later and it will stick.
This is done for all names, including eth0 and wlan0.

This presents an obvious problem - if you move a savefile (which contains this persistent file) to another machine, the new machine's network interface will never be called eth0 or wlan0 anymre (since there is already a record for eth0/wlan0 from the previous machine).

To "reset" the network names, all you need to do is just to delete the 70-persistent-net.rules files; and then reboot.
The rule generetor will re-assign new names again to the network interface and your wired interface will most likely be eth0 and your wireless be wlan0 again.

However, rule generator is an option.
It can be disabled.
But to disable it, you need to re-compile udev.
It cannot be disabled at run-time. It is either enabled at compile time, or disabled.
If you try to disable rule-generator (by disabling its rules) at run-time when it was enabled at build-time; you will get the worst of both worlds: random interface name (e.g. wlan124) which cannot be automatically be renamed.

____

Now, how is this applicable to other distros? In general, what I said above applies to any distros. But the specifics (which filename to delete, etc) will differ from distro to distro depending on how their udev is built; depending on which version the use; and also depending on whether they have applied their special sauce (custom patch) for udev to do yet another screwy things.

I hope this is clearer.

____

@prehistoric:

Thank you for the feedback. I just want to know that my response to you previously is meant for you, not for others. I know you're familiarity with the tool and comfortable with CLI. I will talk at different level for people who has lesser knowledge.

Yet, you do have good points. Diagnostic information when there is failure is useful. We'll make an improvement for the future, but as usual, don't hold our breath: we're slow and lazy Smile

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
_gg


Joined: 21 Jan 2009
Posts: 10

PostPosted: Tue 28 Mar 2017, 02:56    Post subject:  

jamesbond wrote:

It could be that your're running out of space when creating the remaster?

Not sure. I specified my /aufs/devsave/tmp with 150 GB free space. And as I have 8 GB RAM on my Fujitsu notebook I do the remaster on, it's near 4 GB free space for /tmp. Do remaster touch any other fs besides specified? Or maybe it may asynchronously continue after it said "Done"?

Also, remastered ISO is empty for about 800 kB at the end:
Code:

$ tail -c 1000000 remaster-2017-03-23.iso|hexdump -C|tail -n 5
0002b590  36 69 74 3c d2 c5 f2 7d  51 cd be ca d4 02 86 64  |6it<...}Q......d|
0002b5a0  f2 01 f8 08 c4 00 00 00  00 00 00 00 00 00 00 00  |................|
0002b5b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000f4240


Yet, official ISO is empty only for 416 bytes:
Code:

$ tail -c 1000000 Fatdog64-710.iso|hexdump -C|tail -n 5
000f4080  84 0e 1b af 13 68 1c 8f  df 3f 0b 00 00 00 00 00  |.....h...?......|
000f4090  80 00 00 00 80 00 00 00  ea 52 a1 3d 00 00 00 00  |.........R.=....|
000f40a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000f4240


Also, I did a bigger remaster before that one and their tails before zeroes are identical:
Code:

$ tail -c 1000000 remaster-2017-03-23-old.iso|hexdump -C|tail -n 5
000a8d90  36 69 74 3c d2 c5 f2 7d  51 cd be ca d4 02 86 64  |6it<...}Q......d|
000a8da0  f2 01 f8 08 c4 00 00 00  00 00 00 00 00 00 00 00  |................|
000a8db0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000f4240

But zero tail is 300kB long.

jamesbond wrote:

http://www.murga-linux.com/puppy/viewtopic.php?t=109891

I'll apply the updates and try making+booting new ISO.

jamesbond wrote:

Did you use network-setup to do this, or did you depend on auto-DHCP (that is, no configuration at all?)

No configuration, it's out-of-box.

jamesbond wrote:

Which wifi manager do you use, WPA GUI or network setup?

WPA GUI

LateAdopter wrote:

i915.preliminary_hw_support=1

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


Joined: 21 Jan 2009
Posts: 10

PostPosted: Tue 28 Mar 2017, 03:18    Post subject:  

@jamesbond,
also remembered: one of the steps of remaster was to specify "efiboot.img" file. I had mounted Fatdog ISO via GUI and specified this location:
Code:

/mnt/+mnt+sda2+tmp+Downloads+linux+Fatdog64-710+iso/efiboot.img

Yet at step of "check/modify contents of future ISO" in tempfolder, "efiboot.img" was missing and I had to copy it manually there. Maybe remaster setup didn't recognize that location and that I want to make EFI bootable?
Back to top
View user's profile Send private message 
Sage

Joined: 04 Oct 2005
Posts: 5503
Location: GB

PostPosted: Tue 28 Mar 2017, 03:31    Post subject:  

Got it! Ta, jb.
K.I,S.S. always pertains...
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Wed 29 Mar 2017, 03:22    Post subject:  

@_gg: Thanks for the info.

Quote:
Not sure. I specified my /aufs/devsave/tmp with 150 GB free space. And as I have 8 GB RAM on my Fujitsu notebook I do the remaster on, it's near 4 GB free space for /tmp.
That should be more than enough.

Quote:
Do remaster touch any other fs besides specified? Or maybe it may asynchronously continue after it said "Done"?
No.

Quote:
Also, remastered ISO is empty for about 800 kB at the end:
That's odd, I will get need to get back to you.

Quote:
I'll apply the updates and try making+booting new ISO.
You basically just need to use the new efiboot.img instead of the one you find in Fatdog ISO.

Quote:
No configuration, it's out-of-box.
Okay, so that's dhcpcd problem. Dhcpcd is supposed to detect if a network cable is unplugged and replugged; and it's supposed to re-acquire IP address when this happens. Apparently it doesn't. Will have to find a solution later.

Quote:
Yet at step of "check/modify contents of future ISO" in tempfolder, "efiboot.img" was missing and I had to copy it manually there. Maybe remaster setup didn't recognize that location and that I want to make EFI bootable?

Did you tick the checkbox at the bottom of the dialog?

@prehistoric:

EDIT:
This post used to contain my adapted package of rcrsn51's peasywifi. Since then, rcrsn51 has kindly provided the official Fatdog's compatible version of his peasywifi. Please use his official version instead, 3 posts below.

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder

Last edited by jamesbond on Wed 29 Mar 2017, 12:13; edited 1 time in total
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 12805
Location: Stratford, Ontario

PostPosted: Wed 29 Mar 2017, 08:39    Post subject:  

I already have a 64bit version ready to go that is compatible with Fatdog. All you had to do was ask.

If you are going to manage your own version of PWF, you should give the package a different name.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Wed 29 Mar 2017, 09:04    Post subject:  

rcrsn51 wrote:
I already have a 64bit version ready to go that is compatible with Fatdog. All you had to do was ask.
I'm not aware of that. Please provide the Fatdog-compatible version of peasywifi; and I will drop the version I posted above, thanks.

Quote:
If you are going to manage your own version of PWF, you should give the package a different name.
Everything inside is your work, unmodified. I just added code to be enable/disable integration at run-time (instead of at install time), I don't think it's appropriate to name the package something else and take the credit away from you.
_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 12805
Location: Stratford, Ontario

PostPosted: Wed 29 Mar 2017, 09:36    Post subject:  

Here is the 64bit version of PWF v4.2. It is compatible with Fatdog.

1. Install the PET using the two-step right-click procedure that converts the package format.
2. Its post-install script disables wpa-gui. A reboot is required.

I have attached the source code for the tray applet.

@James: Are you confirming that PWF works for you in Fatdog?

[Edit] Withdrawn for repairs.
peasywifi_tray_source.tar.gz
Description 
gz

 Download 
Filename  peasywifi_tray_source.tar.gz 
Filesize  647 Bytes 
Downloaded  155 Time(s) 

Last edited by rcrsn51 on Sat 01 Apr 2017, 06:56; edited 2 times in total
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 22 of 44 [646 Posts]   Goto page: Previous 1, 2, 3, ..., 20, 21, 22, 23, 24, ..., 42, 43, 44 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
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.1151s ][ Queries: 13 (0.0352s) ][ GZIP on ]