xdelta3 patch. Testers needed. - Page 3

BitJam · posted: 2013-05-09 18:27

Thanks SamK!

SamK wrote:When shutting down live CD session a message is obtained to remove CD. The tray is not automatically ejected and cannot be released manually. The system must be powered down and restarted to remove the CDROM.

Are there any error messages a line or two above the message about removing the CD? Maybe an"input/output" error?

You can get slightly more detailed (and colorful) messages during shutdown with the"uverb=8" boot parameter (uverb stands for"umount verbosity"). The color should make the error messages (which are not colored) stand out better.

You can get to a shell right before the eject command is going to be given with the"ubp=5" boot parameter (ubp stands for"umount break point"). Inside the breakpoint (and I think this might actually work) run"umount -r /dev/sr0". If you have more than one cdrom or dvd device then"umount -r /boot-dev" should always work regardless of which device holds the LiveCD. You can then try to run the"eject" command yourself or just use the"exit" command finish the shutdown.

Thanks also for you F5 tests. The cases where you got"no display obtained" are very helpful. We had been planning to use the label"very safe" for the mode which caused your Matrox card to have no display. We may need to rethink that.

SamK · posted: 2013-05-09 18:33

Feedback re Connectshares

Missing Dependency

Code: Select all

apt-cache policy nfs-common
nfs-common:
  Installed: (none)
  Candidate: 1:1.2.6-3
  Version table:
     1:1.2.6-3 0
        500 http://ftp.us.debian.org/debian/ wheezy/main i386 Packages

Menu Entries
OS Ver=antiX-13-beta3_386-full (unpatched)
Entries are present in Start-->Applications-->System Tools
Connectshares
Connectshares Configuration
Disconnectshares

OS Ver=antiX-13-RC1_386-full (patched)
Entries are missing in Start-->Applications-->System Tools

SamK · posted: 2013-05-10 08:51

BitJam wrote:We had been planning to use the label"very safe" for the mode which caused your Matrox card to have no display. We may need to rethink that.

In view of this comment, and also as in the past the card has occasionally been quirky with various OSs the card has been retested.

The original test was conducted three times using"default". On each test the same fail result was obtained.

The retest was conducted five times using"default". Four of the five retests produced a display 1024x768@60.0hz

It might be the quirky nature of this particular adaptor (rather than something more fundamental) that is producing the conflicting (re)test results.

Possibly OK to use the label"very safe"

SamK · posted: 2013-05-10 08:56

BitJam wrote:
SamK wrote:When shutting down live CD session a message is obtained to remove CD. The tray is not automatically ejected and cannot be released manually. The system must be powered down and restarted to remove the CDROM.
Are there any error messages a line or two above the message about removing the CD? Maybe an"input/output" error?

..."uverb=8" boot parameter (uverb stands for"umount verbosity"). The color should make the error messages (which are not colored) stand out better.

..."ubp=5" boot parameter (ubp stands for"umount break point"). Inside the breakpoint (and I think this might actually work) run"umount -r /dev/sr0".

Booted using uverb=8
Start-->Logout-->Reboot
Shutdown messages

Code: Select all

...
umount-live: pivot_root: /live/aufs
umount-live: Move some mountpoints out of aufs
umount-live: Kill most remaining procesess
umount-live: start_t: 23455
umount-live: kill -KILL 3743 3752
umount-live: Unmount most filesystems
unmounting /run/shm /run/lock /run /media /aufs /aufs-ram /linux /boot-dev
           /run/shm /run/lock /run /media /aufs /aufs-ram /linux /boot-dev  <--UNCOLOURED
umount-live: Disable swap
...

System has a single CD-ROM device
Booted using uverb=8 ubp=5
Start-->Logout-->Reboot
At breakpoint

Code: Select all

umount -r /dev/sr0
umount: can't umount /dev/sr0: Invalid argument
umount -r /boot-dev
umount: can't umount /boot-dev: Invalid argument
eject
eject: /dev/cdrom: Input/output error
eject /dev/sr0
eject: /dev/sr0: Input/output error
grep sr0 /proc/mounts
blank

SamK · posted: 2013-05-10 09:58

SamK wrote:Feedback re Connectshares

Missing Dependency
Code: Select all
apt-cache policy nfs-common
nfs-common:
  Installed: (none)
  Candidate: 1:1.2.6-3
  Version table:
     1:1.2.6-3 0
        500 http://ftp.us.debian.org/debian/ wheezy/main i386 Packages
Menu Entries
OS Ver=antiX-13-beta3_386-full (unpatched)
Entries are present in Start-->Applications-->System Tools
Connectshares
Connectshares Configuration
Disconnectshares

OS Ver=antiX-13-RC1_386-full (patched)
Entries are missing in Start-->Applications-->System Tools

The missing menu entries seem to be due to connectshares et al not being present in RC1

beta3

Code: Select all

ls -1 /usr/local/bin/connect*
/usr/local/bin/connectshares
/usr/local/bin/connectshares-config
/usr/local/bin/connectshares-config.sh
/usr/local/bin/connectshares.sh

ls -1 /usr/local/bin/disconnect*
/usr/local/bin/disconnectshares
/usr/local/bin/disconnectshares.sh

RC1

Code: Select all

ls -1 /usr/local/bin/connect*
nil
ls -1 /usr/local/bin/disconnect*
nil

SamK · posted: 2013-05-10 12:46

Menu Differences RC1

Except for the root of the main menu, ROX-JWM is fully populated with icons for each subsequent level including the app launcher. In contrast both ROX-IceWM and Space-IceWM have many missing icons in levels following the root level.

By way of example
Start up using ROX-JWM
Navigate to Main menu-->Applications-->Office
Each launcher at this level (mainly Libre Office) has an icon

Repeat the above using ROX-IceWM and ROX-Space
In each case most of the icons are missing

This pattern is repeated for other level 1 and app lauchers. The icons are present for JWM but many are missing for Ice and Space.

BitJam · posted: 2013-05-10 21:35

@SamK, thanks for your help with the eject problem. I have only one guess left for what could be wrong but it will take me some time to implement a possible solution. Have you been able to eject successfully with an antiX-12 LiveCD on this machine?

@everyone: has anyone besides SamK booted an antiX-13-beta3-delta-1 LiveCD? If so, was the LiveCD ejected when the machine shut down?

Dave · posted: 2013-05-11 01:11

SamK wrote:Menu Differences RC1

Except for the root of the main menu, ROX-JWM is fully populated with icons for each subsequent level including the app launcher. In contrast both ROX-IceWM and Space-IceWM have many missing icons in levels following the root level.

By way of example
Start up using ROX-JWM
Navigate to Main menu-->Applications-->Office
Each launcher at this level (mainly Libre Office) has an icon

Repeat the above using ROX-IceWM and ROX-Space
In each case most of the icons are missing

This pattern is repeated for other level 1 and app lauchers. The icons are present for JWM but many are missing for Ice and Space.

Seems to me that the problem is because there are 2 flags for a default icon in /usr/local/bin/auto-icewm-menu.sh where it reads:

Code: Select all

icewm-xdg-menu --terminal 'roxterm -e %s' --default-entry-icon --default-entry-icon /usr/share/icons/gTangish-2.0a1/32x32/apps/preferences-desktop-theme.png --with-theme-paths --theme gTangish-2.0a1 --entire-menu > ~/.icewm/application

and it should read

Code: Select all

icewm-xdg-menu --terminal 'roxterm -e %s' --default-entry-icon /usr/share/icons/gTangish-2.0a1/32x32/apps/preferences-desktop-theme.png --with-theme-paths --theme gTangish-2.0a1 --entire-menu > ~/.icewm/application

BitJam · posted: 2013-05-11 03:01

I think I fixed the eject problem at shutdown. The culprit was the busybox version of eject. It works on some systems (such as my development system) but not on other systems such as antiX-13 in vbox. I'm now using the standard eject program which required me to copy and update libraries in the initrd. This might also affect systems that keep persistence files on ntfs partitions.

I've attached an xdelta3 file and an initrd.gz file since only the initrd.gz has changed. If you are using a LiveUSB then copy antiX-13-beta-3-delta2-initrd.gz to /antiX/initrd.gz on the LiveUSB. For example if the LiveUSB is running then copy it to /live/boot-dev/antiX/initrd.gz.

edit: This is not 100% true: The initrd.gz file will work with both 32-bit and 64-bit systems. It will work on most 64-bit systems but not all.

I've also attached a gzipped xdelta3 file to update antiX-13-beta3 32-bit iso files that have already had the first delta3 patch applied. gunzip the new delta file and then run:

Code: Select all

xdelta3 -d -s antiX-13-beta3-rc1_386-full.iso b3-RC1_to_RC2_386_delta antiX-13-beta3-rc2_386-full.iso

Of course you can name the iso files whatever you want.

One way to make sure you are using the RC2 version is to use the uverb=8 boot parameter. This will cause colorful and verbose output during shutdown and the eject command will also run in verbose mode so you will see output that looks something like this:

Code: Select all

eject-orig: device name is `/dev/sr0'
eject-orig: expanded name is `/dev/sr0'
eject-orig: `/dev/sr0' is not mounted
eject-orig: `/dev/sr0' is not a mount point
eject-orig: `/dev/sr0' is not a multipartition device
eject-orig: trying to eject `/dev/sr0' using CD-ROM eject command
eject-orig: CD-ROM eject command succeeded

Here is the md5sum of the iso that should be created:

Code: Select all

e267d073c8d9de6c886aa5262c4d2f81

I suggest you only bother with this update if you want to test the eject at shutdown feature. PLMK if you need a 64-bit xdelta3 file.

edit: Added correction about the initrd working fine on all 64-bit systems.

SamK · posted: 2013-05-12 08:22

BitJam wrote:I think I fixed the eject problem at shutdown. The culprit was the busybox version of eject. It works on some systems (such as my development system) but not on other systems such as antiX-13 in vbox. I'm now using the standard eject program...

In various distros I have encountered inconsistent operation of busybox eject applet. It cannot be relied upon. Replacing it with the standard eject app has generally produced the expected operation.

BitJam wrote:I've also attached a gzipped xdelta3 file to update antiX-13-beta3 32-bit iso files that have already had the first delta3 patch applied. gunzip the new delta file and then run:
Code: Select all
xdelta3 -d -s antiX-13-beta3-rc1_386-full.iso b3-RC1_to_RC2_386_delta antiX-13-beta3-rc2_386-full.iso

Reporting success. This has been tested on a range of hardware using single and multiple separate CD/DVD drives. The expected operation was obtained.

BitJam · posted: 2013-05-12 08:55

Thank you SamK for catching the bug and testing the fix.

Eino · posted: 2013-05-12 14:14

I'm running the patched disk on an old antique. Everything is running better than I expected.
This is the machine booted with the default settings.

Code: Select all

System:    Host: antiX1 Kernel: 3.6.11-antix.1-486-smp i686 (32 bit, gcc: 4.7.2) 
           Desktop: IceWM 1.3.7 Distro: antiX-13-rc1_386-full Luddite 4 May 2013
Machine:   System: Gateway product: E-4600 version: 4000725
           Mobo: Intel model: D850GB version: AAA49507-903
           Bios: Intel version: GB85010A.15A.0028.P09.0103091412 date: 03/09/2001
CPU:       Single core Intel Pentium 4 CPU (-UP-) cache: 256 KB flags: (pae sse sse2) bmips: 2793.12 clocked at 1396.560 MHz 
Graphics:  Card: NVIDIA NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] bus-ID: 01:00.0 
           X.Org: 1.12.4 drivers: vesa,nouveau (unloaded: fbdev) Resolution: 1024x768@0.0hz 
           GLX Renderer: N/A GLX Version: N/A Direct Rendering: N/A
Audio:     Card: Ensoniq ES1371 [AudioPCI-97] driver: snd_ens1371 port: df00 bus-ID: 02:0a.0 Sound: ALSA ver: 1.0.25
Network:   Card: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 
           driver: tulip ver: 1.1.15-NAPI port: d800 bus-ID: 02:0b.0
           IF: eth0 state: unknown speed: N/A duplex: N/A mac: <filter>
Drives:    HDD Total Size: 140.1GB (-) 1: id: /dev/sda model: WDC_WD1000BB size: 100.0GB 
           2: id: /dev/sdb model: WDC_WD400BB size: 40.0GB 
Partition: ID: / size: 595M used: 22M (4%) fs: rootfs ID: swap-1 size: 2.30GB used: 0.00GB (0%) fs: swap 
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 64 Uptime: 16 min Memory: 187.6/754.5MB Runlevel: 5 Gcc sys: 4.7.2 
           Client: Shell (bash 4.2.37) inxi: 1.8.45

BitJam · posted: 2013-05-12 22:06

Over on the Mepis forums, Jerry3904 asked about this feature:

Here's one for antiX 13 Final: can you get it to make an automatic relink with wifi after sleep? It would remove a serious annoyance for those who use sleep regularly--as I do.

I would imagine something like this would be done by configuring acpid but I don't know much about it. Does anyone know how to do this?

dolphin_oracle · posted: 2013-05-13 00:53

interestingly, my laptop connects back with wifi without any problems after sleep (suspend). i'm using wicd for the connection management.

BitJam · posted: 2013-05-15 17:30

Thank you all again for all the testing. We are currently planning to label the"F5 Video Mode" bootloader menu as follows:

Code: Select all

Label        Boot Options             Was Previously
----------   ---------------------    --------------
default     ""                       modeset 0
safe        "nomodeset xorgconf"     auto res 1
auto res.   "xres=auto"              modeset 2
very safe   "nomodeset"              default

Some older machines don't work without the"nomodeset" option. The video loses sync. Since most people don't have this problem we are enabling modeset by default because it provides a better experience for machines where it works. The"safe" mode should be used if the video is all scrambled. The"safe" mode also creates a minimal xorg.conf file. The only thing it does is broaden the allowed vertical and horizontal frequencies for the monitor. This could be bad for extremely old CRT monitors. In a few other cases it gives Xorg more flexibility to choose the best (highest) resolution.

The"auto res." entry enables modeset but also builds an xorg.conf that lists possible resolutions starting with the resolution reported by"hwinfo --monitor". On one system that was tested, this allowed a higher maximum resolution.

Finally, the"very safe" mode disables modeset and lets Xorg choose all the defaults (because we don't create an xorg.conf file). Xorg is very conservative about allowed horizontal and vertical frequencies so this can result in low maximum resolution.

For most modern systems it won't make much difference which option you choose. The biggest difference you will notice is if modeset is enabled or not. For older systems where the video gets scrambled when modeset is enabled (which is now the default), one of the safe options should be selected. On a very few systems, you will get better modeset resolution if you select"auto res.".

You can still manually enter the X resolution as in"xres=1600x1200". We removed these entries from the F5 menu because they seemed to be doing more harm than good. We have also made this feature safer. Previously when you set the xres then it was all or nothing. If X couldn't work with the resolution you selected it would not start. We now provide all the"auto res." resolutions as fallbacks. so it should be much safer to set xres=. It should be as safe as selecting"auto res.". Therefore in theory we could have included specific resolutions in the F5 menu. There are two reasons we did not. First, it seems that they are not needed; one of the four new entries should provide the maximum resolution. Second, we would need to provide two entries for each resolution, one for people who need/want modeset and another for people who need to have modeset disabled.