Re: [DNG] Booting devuan on a rasberry pi
Hello Again.. " [0.912573] sdhost-bcm2835 20202000.mmc: could not get clk, deferring probe " Does you have any problems with your sdcard? Shutdown and clean the contacts, then insert it again boot, and wait some time, to check if it will resize disk partition to mazx size.. Or if mmc clock is lower, it will take a lot more time to load.. > Hello, > Were is your > > > Hi, > > I'm trying to boot a Raspberry PI B+ on devuan_ascii_2.0.0_armhf_raspi2.img > > > > I'm getting a boot loop with this output: https://pastebin.com/ALTzdJxW > > Any thoughts? > > > > Should I be using the raspi1 image instead? > > What is your RaspberryPi version? > > In the logs I see: > " > [2.014566] Waiting for root device /dev/mmcblk0p2... > " > > Does you waited enough time? > I don' know that image, > But some do a resize of /dev/mmcblk0p2( and that could take some time.. ) > > -- > s@po -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Booting devuan on a rasberry pi
Hello, Were is your > Hi, > I'm trying to boot a Raspberry PI B+ on devuan_ascii_2.0.0_armhf_raspi2.img > > I'm getting a boot loop with this output: https://pastebin.com/ALTzdJxW > Any thoughts? > > Should I be using the raspi1 image instead? What is your RaspberryPi version? In the logs I see: " [2.014566] Waiting for root device /dev/mmcblk0p2... " Does you waited enough time? I don' know that image, But some do a resize of /dev/mmcblk0p2( and that could take some time.. ) -- s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Booting devuan on a rasberry pi
Hi, I'm trying to boot a Raspberry PI B+ on devuan_ascii_2.0.0_armhf_raspi2.img I'm getting a boot loop with this output: https://pastebin.com/ALTzdJxW Any thoughts? Should I be using the raspi1 image instead? Thanks ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Raspberry Pi 4 (Brad Campbell)
On 7/6/19 5:17 AM, dng-requ...@lists.dyne.org wrote: Message: 5 Date: Sat, 6 Jul 2019 16:22:33 +0800 From: Brad Campbell To:dng@lists.dyne.org Subject: [DNG] Raspberry Pi 4 Message-ID:<9d5f2187-0575-650b-29f9-0d1e226cd...@fnarfbargle.com> Content-Type: text/plain; charset=utf-8; format=flowed G'day all, I have an old RPI3 running Jessie that I wanted to replace with a 4 (wanted USB3 & GbE) Not wanting to re-configure or re-install I downloaded the latest Raspbian for the Pi4 (Buster) to use for parts. I replaced the boot partition contents straight from the Buster image. Had to edit cmdline text to alter the root parameter "root=/dev/mmcblk0p2". Then I simply rsynced /lib/modules and /lib/firmware across to the root partition (adding not replacing). It booted right up with USB, net and console functional and I was back in business on the new hardware. I don't use the GPU except for initial bringup, nor wlan or bluetooth. So I can't vouch for those, although udev certainly detects the wlan. The config.txt lines to disable wlan & bt still work also : dtoverlay=pi3-disable-bt dtoverlay=pi3-disable-wifi Regards, Brad I tried what you've described --- put a fresh copy of "devuan_ascii_2.0.0_arm64_raspi3.img" on an 8GB microSD card, then copied the parts of Raspbian Buster over; but I end up with an error "/sbin/init exists, but is not executable (error -8)", possibly suggesting that there is a mismatch between 32-bit boot code and 64-bit /sbin/init. Did you make any other changes? -- -Robert Montante, Ph.D. Department of Mathematical and Digital Sciences Bloomsburg Universitybobmon AT bloomu DOT edu Bloomsburg, PA 17815prof.montante AT gmail DOT com phone: 570-389-4624 montcs.bloomu.edu/~bobmon/ -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
On Sat, 06 Jul 2019 08:49:52 +0200 Martin Steigerwald wrote: > Steve Litt - 06.07.19, 07:24: > > > It is not > > > difficult to think of the day when Debian will remove completely > > > sysvinit script in all packages. > > > > Pre-Cisely! > > I would not bet on that. Depends on the odds. Obviously nobody without a time machine or crystal ball knows for sure. You prioritize the existence and activities of the debian-init-diversity group. I prioritize the profit motive of complexifying GNU/Linux, as well as some former bad acts of the Debian project being a pattern for their future activity. > > There is the debian-init-diversity group where Debian and Devuan > people work together. Back then I helped to bring that forward and > there is still a lot of activity. Thank you for that. Regardless of the final outcome, you did something important in undoing the savage mistakes of late 2014. A lot of people talk: You did something, and the something you did might benefit all of us. > Developers in that group did > updates for sysvinit, insserv, startpar, openrc, runit and others for > Debian which then could be and have been used in Devuan. At the same > time there is a new upstream maintainer for sysvinit, insserv and > startpar so these are all actively developed. These developers closed > a ton of sysvinit related bug reports in Debian. It's amazing. In > fact the upstream developer even dug through Debian bug tracker to > find bugs to fix. [snip sysvinit, insserv and startpar bug fixes] My feeling that sysvinit is not in safe hands in the Debian project isn't based on the quality of sysvinit or its components. As a matter of fact, I never noticed any bugs or weird stuff with sysvinit during the 13 years I used sysvinit as my daily driver init (with occasional forays into upstart and daemontools). My feeling is based on: 1) Corporate profit motive for keeping systemd the only init in town. 2) The (insert your own noun epithet) of "FreeDesktop.Org". 3) Systemd's technological ability to sabotage all attempts at alt-initting a computer. 4) The huge moving-target workload necessary because of #3. 5) See the response to your next statement... > While Debian project for now will keep the libsystemd0 dependency on > a lot of packages Which makes libsystemd0 the ideal kill switch for init diversity. One might ask who would be so mean as to kill init diversity within Debian? For a list of such people, see the original decision: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 > that not absolutely need it and regarding init > diversity there is a place for Devuan to go further, there are Debian > developers who strongly prefer to use sysvinit and who prefer to > avoid Systemd. It's completely understandable that some people like sysvinit. [snip highly successful case history of migration to Devuan with sysvinit] > That kind of inspired the user-services project I did not work on > after that again. I more and more believe it would be good to package > that stuff in a way that it would work out of the box for users. Or… > well to do some post package processing to make it work. For a distro like Debian or Devuan, "works out of the box for users" is almost a necessity, in the long run. When I recommend a series of steps to accomplish something, it's for the early adopters. > Of course it is likely at some time some may bring up that topic and > there would be a discussion, but… assuming from the past, that > discussion would take a time to come to an conclusion. So I believe > the risk that all Debian developers would *suddenly* drop init > scripts from packages is quite low. There would be at least a > considerable forewarning time. > > That said, I agree it would be good to find a way to inject runit > symlinks into packages, cause I believe it to be unlikely that many > Debian package maintainers would include runit support. Pre-cisely! Runit /etc/sv directories and any symlink strategy can be implemented by people who care about runit. Same for s6, OpenRC, Epoch, etc. I don't think developers of daemons ever should have been tasked with making scripts or unit files for *any* init. > However that > said, I would. > > So: If you like to provide runit support for fio Debian package, > please go ahead. As long as the runit support is implemented in a way > that the existing start support for sysvinit – which I implemented > back then – and systemd still works as well, and you tested the runit > support, I gladly accept a merge request. I'd even make some effort > to put it into the package itself, in case you provide something to > me, in case you are not familiar with forking a git repo and > providing a merge request. I can't think of anything I or anyone could do, regarding runit runscripts, that would adversely affect sysvinit. As far as systemd, runit and s6 are never going to use the systemd mechanism by which service A tells systemd that it's loaded, but if som
Re: [DNG] Runit service depend another script not daemon
il devuanizzato Steve Litt il 06-07-19 07:24:37 ha
scritto:
Instead it's possible
inject in all daemon's install a piece of posix shell?
Workaround script on event "DPkg::Post-Invoke" as I said in the
previous email?
You know much more than I do about packaging. Given something like
event "DPkg::Post-Invoke", all it would need to do is call a
shellscript, with the argument of the daemon name, and the shellscript
could make the necessary symlinks or whatever. All the heavy lifting
would still be done in the runit-runscripts package.
Put my code here.
Work for epoch init system but it is adaptable to any other such as
runit, s6 and so on...
Run script on event Pre-Invoke and Post-Invoke:
#/etc/apt/apt.conf.d/99_dpkg_init_script
DPkg::Pre-Invoke { "/usr/local/bin/dpkg_init_script 1"; };
DPkg::Post-Invoke { "/usr/local/bin/dpkg_init_script 2"; };
The script (it should run for apt, apt-get, aptitude invoke and so on...):
#!/bin/sh
#/usr/local/bin/dpkg_init_script
HIGH_EVID="\033[31m"
HIGH_NORM="\033[0m"
MOD_INSTALL=1
MOD_REMOVE=2
MOD_PURGE=3
# Scan command line and find command
command()
{
if [ "$#" -eq "1" ]; then
CMD=$1
if [ "$CMD" = "install" ]; then
return $MOD_INSTALL
elif [ "$CMD" = "remove" ]; then
return $MOD_REMOVE
elif [ "$CMD" = "purge" ]; then
return $MOD_PURGE
else
return 0
fi
return 0
else
return 0
fi
}
# Epoch init system install/remove
epoch()
{
if [ "$#" -eq "2" ]; then
ACTION=$1
PACKAGE=$2
INIT_EPOCH_BIN="/usr/local/sbin/epoch"
INIT_EPOCH_ETC="/etc/epoch/epoch.conf"
INIT_EPOCH_PKG_DIR="/etc/epoch/object/"
INIT_EPOCH_PKG_DIRESC="\/etc\/epoch\/object\/"
INIT_EPOCH_PKG_REP="/etc/epoch/repo/"
# If not present epoch do not do nothing
if [ -x "$INIT_EPOCH_BIN" -a -f "$INIT_EPOCH_ETC" -a -d "$INIT_EPOCH_PKG_DIR" -a -d
"$INIT_EPOCH_PKG_REP" -a -f "$INIT_EPOCH_PKG_REP$PACKAGE.conf" ]; then
if [ "$ACTION" -eq "$MOD_INSTALL" ]; then
echo cp $INIT_EPOCH_PKG_REP$PACKAGE.conf
$INIT_EPOCH_PKG_DIR$PACKAGE.conf
cp $INIT_EPOCH_PKG_REP$PACKAGE.conf
$INIT_EPOCH_PKG_DIR$PACKAGE.conf
echo sed -i "\$aImport
$INIT_EPOCH_PKG_DIR$PACKAGE.conf" $INIT_EPOCH_ETC
sed -i "\$aImport
$INIT_EPOCH_PKG_DIR$PACKAGE.conf" $INIT_EPOCH_ETC
elif [ "$ACTION" -eq "$MOD_REMOVE" -o "$ACTION" -eq
"$MOD_PURGE" ]; then
echo rm $INIT_EPOCH_PKG_DIR$PACKAGE.conf
rm $INIT_EPOCH_PKG_DIR$PACKAGE.conf
echo sed -i "/Import
$INIT_EPOCH_PKG_DIRESC$PACKAGE.conf/d" $INIT_EPOCH_ETC
sed -i "/Import
$INIT_EPOCH_PKG_DIRESC$PACKAGE.conf/d" $INIT_EPOCH_ETC
fi
fi
fi
}
if [ "$#" -eq "1" ]; then
DPKG_PHASE=$1
else
echo "arg err"
exit
fi
APTPID=$( ps -ho ppid "${PPID}" | sed 's/^ *//' | sed 's/ *$//' )
APTCMD=$( ps -ho args "${APTPID}" | sed 's/^ *//' | sed 's/ *$//' )
VAR=$APTCMD
while test -n "$VAR" ; do
IFS=' ' read -r VAR ALL <<- XXX
$VAR
XXX
command $VAR
ACTION=$?
if [ "$ACTION" -ne "0" ]; then
VAR=$ALL
break;
fi
VAR=$ALL
done
EXDPKG=`dpkg-query -W -f='${binary:Package}\t${db:Status-Abbrev}\n' $ALL
2>/dev/null`
echo exdpkg: $EXDPKG
if [ "$DPKG_PHASE" -eq "1" ]; then
printf "${HIGH_EVID}Pre-invoke${HIGH_NORM}\n"
#printf "%s\n" $EXDPKG |
dpkg-query -W -f='${binary:Package}\t${db:Status-Abbrev}\n' $ALL
2>/dev/null |
while read PACKAGE STATUS
do
printf "${HIGH_EVID}Package %s Status %s${HIGH_NORM}\n"
$PACKAGE $STATUS
if [ "$ACTION" -eq "$MOD_REMOVE" -o "$ACTION" -eq "$MOD_PURGE"
]; then
if [ "$STATUS" = "ii" -o "$STATUS" = "ri" -o "$STATUS" =
"pi" ]; then
# If exists package, is remove command and
package is installed, remove script
# aptitude return "pi" instead of "ii", remove
alike
printf "${HIGH_EVID}Remove
script${HIGH_NORM}\n" $PACKAGE $STATUS
# Epoch init system
epoch $ACTION $PACKAGE
Re: [DNG] UEFI support in the live-sdk
On 7/6/19 7:16 AM, aitor_czr wrote: First of all, are you using the latest sources: $ git clone https://git.devuan.org/aitor_czr/live-sdk.git No, I'm using the copy I cloned at the end of May. It worked for me then; I did not change anything, so I expect it should work now. On the other hand, i must admit that i didn't update the repository of gnuinos during weeks; so, it couldn't work. did you select this choice? I selected Devuan, stable, main. Same as last time. Today I tried changing the mirror from deb.devuan.org to pkgmaster.devuan.org but it didn't make any difference. It pulls down Packages.gz and then stops. --2019-07-06 12:28:41-- http://pkgmaster.devuan.org/merged/dists/ascii/main/debian-installer/binary-amd64/Packages.gz Resolving pkgmaster.devuan.org (pkgmaster.devuan.org)... 5.196.38.18 Connecting to pkgmaster.devuan.org (pkgmaster.devuan.org)|5.196.38.18|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 62636 (61K) [text/plain] Saving to: ‘Packages.gz’ Packages.gz 100%[===>] 61.17K 246KB/sin 0.2s 2019-07-06 12:28:42 (246 KB/s) - ‘Packages.gz’ saved [62636/62636] . libdevuansdk v1.0 loaded . devuan blend leaded livesdk@ascii % fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI support in the live-sdk
Hi fsmithred,
On 5/7/19 22:46, fsmithred via Dng wrote:
On 5/30/19 4:54 PM, aitor_czr wrote:
Hi fsmithred,
On 30/5/19 15:30, fsmithred via Dng wrote:
Reboot into the system looks good. It installed the full system from
the iso (without network)
:) :) :)
Now I have to look at it and figure out what you did.
fsmithred
All these changes have been commited in the git repository. I'll
build another image during this night...
Thanks a lot for your help, fsmithred :)
Cheers,
Aitor.
I'm just getting back to this now. I tried running it again without
making any changes. Ran the following commands including the trivial
steps to select repo, suite, etc. and it did not build.
# zsh -f
# source sdk
# load
the following steps are trivial. You can choose between the
repository of devuan or gnuinos (a fully amprolla setup). Debian is a
work in progress.
After the dialog, it just dumped me back to the zsh prompt. What am I
missing? I tried build_iso_dist and it said "command not found."
Thanks,
fsmithred
First of all, are you using the latest sources:
$ git clone https://git.devuan.org/aitor_czr/live-sdk.git
On the other hand, i must admit that i didn't update the repository of
gnuinos during weeks; so, it couldn't work. did you select this choice?
I've just updated the repository today with amprolla and the live-sdk is
working for me. Sorry, but i'm focused on simple-netaid these days, and
i want to finish it over the course of july.
I did a lot of improvements. One of them is the unlimited size of the
buffer shared by the server and the client sides of the unix socket (the
shared information between the backend and the frontend).
This unlimited size of the buffer is possible thanks to the sbuf structs
whose lifecycle is:
struct sbuf s;
sbuf_init(&s);
sbuf_addch(&s, 'F'); /** add a character **/
sbuf_addstr(&s, str); /** add a string **/
printf("%s\n", s.buf);
free(s.buf); /** free the memory **/
But this is not my job... I took the idea from another project (by a
developer of bunsenlabs -Johan Malm- together with one of the main
developers of the tint2 panel):
https://github.com/johanmalm/jgmenu
I always beat around the bush :)
Cheers,
Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Raspberry Pi 4
G'day all, I have an old RPI3 running Jessie that I wanted to replace with a 4 (wanted USB3 & GbE) Not wanting to re-configure or re-install I downloaded the latest Raspbian for the Pi4 (Buster) to use for parts. I replaced the boot partition contents straight from the Buster image. Had to edit cmdline text to alter the root parameter "root=/dev/mmcblk0p2". Then I simply rsynced /lib/modules and /lib/firmware across to the root partition (adding not replacing). It booted right up with USB, net and console functional and I was back in business on the new hardware. I don't use the GPU except for initial bringup, nor wlan or bluetooth. So I can't vouch for those, although udev certainly detects the wlan. The config.txt lines to disable wlan & bt still work also : dtoverlay=pi3-disable-bt dtoverlay=pi3-disable-wifi Regards, Brad ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
