Re: [DNG] net-install troubles [SOLVED]
wow. can't type. the installer ddn't work when the iso was loaded via grub and not the root filesystem on the device. July 1 2020 10:02 PM, "Curtis Maurand via Dng" wrote: Turns out tha the trouble was because i was trying to run the install from a muli-boot usb stick. found another smaller usb stick and dd’d the image to the stick. the install was then successfull. the installer didn’t work whe the is was loaded from grub on the stick. could be a feature or a bug. :-) it is amd64. the install is complete. thanks for your help. —Curtis mailto:cur...@maurand.com (mailto:mailto:cur...@maurand.com) Sent from my iPhone On Jul 1, 2020, at 7:53 PM, Ozi Traveller via Dng wrote: The non-free firmware is here: http://deb.devuan.org/merged/pool/DEBIAN/non-free/f/firmware-nonfree/firmware-linux-nonfree_20190114-2_all.deb (http://deb.devuan.org/merged/pool/DEBIAN/non-free/f/firmware-nonfree/firmware-linux-nonfree_20190114-2_all.deb) On Thu, Jul 2, 2020 at 6:31 AM Hendrik Boom wrote:On Tue, Jun 30, 2020 at 06:20:19PM +, Curtis Maurand via Dng wrote: > Hello, > I'm new to the mailing list, but not new to devuan. I've been running devuan > ascii in production for a couple of years. I really like the product. My > system is so much more stable without systemd and all the bull associated > with Ubuntu. > > I've been trying to use the net-install from a USB stick on a system that > does not have a CD-ROM attacted. It has been a failure. > > Here are the troubles. If any of you have work arounds, I'd be grateful > > first it complains about needing a non-free firmware for the wifi device and > asks for a a non-existant CD. It keeps asking and I keep saying no. It look > for the ISO that is loaded from the USB stick or go out to the network for > the firmware since it asks again after the network loads and configures. > > It asks for a realtek driver for the realtek nic's but they seem to work OK. Sorry. I don't know where to get the nonfree firmware if it isn't on your installation media. Perhaps you are installing in a mode that refuses nonfree anything? I believe there's an option in the installer to allow nonfree firmware. That's an option the Free Software Foundation complains about and refuses to consider Debian and Devuan to be truly free. See if you can find that option. > > When partitioning the disk, It sees the exisiting partitions and > filesystems that are there (Ext4, BTRFS and SWAP). When I go to set > the mount point and whether to use the partition I get the choice of > "Do not use," Ext2, Fat16, and Fat32. No Ext4 or BTRFS which are the > two that i need. Maybe a workaround? Are you planning to install the new system on those Ext4, BTRFS partitions? Or are you going to install it on new partitions and have the eventual installed system use those partitions? If the latter, you could install a minimal system on the partitions it will let you use, and then afterward add the others to the /etc/fstab file. This whole situation puzzles me; I have never had to do this on a new install. I have done things like this on my server, which has had no new installation of Debian/Devuan for over a decade. Create new partitions for new file systems, copy the entire system over, adjust critical files (like /etc/fstab) in the copied system, boot into it and then upgrade. I go through this charade to make sure I have a fallback in case the upgrade fails (it has once -- ran out of disk space in /usr) but it also works when I want to change file systems. But I've never had it on a new install. -- hendrik > > At this point, I have to give up. I'm about to try the Desktop-Live. The > net-install should work and have drivers for Ext4 at least, right? > > Should I install ascii and then do a dist-upgrade? I've done that to a couple > of very lightweight systems (DNS servers) successfully. > > Thanks in advance > Curtis > ___ > Dng mailing list > Dng@lists.dyne.org (mailto:Dng@lists.dyne.org) > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > (https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng) ___ Dng mailing list Dng@lists.dyne.org (mailto:Dng@lists.dyne.org) https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng (https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng) ___ Dng mailing list Dng@lists.dyne.org (mailto:Dng@lists.dyne.org) https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng (https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] terminal paste failure
On Thu, 2 Jul 2020 10:02:05 -0400 Haines Brown wrote: > This morning I find that the wiress mouse can cut and paste between > terminals or nano sessions even with the wired mouse disconnected. > Whether the problem is permanently in the past remains to be seen. Try "reset" in the terminal, sometimes this helps. See "man reset" for more info. -- richard lucassen https://contact.xaq.nl/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] terminal paste failure
On Wed, Jul 01, 2020 at 05:36:05PM -0400, Haines Brown wrote: > Last night for some reason I can no lonter paste text selected in > nano to another nano document with the middle mouse button. It seems > to have failed in the course of the night. > ... > However, an old wired USB mouse does not suffer from the problem. > > Haines Brown This morning I find that the wiress mouse can cut and paste between terminals or nano sessions even with the wired mouse disconnected. Whether the problem is permanently in the past remains to be seen. Haines Brown ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] About amprolla-3
Hi again, On 02/07/20 13:50, aitor_czr wrote: Dear Ralph, On 02/07/20 09:36, Ralph Ronnquist via Dng wrote: aitor_czr wrote on 2/7/20 9:13 pm: Hi again, On 02/07/20 10:42, aitor_czr wrote: for other values of*dist* we would find also other categories like 'contrib' or 'non-free' and also other different architectures ( 'source' 'all' 'i386 and 'amd64' aside) Strictly speaking: the source for each category and, on the other hand, the binaries and the contents for each category and architecture (binary-all, etc...). You understand... All clear. Except your note about '/binary-armhf/Packages.gz' which you said it should be '/Packages.gz' but didn't use it so ... Not used in devuan because devuan (as an universal operating system) uses the whole range of architectures. So..., not used in devuan, but required by devuan derivatives. Indeed, another change concerning to the Contents-*.gz is needed for devuan derivatives. This is due to the fact that devuan has already merged the Contents of debian into its own Contents, so that they are not required anymore by any devuan derivative because it would be redundant[*]. Therefore, i've just defined a new tuple named contents in lib/config.py with values: contents = [ 'devuan, 'debian' ] (for DEVUAN) contents = [ 'X', 'devuan' ] (for X = heads, gnuinos... or whatever you want) Cheers, Aitor. [*] As opposed to the binaries *Packages.gz*, pulled from "http://deb.devuan.org/devuan; -containing only those packages built for devuan and non-existent in debian), the Content-*.gz will be pulled from http://deb.devuan.org/merged;. Or maybe i'm doing also an extra step for the binaries? In any case, the repo "packages.gnuinos.org" is working as expected so far, with one outstanding issue regarding the Contents. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] terminal paste failure
On Wed, Jul 01, 2020 at 05:36:05PM -0400, Haines Brown wrote: > Last night for some reason I can no lonter paste text selected in > nano to another nano document with the middle mouse button. It seems > to have failed in the course of the night. > > I've been running Beowulf ever since the beta. I don't have a desktop > environment but rely on fluxbox for window management. > > The problem affects both root and user. It does not affect selecting > and pasting between GUI applications such aa emacs. It affects both > eterm and mlterm. eTerm puzzles me. I installed xterm, but it runs > eterm. > > Clearing the caches did not help: > > $ xsel -cp && xsel -cs && xsel -cb > > > Selected text shows up in xcliboard, and so the problem seems to be > with pasting. > > I tried Ctl-Shift-c and Ctl-Shift-v without luck. > > I tried Ctl-w to cut a work, but Ctl-y did not paste it. > > I repladed the (wireless) mouse and used it in a different port. > Reconfiguring xserver-xorg and rebooting did not help. > > However, an old wired USB mouse does not suffer from the problem. I had similar problems a few days ago. Suddenly some cut-and-pastes didn't work. In particular, I was unable to cut from emacs or a terminal (I forget which teminal program; it could have been qterminal, xterm, or uxterm) and paste in the URL bar of firefox. It didn't matter whether I used the outline in emacs and paste with middle-click or the edit manu in emacs and the paste menu item on firefox. I wondered whether this might be because of the two somewhat incompatible mechanisms in X versus in a desktop. Sometimes this means one kind of cut doesn't match another kind of paste and I just try again with a different combination. But this time switching kinds didn't hwlp. And some pieces of software try hard to be compatible with both. It can help, but what to do if the two paste buffers have different information? Or maybe I'm off-track here and have some misunderstanding about how the cu/paste mechanisms ineract. There does seem to be some conflict between X and desktops, though. I was baffled. I wrote a note about it to this mailing list and got no reply. I couldn't remember doing any upgrades or other system changes recently. But after I logged out and logged in again (I forget whether I also turned the machine off and on again; I think I didn't), everything was OK. I too use a wireless mouse. I still do not understand what happened. -- hendrik > > > Haines Brown > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] About amprolla-3
Dear Ralph, On 02/07/20 09:36, Ralph Ronnquist via Dng wrote: aitor_czr wrote on 2/7/20 9:13 pm: Hi again, On 02/07/20 10:42, aitor_czr wrote: for other values of*dist* we would find also other categories like 'contrib' or 'non-free' and also other different architectures ( 'source' 'all' 'i386 and 'amd64' aside) Strictly speaking: the source for each category and, on the other hand, the binaries and the contents for each category and architecture (binary-all, etc...). You understand... All clear. Except your note about '/binary-armhf/Packages.gz' which you said it should be '/Packages.gz' but didn't use it so ... Not used in devuan because devuan (as an universal operating system) uses the whole range of architectures. So..., not used in devuan, but required by devuan derivatives. Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] About amprolla-3
aitor_czr wrote on 2/7/20 9:13 pm: > Hi again, > > On 02/07/20 10:42, aitor_czr wrote: >> for other values of *dist* we would find also other categories like >> 'contrib' or 'non-free' and also other different architectures ( >> 'source' 'all' 'i386 and 'amd64' aside) > > Strictly speaking: the source for each category and, on the other hand, > the binaries and the contents for each category and architecture > (binary-all, etc...). You understand... All clear. Except your note about '/binary-armhf/Packages.gz' which you said it should be '/Packages.gz' but didn't use it so ... Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] About amprolla-3
Hi again, On 02/07/20 10:42, aitor_czr wrote: for other values of *dist* we would find also other categories like 'contrib' or 'non-free' and also other different architectures ( 'source' 'all' 'i386 and 'amd64' aside) Strictly speaking: the source for each category and, on the other hand, the binaries and the contents for each category and architecture (binary-all, etc...). You understand... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] About amprolla-3
I rectify:
On 02/07/20 10:42, aitor_czr wrote:
(Note the missing '/' symbol at the begining of the string) and the
code above will stay this way:
if k.endswith('/binary-armhf/Packages.gz'):
for a in arches:
for c in categories:
if a in k and ("/%s/" % c) in k:
urls = (join(url[0], k), join(url[1], k))
tpl.append(urls)
if k.endswith('/binary-armhf/Packages.gz'):
for a in arches:
for c in categories:
if a in k and ("%s/" % c) in k:
urls = (join(url[0], k), join(url[1], k))
tpl.append(urls)
Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] About amprolla-3
Hi all,
Having a look at the code of the amprolla_init.py script:
https://github.com/parazyd/amprolla/blob/master/amprolla_init.py
you'll find the following commented lines 76-81:
# if k.endswith('/binary-armhf/Packages.gz'):
# for a in arches:
# for c in categories:
# if a in k and ("/%s/" % c) in k:
# urls = (join(url[0], k), join(url[1], k))
# tpl.append(urls)
Obviously, they were being tested under an armhf architecture, but they
didn't seem to work since they are commented.
In a more general scope we should replace the first line in order to
complay with the whole list of architectures as follows:
if k.endswith('/Packages.gz'):
At this point, let's clarify that the *release_contents* python
dictionary can take different values within the *for* loop above (see
the line 60),
depending on the value of the *dist* variable (say 'gnuinos', 'devuan'
or 'debian', in my concrete case). For example, for dist='gnuinos' the
instruction
'print(release_contents) should throw something like this:
{
'main/source/Release':
('6ac08b835a4af4612418e2f94e1870e4cff8588e7d76fe88b687f88d49d33905', '129'),
'main/Contents-all.bz2':
('4e1468a9098c25653df085b47e8a07883a9d7eff8fa8d72ce2fbd01976557caa',
'86697'),
'main/binary-amd64/Release':
('2940b51273608494b88f6d62ae1381f5a9a9fe82d0a562069b6cb1d91b91e134',
'128'),
'main/debian-installer/binary-amd64/Release':
('2940b51273608494b88f6d62ae1381f5a9a9fe82d0a562069b6cb1d91b91e134',
'128'),
'main/Contents-i386.gz':
('4a668df2a548c96634fb8f5de914f2b097fa4cbce36e2893d218056b1de3afff',
'388221'),
'main/binary-all/Packages.gz':
('8fb999c8c9152e4b74801cbd08cfb205dd405e98734fd63c58ac5ca3d5556497',
'13468'),
'main/debian-installer/binary-i386/Packages.gz':
('4e30cd269b57c46ec94b464f7be8f9f366ed235bce9f4df1be97f6b89c863200',
'15236'),
'main/Contents-i386.bz2':
('c846be19c27d9f65ea741a8b1384efa96669d75a0622aab15a6cc0d531e38964',
'296180'),
'main/debian-installer/binary-i386/Release':
('e80ebfe3fab8b3a7e7e211cf323982110509a8172db4e540c6d651ebb86db9c3',
'127'),
'main/source/Sources.bz2':
('44be781abbc7bd2c457c91cb224232f8c7bb320266c9c318a14c1c595c5c426f',
'27068'),
'main/Contents-i386':
('e552d78bf459de48607f6825ee183afc6cdafce349abe4d708f83c4d47aef3b7',
'5730743'),
'main/source/Sources':
('d42702641f669ea8e148d3c5eb956e5a39d727c9d4de1d56ef0b81cf37e941ab',
'218384'),
'main/binary-i386/Packages.gz':
('98ec7d3c3d761c8ca3e08fdfbc3f0ae5c102362b3f6cec6f73e2be06e9c985d9',
'66641'),
'main/source/Sources.gz':
('011c2edae24ffeb414df8562293a869ceaa16fd9568bfcd19e9fbfa3de75dc7a',
'35398'),
'main/debian-installer/binary-all/Packages':
('483bdbf818dba2d97562cca9de4622f53b31abe8a64716b19731f288efd877cb',
'726'),
'main/Contents-all':
('cf80c86286974b8d944da5b7f552890b9f8a4b41aacd792093d28fed9eeaf7b6',
'1275824'),
'main/binary-amd64/Packages.gz':
('cde0dc0180b806e33ec015a23cdce7252be77bcec93237dc8d6aa81298686dd0',
'64478'),
'main/Contents-all.gz':
('e80d7fc7fb34445796a1ea59c053266d3157ed6db2f20af472e76e4ea07a550c',
'104332'),
'main/debian-installer/binary-amd64/Packages':
('1017fac3c3b3703737124b3330e9d62b04eb1f21afd9a617eec8759a5d09b455',
'41675'),
'main/debian-installer/binary-all/Release':
('aeda45f8528299e45bd726306a20aef04175b8a76cfbb4aebde09fff38647407',
'126'),
'main/binary-i386/Release':
('e80ebfe3fab8b3a7e7e211cf323982110509a8172db4e540c6d651ebb86db9c3',
'127'),
'main/debian-installer/binary-all/Packages.gz':
('bf18c4b295e4b2f416ab6f24ac079c7d1d83e47fde316b950c31b44a576aba41',
'481'),
'main/Contents-amd64.bz2':
('f820fbf1fcbdf53cabf32a9a75a199a4e0e05e41f08834f6f9d5ee673064c7e4',
'262172'),
'main/debian-installer/binary-amd64/Packages.gz':
('ff9fd291958c79c71c1ba27f1591f894d8293025b30ad8f28157c93a0551ba6f',
'9004'),
'main/binary-i386/Packages':
('04d563842c9d921e79e98c00b459632ee5e75b3b6fa05366f93d0c31204b20bc',
'285503'),
'main/debian-installer/binary-i386/Packages':
('5fb434475ab503ea25b9eccfb982544308742a93d0d0474efdcc16de21552b78',
'80531'),
'main/Contents-amd64.gz':
('34b71529f439275b98cd8b7c7ace9bb16d2dfd653f81609a58c108ae39c35080',
'320050'),
'main/binary-all/Packages':
('61ff4f5097b9649507538657f42999212c0c6d108a9d15b600f1f5d17db43bb8',
'43601'),
'main/binary-all/Release':
('aeda45f8528299e45bd726306a20aef04175b8a76cfbb4aebde09fff38647407',
'126'),
'main/binary-amd64/Packages':
('382aa290f73ba0b9852d36e419f02915bc77a6647b59cfca3263a2d846a0056d',
'276479'),
'main/Contents-amd64':
('8e4d1ddb1891450a13414e35d2195bee79183670094a3e2e269b0511c6c1dfd3',
'4379342')
}
for other values of *dist* we would find also other categories like
'contrib' or 'non-free' and also other different architectures (
'source' 'all' 'i386 and 'amd64' aside)
getting lines like this other one:
'non-free/debian-installer/binary-hppa/Packages.xz':
('0040f94d11d0039505328a90b2ff48968db873e9e7967307631bf40ef5679275', '32'),
This said, and coming back to the commented lines in the
amprolla_init.py script, you'll understand
Re: [DNG] Non-systemd Linux for older hardware (was: Devuan Jessie End of Life (EOL) archiving)
On Wed, Jul 01, 2020 at 02:36:23PM -0400, Hendrik Boom wrote: > On Wed, Jul 01, 2020 at 08:18:37PM +0200, Martin Steigerwald wrote: > > Unless it is not just the kernel but also glibc or something somehow not > > working on older hardware. > > It may well be that the newer hardware has machine instructions not > available on older hardware, and that the compilers that generate > packaged code use those machine instructions; in which case the new > packages would be quite incomatible with the old hardware. glibc, and probably many individual programs as well; gcc defaults have been changed to produce i686 instructions so you'd need to rebuild world to get i586 or i486 back. The question remains, why? For driving that medical scanner/CNC machine you're much better off running software from that era instead of risking regressions. For any other use, you're in Amiga/etc land, and it's a matter of hobby rather than productively "using old 'still good' hardware". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
