Precise Puppy 5.5 Release Candidate
Dear Kernel 3.8.0:
On my Asus A7V400-MX with 500 mb RAM, using Puppy Precise 5.4.93 .iso burned to a DVD, the BootFlash Installer and the Puppy Universal Installer both produce a USB that, when it is booted, unfortunately states
"Searching for Puppy files. puppy_precise_5.4.93.sfs not found."
And, as well, this being Awards Season in North America, I would like to nominate Sage an 'Understatement of the Year' award for the comment
"Remarkably slow loading and initial setup ...."
On my Asus A7V400-MX with 500 mb RAM, using Puppy Precise 5.4.93 .iso burned to a DVD, the BootFlash Installer and the Puppy Universal Installer both produce a USB that, when it is booted, unfortunately states
"Searching for Puppy files. puppy_precise_5.4.93.sfs not found."
And, as well, this being Awards Season in North America, I would like to nominate Sage an 'Understatement of the Year' award for the comment
"Remarkably slow loading and initial setup ...."
-
- Posts: 29
- Joined: Sat 17 Jan 2009, 00:15
-
- Posts: 29
- Joined: Sat 17 Jan 2009, 00:15
I'm getting configure errors, I wanted to learn to make .pets, and downloaded Mplayer, Httrack, and Rhythmcat and in each typing ./configure gets me the same error:
I can't recall seeing this on Fedora, but I haven't done much with source, am I doing something wrong, or is GCC?
This is on 5.4.90, with G.C.C 4.6.3
Code: Select all
checking whether we are cross compiling... configure: error: in `/mnt/sdb2/RhythmCat-1.0.0-1':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
This is on 5.4.90, with G.C.C 4.6.3
Frugal install of 5.4.9.2....all looking good so far.
# report-video
VIDEO REPORT: Precise Puppy, version 5.4.92
Chip description:
VGA compatible controller: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] (rev a2)
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1024x768x16
Depth (bits, or planes): 24
Modules requested to be loaded: dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): nouveau
Loaded modules: dbe dri dri2 exa extmod fb glx kbd mouse record shadowfb
Actual rendering on monitor:
Resolution: 1440x900 pixels (380x238 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
#
-Computer-
Processor : 2x AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
Memory : 3888MB (227MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Thu 21 Feb 2013 11:43:52 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Gallium 0.4 on NV4C
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : HDA-Intel - HDA NVidia
-In-Computer-
Processor : 2x AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
Memory : 3888MB (227MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Thu 21 Feb 2013 11:43:52 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Gallium 0.4 on NV4C
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : HDA-Intel - HDA NVidia
Actual rendering on monitor:
Resolution: 1440x900 pixels (380x238 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
#
# report-video
VIDEO REPORT: Precise Puppy, version 5.4.92
Chip description:
VGA compatible controller: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] (rev a2)
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1024x768x16
Depth (bits, or planes): 24
Modules requested to be loaded: dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): nouveau
Loaded modules: dbe dri dri2 exa extmod fb glx kbd mouse record shadowfb
Actual rendering on monitor:
Resolution: 1440x900 pixels (380x238 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
#
-Computer-
Processor : 2x AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
Memory : 3888MB (227MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Thu 21 Feb 2013 11:43:52 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Gallium 0.4 on NV4C
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : HDA-Intel - HDA NVidia
-In-Computer-
Processor : 2x AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
Memory : 3888MB (227MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Thu 21 Feb 2013 11:43:52 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Gallium 0.4 on NV4C
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : HDA-Intel - HDA NVidia
Actual rendering on monitor:
Resolution: 1440x900 pixels (380x238 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
#
compressed NTFS
I have found a problem with use of compressed-NTFS and both versions of 5.5beta.
This problem differs from past reports because this problem occurs in the following manner. (As we may remember, the past problem was with SHUTDOWN processing of the save-session)
This problem occurs at boot-time under the following scenario:By simply moving the Precise data folder from the compressed-NTFS to a standard NTFS,and having GRUB4DOS point to its new NTFS location, the system will boot without problems.
This has not happened with Pemasu's versions of Precise.
Hope this helps.
This problem differs from past reports because this problem occurs in the following manner. (As we may remember, the past problem was with SHUTDOWN processing of the save-session)
This problem occurs at boot-time under the following scenario:
- Copy the CD contents to a folder on compressed-NTFS
- Instruct the GRUB4DOS boot manager to find the files needed at boot.
- Boot system with newly changed GRUB4DOS
Code: Select all
(hd0,4)
[Linux-bzImage, setup=0x3e00, size=0s2ce260]
[Linux-initrd @ 0x5e3000,0x1df473 bytes]
uncompression error
--system halted
This has not happened with Pemasu's versions of Precise.
Hope this helps.
Precise 5.4.9.3 (k3.8.0)
@micko1:
I tried a clean boot with: as suggested. This does allow you to load the nouveau driver with the xorgwizard prompting both report-video and xorg.conf to identify the driver as 'nouveau'. Unfortunately, glxgears reports only 38 fps (as compared to ca. 1350 fps with k3.2.29 and the proprietary nvidia driver 173.14.35 in Precise 5.4.92). So at least with my hardware (GeForce FX5200), this does not seem to be a viable solution.
@pemasu:
Unfortunately, linking the missing version.h (or copying it to the expected location does not fix the problem with compiling the nvidia drivers in k3.8.0 as it did in k3.7.2. This produces:
This is true for 173.14.35 and the latest driver 173.14.36 (dated October 4, 2012).
@rcrsn51:
Thanks for the explanation. It is too bad that the newer kernels won't work with the Samba-TNG server. I don't have time to mess with the full samba at the moment, so I will just have to roll back to an earlier kernel.
I tried a clean boot with:
Code: Select all
pfix=ram nouveau.noaccel=1
@pemasu:
Unfortunately, linking the missing version.h (or copying it to the expected location does not fix the problem with compiling the nvidia drivers in k3.8.0 as it did in k3.7.2. This produces:
Code: Select all
Error: Unable to determine kernel module filename
@rcrsn51:
Thanks for the explanation. It is too bad that the newer kernels won't work with the Samba-TNG server. I don't have time to mess with the full samba at the moment, so I will just have to roll back to an earlier kernel.
Re: compressed NTFS
I cannot duplicate this problem. I made a compressed NTFS drive and booted 5493 using Grub4Dos. Everything worked correctly, including saving to /mnt/home.gcmartin wrote:I have found a problem with use of compressed-NTFS and both versions of 5.5beta.
syslogd & klogd send messages from the future.
When examining /var/log/messages, one will notice that many messages seem to be coming from some time in the future. If one is not aware of this, it can be very confusing while trying to troubleshoot problems. Even if one is aware of it, it is confusing since not all messages arrive via time warps, so one cannot simply subtract a constant offset to determine the actual time that any given message arrived. It is as if time keeps jumping backward and forward.
(Although I don't have Precise Puppy, this behavior has existed in recent Puppies, and looking at the appropriate scripts in Woof, I see no reason to think that this has changed.)
Here is what is happening:
In order to prevent timestamps from the future from being written to a partition during e2fsck, in the init script in initrd, the TZ environment variable is set to a fictitious time zone 23 hours east of Greenwich ("TZ=XXX-23"). (See Barry's blog: Timezone in the initrd (initramfs))
So if the hardware clock currently says 12:00 noon on Monday, Linux will assume it is 12:00 noon on Monday in that fictitious time zone when init executes "/bin/hwclock --hctosys --localtime", and sets the system clock to 13:00 UTC on Sunday.
This is good. It works as intended.
But the system clock will later be reset by /etc/rc.country based upon the user's actual timezone. If the user lives in London, the system clock will be reset to 12:00 noon UTC on Monday.
Now any process that still believes "TZ=XXX-23" will believe that the local time is 11:00 AM on Tuesday.
Because syslogd and klogd were started with "TZ=XXX-23" in their environment, they still think they are living in that fictitious time zone. So klogd will send log messages with timestamps based on local time in that timezone, which will be 23 hours ahead of UTC. Messages passed to syslogd will also be logged with a timestamp 23 hours ahead of UTC, unless the caller passes its own timestamp along with the message that it passes to syslogd.
The time offset will not always be 23 hours, but will vary depending upon the user's time zone. For instance, in the UTC+1 time zone the offset will be only 22 hours. In the UTC+8 time zone it will be 15 hours. But it can be as much as 35 hours -- that would be in the UTC-12 time zone (although that time zone mostly applies only to folks visiting a few uninhabited Pacific islands or in the radio room of a ship on the high seas just east of 180 degrees of longitude ).
Here is an example:
In the following excerpt from a bash session I run logger to send a message to syslogd; logger knows the correct timezone and so sends a good timestamp. Then I pass a message to /dev/kmsg, which klogd finds and sends on to syslogd; klogd still thinks the timezone is "XXX-23" so sends a bad timestamp. (I am using UTC for localtime.)
The easiest way to fix it is probably to simply restore one line of code in /etc/rc.d/rc.sysinit that Barry added on 2010-Mar-19, but soon commented-out. This is the line:
Then, after restoring:
I have not tried this, so this advice comes with no warranty, and I don't know if there might be any nasty side-effects. But I don't anticipate any, since all it does is allow processes started to use /etc/localtime, whatever that may be, or UTC if /etc/localtime doesn't exist, rather the the fictitious time zone.
Barry, I'm guessing that you commented-out that line since the time zone would soon be set in rc.country, based on the next comment in the code:
If I am assuming incorrectly, and unsetting TZ caused problems, a better fix will obviously be needed.
(One minor side-effect of this suggested fix would be that any messages logged by syslogd or klogd in the few seconds before the system clock is reset -- including any in the kmsg queue -- will have a wrong timestamp. As it stands now, if the hardware clock is set to local time, those timestamps will actually be right: since both the system clock and the time zone are wrong, the two wrongs cancel each other out. With the suggested fix, during those few seconds timestamps would seem to come from the past by varying amounts of time, again depending upon local time zone, or by exactly 23 hours on first boot when the /etc/localtime symlink does not yet exist. That's assuming hardware clock is on local time. If it is on UTC, timestamps would seem to come from exactly 23 hours in the past, or by varying amounts of time on first boot when the /etc/localtime symlink does not yet exist. But it seems preferable to have the timestamps correct for all the time between boot and shutdown than to have them correct during a small fraction of the boot process.)
Of course there are alternate solutions:
The syslogd and klogd daemons could be restarted after rc.country sets the clock properly by running "00sys_logger stop" and 00sys_logger start".
Or setting the clock could be moved forward in the boot process so that it happens before those logging daemons are first started. But I don't know what complications might arise from doing that.
Here is an example of someone who ran into this timestamp problem. He reported that restoring the "unset TZ" line in rc.sysinit fixed it.
Time weirdness, reported time is 31 hours into the future
(His local time was UTC-8. 8 + 23 = 31.)
Here is my response.
Another report:
(Although I don't have Precise Puppy, this behavior has existed in recent Puppies, and looking at the appropriate scripts in Woof, I see no reason to think that this has changed.)
Here is what is happening:
In order to prevent timestamps from the future from being written to a partition during e2fsck, in the init script in initrd, the TZ environment variable is set to a fictitious time zone 23 hours east of Greenwich ("TZ=XXX-23"). (See Barry's blog: Timezone in the initrd (initramfs))
So if the hardware clock currently says 12:00 noon on Monday, Linux will assume it is 12:00 noon on Monday in that fictitious time zone when init executes "/bin/hwclock --hctosys --localtime", and sets the system clock to 13:00 UTC on Sunday.
This is good. It works as intended.
But the system clock will later be reset by /etc/rc.country based upon the user's actual timezone. If the user lives in London, the system clock will be reset to 12:00 noon UTC on Monday.
Now any process that still believes "TZ=XXX-23" will believe that the local time is 11:00 AM on Tuesday.
Because syslogd and klogd were started with "TZ=XXX-23" in their environment, they still think they are living in that fictitious time zone. So klogd will send log messages with timestamps based on local time in that timezone, which will be 23 hours ahead of UTC. Messages passed to syslogd will also be logged with a timestamp 23 hours ahead of UTC, unless the caller passes its own timestamp along with the message that it passes to syslogd.
The time offset will not always be 23 hours, but will vary depending upon the user's time zone. For instance, in the UTC+1 time zone the offset will be only 22 hours. In the UTC+8 time zone it will be 15 hours. But it can be as much as 35 hours -- that would be in the UTC-12 time zone (although that time zone mostly applies only to folks visiting a few uninhabited Pacific islands or in the radio room of a ship on the high seas just east of 180 degrees of longitude ).
Here is an example:
In the following excerpt from a bash session I run logger to send a message to syslogd; logger knows the correct timezone and so sends a good timestamp. Then I pass a message to /dev/kmsg, which klogd finds and sends on to syslogd; klogd still thinks the timezone is "XXX-23" so sends a bad timestamp. (I am using UTC for localtime.)
Code: Select all
# date
Fri Feb 22 13:49:26 UTC 2013
# logger "Test message via logger."
# echo "Test message via klogd." > /dev/kmsg
# tail -n 2 /var/log/messages
Feb 22 13:49:33 puppypc9902 user.notice root: Test message via logger.
Feb 23 12:49:43 puppypc9902 user.warn kernel: [771703.492205] Test message via klogd.
# date
Fri Feb 22 13:50:11 UTC 2013
#
Code: Select all
#unset TZ #100319 busybox hwclock gives priority to this (rather than /etc/localtime) and 'init' has set it wrong.
Code: Select all
unset TZ #100319 busybox hwclock gives priority to this (rather than /etc/localtime) and 'init' has set it wrong.
Barry, I'm guessing that you commented-out that line since the time zone would soon be set in rc.country, based on the next comment in the code:
Code: Select all
#...comment-out for now. note, TZ now set in rc.country.
(One minor side-effect of this suggested fix would be that any messages logged by syslogd or klogd in the few seconds before the system clock is reset -- including any in the kmsg queue -- will have a wrong timestamp. As it stands now, if the hardware clock is set to local time, those timestamps will actually be right: since both the system clock and the time zone are wrong, the two wrongs cancel each other out. With the suggested fix, during those few seconds timestamps would seem to come from the past by varying amounts of time, again depending upon local time zone, or by exactly 23 hours on first boot when the /etc/localtime symlink does not yet exist. That's assuming hardware clock is on local time. If it is on UTC, timestamps would seem to come from exactly 23 hours in the past, or by varying amounts of time on first boot when the /etc/localtime symlink does not yet exist. But it seems preferable to have the timestamps correct for all the time between boot and shutdown than to have them correct during a small fraction of the boot process.)
Of course there are alternate solutions:
The syslogd and klogd daemons could be restarted after rc.country sets the clock properly by running "00sys_logger stop" and 00sys_logger start".
Or setting the clock could be moved forward in the boot process so that it happens before those logging daemons are first started. But I don't know what complications might arise from doing that.
Here is an example of someone who ran into this timestamp problem. He reported that restoring the "unset TZ" line in rc.sysinit fixed it.
Time weirdness, reported time is 31 hours into the future
(His local time was UTC-8. 8 + 23 = 31.)
Here is my response.
Another report:
On Jan 29, [url=http://www.murga-linux.com/puppy//viewtopic.php?p=680873#680873]in Slacko-5.4 feedback and bug reports[/url], ally wrote:also noticed that /var/log/messages date is one day forward (ie 30 jan)?
+1 thanks, have that same issue, but on a 1024x600 screen, so may need to scrollbar with less rows... keep a easy to find label tab on that fix if 11 is still too long.kurtdriver wrote:BarryK wrote:
OK, SNS now has a scrollbar if more than 11 wifi networks found.
This is in Woof, committed and uploaded.
Oh, thank you, very much!
The mouse freeze at first boots seems to have reappeared on the newer kernel version, maybe add a kernel command switch to adjustable timeout increase until the cause is found.
This version seems crisp, clean and more responsive. Like the choice of colors, icons and wallpaper.
Broadcom wl driver
I have compiled the Broadcom wl driver for Precise 5.5Beta with kernel 3.8.0
Load the delta file from:
http://murga-linux.com/puppy/viewtopic. ... 5&start=49
followed by the multi-kernel driver pet from post #1 of that topic
then reboot.
I had some problems compiling which I will record in Barry's blog.
Cheers
peebee
Load the delta file from:
http://murga-linux.com/puppy/viewtopic. ... 5&start=49
followed by the multi-kernel driver pet from post #1 of that topic
then reboot.
I had some problems compiling which I will record in Barry's blog.
Cheers
peebee
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Precise Puppy version 5.4.93 (5.5beta)
Manual frugal to ext3 partition and booting via grub4dos, on my 10yr old Acer laptop.
Exceptional, all the basics work as expected OOTB .
Not quite as nippy as on the newer laptop, but that’s expected.
All things considered - a Luvly Puppy - many thanks.
Hinfo report FYI.
Manual frugal to ext3 partition and booting via grub4dos, on my 10yr old Acer laptop.
Exceptional, all the basics work as expected OOTB .
Not quite as nippy as on the newer laptop, but that’s expected.
All things considered - a Luvly Puppy - many thanks.
Hinfo report FYI.
- Attachments
-
- hardinfo_report.html.gz
- not a gz. rename t html.
- (44.32 KiB) Downloaded 179 times
[b]Asus[/b] 701SD. 2gig ram. 8gb SSD. [b]IBM A21m[/b] laptop. 192mb ram. PIII Coppermine proc. [b]X60[/b] T2400 1.8Ghz proc. 2gig ram. 80gb hdd. [b]T41[/b] Pentium M 1400Mhz. 512mb ram.
Precise Puppy version 5.4.92 (5.5beta)
Exactly the same setup as above (5.4.93) and the same Laptop.
All seems very good and all basics working OOTB.
5.4.93 feels very slightly nippier, but not really much in it.
Running temperature and CPU activity seem about the same.
Both outstanding on a 10yr old Laptop. Again - many thanks.
Exactly the same setup as above (5.4.93) and the same Laptop.
All seems very good and all basics working OOTB.
5.4.93 feels very slightly nippier, but not really much in it.
Running temperature and CPU activity seem about the same.
Both outstanding on a 10yr old Laptop. Again - many thanks.
- Attachments
-
- hardinfo_report.html.gz
- (44.15 KiB) Downloaded 246 times
[b]Asus[/b] 701SD. 2gig ram. 8gb SSD. [b]IBM A21m[/b] laptop. 192mb ram. PIII Coppermine proc. [b]X60[/b] T2400 1.8Ghz proc. 2gig ram. 80gb hdd. [b]T41[/b] Pentium M 1400Mhz. 512mb ram.
Precise Puppy 5.5beta
I did a remaster of 5.4.93 adding quite a few applications from
pets,debs,and ppm,the iso grew to 500+ mb but the dvd works well on several
computers.
VIDEO REPORT: Precise Puppy, version 5.4.93
Chip description:
VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Manhattan
[Mobility Radeon HD 5400 Series]
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1600x900
Depth (bits, or planes): 24
Modules requested to be loaded: synaptics dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): ati
Loaded modules: dbe dri dri2 exa extmod fb glx kbd mouse radeon ramdac
record synaptics
Actual rendering on monitor:
Resolution: 1600x900 pixels (423x238 millimeters)
Depth: 24 planes
pets,debs,and ppm,the iso grew to 500+ mb but the dvd works well on several
computers.
VIDEO REPORT: Precise Puppy, version 5.4.93
Chip description:
VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Manhattan
[Mobility Radeon HD 5400 Series]
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1600x900
Depth (bits, or planes): 24
Modules requested to be loaded: synaptics dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): ati
Loaded modules: dbe dri dri2 exa extmod fb glx kbd mouse radeon ramdac
record synaptics
Actual rendering on monitor:
Resolution: 1600x900 pixels (423x238 millimeters)
Depth: 24 planes
- Attachments
-
- screenshot.jpg
- (62.85 KiB) Downloaded 720 times
Precise Puppy 5.4.92
- faster to boot than 5.4.90
- I think acpi_cpufreq is not needed (where does it work?)
- /tmp/dhcpcd.log "Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory"
- /var/log/Xorg.0.log
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(EE) Failed to load module "fglrx" (module does not exist, 0)
- some files groups are still wrong
- /etc/apm obsolete
- /etc/dbus-1/system.d/ missing
- /etc/gconf/ obsolete
- SMB Browser broken :
open /root/network/ in ROX click "Network", shows "scanning network, please wait", then "finished!" then nothing...
From command line, AppRun, displays "it dosen't seem like you are..." "bash: /root/options: No such file or directory"
- gnome player "open location" missing icon
- Bright color in console doing ls -la /dev/ram comes from "/etc/profile" line 188 alias ls='ls --color=auto'
- faster to boot than 5.4.90
- I think acpi_cpufreq is not needed (where does it work?)
- /tmp/dhcpcd.log "Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory"
- /var/log/Xorg.0.log
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(EE) Failed to load module "fglrx" (module does not exist, 0)
- some files groups are still wrong
- /etc/apm obsolete
- /etc/dbus-1/system.d/ missing
- /etc/gconf/ obsolete
- SMB Browser broken :
open /root/network/ in ROX click "Network", shows "scanning network, please wait", then "finished!" then nothing...
From command line, AppRun, displays "it dosen't seem like you are..." "bash: /root/options: No such file or directory"
- gnome player "open location" missing icon
- Bright color in console doing ls -la /dev/ram comes from "/etc/profile" line 188 alias ls='ls --color=auto'
Menu>Setup>QuickSetup First Run Settings
Sometimes a picture is worth a thousand words.
QuickSetup - User assist for initial system starts
Can someone explain why when the wireless laptop does not have a LAN cable plugged in when the PC is booted pfix=ram for beta test, I do not get a Network section; versus when a LAN wire is plugged in, I do?
The Network section is equally important for use of the laptop in both cases of wire out or wire in.
Is this a bug? If so which is the bug...showing it or not showing it?
QuickSetup - User assist for initial system starts
Can someone explain why when the wireless laptop does not have a LAN cable plugged in when the PC is booted pfix=ram for beta test, I do not get a Network section; versus when a LAN wire is plugged in, I do?
The Network section is equally important for use of the laptop in both cases of wire out or wire in.
Is this a bug? If so which is the bug...showing it or not showing it?
- Attachments
-
- capture11550.png
- Network section does not display even though its needed
- (60.98 KiB) Downloaded 642 times
-
- capture3830.png
- Displays if a cable is plugged into the Laptop
- (72.16 KiB) Downloaded 653 times
FIND command, command use, or terminal problem
I was searching for the existence of a file using the find command.
This worksAs does this, too
BUT THIS results in errors shown
Is this
Note: This may or may not be important in light of filesystem changes that are being introduced in Precise: BUT, /mnt/sda1 is a FAT16 drive on the HDD.
Here to help
This works
Code: Select all
# cd ~
# find / -name grl*
Code: Select all
# find /mnt/sda1 -name grl*
Code: Select all
# pwd
/root
# whoami
root
# cd /mnt/sda1
# find . -name grl*
find: paths must precede expression: grldr1.old
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
# find / -name grl*
find: paths must precede expression: grldr1.old
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
- a terminal problem?
- a find command problem?
- incorrect use of find command?
Note: This may or may not be important in light of filesystem changes that are being introduced in Precise: BUT, /mnt/sda1 is a FAT16 drive on the HDD.
Here to help