You are not logged in.
Hello:
OK, reboot into rescue mode, then fire up aptitude:
aptitude
Ok.
I started there and saw that x11-xkb-tools was not installed.
Assuming x11-xkb-tools should be there (and maybe other missing configuration files) and that an update would install whatever was needed, I exited aptitude and decided to try apt-get update.
I first checked that the /etc/apt/sources.list was this one and that everything else was remmed out:
deb http://pkgmaster.devuan.org/merged ascii main
deb http://pkgmaster.devuan.org/merged ascii-updates main
deb http://pkgmaster.devuan.org/merged ascii-security main
deb http://pkgmaster.devuan.org/merged ascii-backports main
Then I did apt-get update and got a warning about dpkg having been interrupted which got fixed with the instructions on the screen with ...
dpkg --configure -a
... and then ran apt-get update again.
It started to do its work but complained about /etc/pam.d/login having been modified and asking about which version to keep.
I guessed that that could have been the glitch that affected my kb/mouse (?) so I kept the existing script version (default option) and continued.
If that one did not work, I could try the new version which obviously was not an option if I accepted the new one from the start.
When it was done (it was a lot) I exited, rebooted and got my desktop, this time with working kb and mouse. =^ )
Once there, I started SPM and updated everything again.
Then for safe measure, I did the same through apt.
Now, it seems everything is well again:
root@devuan:/home/groucho# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@devuan:/home/groucho#
root@devuan:/home/groucho# uname -a
Linux devuan 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux
root@devuan:/home/groucho#
groucho@devuan:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Devuan
Description: Devuan GNU/Linux 2.0 (ascii)
Release: 2.0
Codename: ascii
groucho@devuan:~$
A big thank you to all of those who pitched in to help.
Really appreciated your input.
That said, it I think I have to brush up and deepen my command line skills.
Best,
A.
Hello:
OK, reboot into rescue mode, then fire up aptitude:
aptitude
Ok.
Use the / key to bring up a search box and find the package x11-xkb-tools. If it has an i in front, it's installed. If that's the case, purge it (Shift+-) then re-install the package. It'll probably throw up a bunch of errors when purging, remove all packages that rely on it too (they'll be re-installed when you install the package)
Ok.
One question ...
Purging the packages will require downloading them again?
If so, will the wireless network be up when I log into rescue mode?
Could this be done with a live Jesse or Ascii CD?
HTH!
Hopefully ... 8^)
Thanks for your input.
A.
Hello:
How about reading those ASCII release notes?
I have read them.
But have not been able to identify anything specific that would help me solve this.
At least not with my level of exposure to Linux.
Perhaps you could point out anything I may have (surely) missed?
Thanks in advance.
A.
Hello:
It looks like your X is having some Problem either with this USB device or with USB in general.
That's one possibility that has come to mind.
* can you try another USB keyboard?
The keyboard is the same I use in the same box that other OSs run in, just on different disks.
Works perfectly well.
* can you try a PS2 keyboard?
Nope ...
My box does not have a PS2 port. =-'
* can you have a close look into /var/log/Xorg.0.log ? If nothing springs to your eye make it available to us?
I've had a look ...
I'll post it tomorrow morning.
* do you have an /etc/X11/xorg.conf or other config files as referenced from /var/log/Xorg.0.log ? If yes make it/them available, too...
When I installed Devuan Jesse I had to install the non-free Nvidia drivers to make my two Nvidia cards drive the three monitors.
If I recall correctly, I tried using the same xorg.conf file I was using with PCLinuxOS which worked.
I'll check and see if that is as I remember and then post it along with the log.
Thanks a lot for your input.
A.
Hello:
Hello:
I was able to start X, got the full desktop but still no Kb or mouse (it's plugged into the USB Kb).
So the problem persists. =^/
Anyone?
I tried using a different mouse directly connected to a USB port (instead of a PS2 connected to a port on the Kb) but still no dice.
Is there any way I can get out of this problem without having to do a full reinstall?
That's the MS way out...
I was wondering about using a live Jese/Ascii *.iso to boot and do an update to see if that fixes anything or change repos to Jesse and then do an update to see if I can get to where I started from ie: a healthy and perfectly working Jesse installtion 8^/.
Or try to do the same things from the terminal, but I'd need some instructions.
Thanks in advance.
A.
Hello:
... have an entry for booting into runlevel 1 in your GRUB boot menu as well.
I'll have a look - never had to use it before.
... might want to do yourself the favor of reading the section on "Starting X from a console (TTY)" in the ASCII release notes before you use startx to start X.
Too late ... 8^D LoL
I was able to start X, got the full desktop but still no Kb or mouse (it's plugged into the USB Kb).
So the problem persists. =^/
Thanks for your input.
A.
Hello:
... try narrowing the problem down. I'd try disabling slim ...
... if your keyboard works after a normal boot.
If it does try startx. If it still works clearly slim is the culprit.
I did as you suggested.
I was able to start the X server and got my full desktop across the three monitors (so it would seem that it is not a Nvidia non-free driver issue) but the Kb was as unresponsive as before.
I have a gut feeling (?) that this is something related to Xorg.conf.
Any suggestions will be appreciated.
Thanks for your input.
A.
Hello:
I'll try it and report back on how the Kb behaves.
I did as per your instrucions and was able to log into recovery mode, with what would seem to be a fully working keyboard.
So I suspect there is an issue with SLiM, maybe caused by something else (?) eg: XOrg conf, Nvidia drivers ...
I guess I may be able to find a clue to whatever is happening in dmesg or one of the log files.
I'll have a look - any suggestions are welcome.
Thanks in advance.
A.
Hello:
When the GRUB menu shows up, select Devuan, but don't hit Return. Type e instead. Now you should see a bunch of text containing a line somewhere reading somehting like:
linux /vmlinuz-4.9.0-6-686-pae root=UUID=810cd705-55b6-4ce2-a414-76e16ce125f4 ro quiet
... navigate to the end of that line, then insert 1. Then hit F10 to boot.
... process should pause at a certain point and you should be asked to enter your root password ...
... are in 1 or "recovery mode".
You won't have to change that GRUB configuration back because it's not permanent.
OK.
Thanks a lot. 8^)
In contrast to what I was used to with MS OSs, I've never had to do go to recovery mode with my Linux installations.
It's actually the first time.
I'll try it and report back on how the Kb behaves.
What do you mean by "upgrade"?
This:
https://devuan.org/os/documentation/dev … e-to-ascii
"This document shows how to upgrade from Devuan Jessie to Devuan Ascii. It assumes a working Devuan Jessie system is already installed and should not be used for migrations."
Thanks for your input.
A.
Hello:
Have you read the Release notes?
Yes, didn't see anything which would raise a flag.
But I'm not that proficient Linux-wise ... 8^/
I suspect something is amiss with the backend combo needed for your setup.
It has the default SLiM and XFCE combination.
Is anything else missing?
What was in Jesse was working without any problems so I expected that if anything was missing, it would either get installed or reconfigured.
I'm not complaining but as it is a default Jesse (SLiM and XFCE) installation upgrade I expected no major hickups save maybe the Nvidia drivers acting up.
Thanks for your input.
A.
Hello:
Does the keyboard respond when you boot the system in recovery mode?
I boot devuan from the grub in my PCLinuxOS setup.
ie: the default boot is PCLinux, the second options in the list is Devuan (for the time being, till things smooth out)
Can't see how to get into recovery mode, the keyboard is not responsive.
What login manager are you trying to use?
My Devuan installation is the *default* Jesse using SLiM and XFCE.
Thanks for your input.
A.
Hello:
Not sure if i can help much ...
No problem, thanks you for answering. =-)
At what point the keyboard doesn't respond?
At the very start, when the login manager shows up.
Can you still login to a text console?
As the keyboard is non responsive, F1 or any other input is not an option.
Also what kind of keyboard is it?
Same as I was using with Jesse, same as the one I use with PCLinux, all the same rig just on different drives for each.
Does it maybe need some non-free package ...
No ...
It's a (ancient to some) very sturdy and dependable Wise USB keyboard salvaged from somewhere when I got my (also ancient to some) Sun workstation.
Has a PS2 plug on the side for the Wise optical mouse.
It all worked perfectly well with Jesse from the out-of-the-box install.
The only non-free I needed to install in Jesse were the drivers for my two Nvidia cards (I use three monitors).
No way the Devuan free drivers would work.
Maybe that's the catch - but I *do* see all three monitors lioke before, it's just the kb that does not respond.
Thanks for your input.
A.
Hello:
Thinking everything would be fine ie: being stable and all, I followed the instructions here:
https://devuan.org/os/documentation/dev … e-to-ascii
Everything went smoothly, did not see any warnings.
Now, on reboot, I am completely locked out of my Devuan rig. (writing from my PCLinuxOS drive) as the keyboard does not respond as it is not active (no leds light up), so there's no F1 or anything else.
Short of doing the old MS trick (ie: reinstall from CD), is there a way out of this situation?
Thanks in advance.
A.
Hello:
... was the perfect solution,
Thank you very much !!!
You're welcome ...
But the merit goes to the guy who found this 'workaround' ...
Unfortunately, it is not a solution.
It's a bug that won't get fixed.
And from what I have found, there does not seem to be an Xfce 4.12 jessie-backport in sight.
Cheers,
A.
Hello:
Now, that would mean booting up the live *.iso, upgrading and changing everything I need to change while up ...
Yes, of course!
Look at /etc/refractasnapshot.conf and set the work_dir and snapshot_dir to someplace that has enough space to hold a copy of the filesystem plus the new iso.
OK, I had not thought of that important detail.
... don't even need the iso. You can copy $work_dir/iso/live/* to the live folder on the sd card rather than extract them from the finished iso.
OK.
I'll post the results as soon as I get it up and running.
Best,
A.
Hello:
First of all, thank you for taking the time to write this up. =-)
You tried to update a live system. Ouch.
Indeed ... 8^\'/!
It can be done, but understand what's going on.
Which I quite evidently did not.
If you set it up for full persistence, then any changes or additions get stored on the persistent partition, in their normal location (i.e. full path). That persistent file system gets overlaid on the read-only live system.
OK
So anything you changed did not make any changes in the live system on the first partition.
Right.
I had it more or less clear up to that point.
... boot without persistence and mount the persistent partition ...
... delete anything that isn't your personal stuff. Then when you reboot with persistence, it will be just like the first time.
Yes.
Done that once already.
If you update the kernel, you'll only be updating the one in /boot in your live system. But the live system gets booted from the kernel in the /live folder in the root of the iso (or device). The kernel in /boot only gets used after a normal installation. Same is true for the initrd.
I see ... (but still have to digest 100% ... )
... copy those from /boot to /live and name them to match what's there (and what's in your boot menu).
OK.
... the source of your wifi problems. Another possibility is if your update switched you from udev to eudev and the network interface names changed. Check the interface names with 'ifconfig' or 'ip a' and make sure that wicd is using the right name. (little triangle in upper right will get you to preferences in wicd)
I'm starting to get the idea behind the 'ouch'.
One more catch - the first partition is read-only during a live session. So either plug the sd card into another system to mount it and copy the files or use an undocumented trick to copy the files. Since jessie, if you run with persistence, your root user will be able to write to the first partition. In fact, you don't even need a persistent volume to do this - you just need the word, persistence, in the boot command. When you do this, you might notice (hint: look!) that the first partition is mounted at /lib/live/mount/persistence/ instead of /lib/live/mount/medium/.
I'll have a look there ...
Last bit of advice - full persistence is nice for saving files and making some config changes.
Indeed ...
But no big stuff. As it gets stuffed.
When you start running updates or adding software, you're filling up your space, and you're making less of your system read-only (aka - unhackable).
I understand.
Like I mentioned earlier, this is a dedicated persistent install for running a dedicated application from a netbook.
The princiopal idea is to run lighter than the XP installed in the machine and to run the Linux version of the app, keeping it as far away as possible from the XP instalaltion.
I should have left it alone, but ...
I had the idea that it had to be as 'up to date' as possible but looking back, while it may be a good idea for any running system, in this particular case it does not make much sense. More so after royally buggering it up.
If you want to make big changes like that, you might be better off making a new iso.
Quite so ...
And probably much easier.
Now, that would mean booting up the live *.iso, upgrading and changing everything I need to change while up and then 'refracting' it all into a new iso which will keep all the changes.
Right?
Anything specific I'd have to be aware of when doing this?
You can then copy the contents of that iso to the sd card to replace the files with the updated system. You may or may not need to delete any system files that are on the persistent partition.
OK.
Once again, thank you very much for writing this up.
Best,
A.
Hello:
Here I was very (very) happy with my new Vuu-do Live SD Card installation, having persistence on a second partition (50GB ext4) of a XP netbook's HDD (Asus 1000HE). If you need more details about the setup, it's here:
https://dev1galaxy.org/viewtopic.php?pid=8249#p8249
Everything was just as I wanted it to be and working perfectly.
As I was getting ready to test the dedicated application (coffee roasting software) I'll be running from the netbook, I remembered that I had not updated the installation.
So I went to SPM (Synaptic Package Manager) and made it do it's thing.
Well ...
It did, including a new kernel but unfortunately a couple of things went south:
1.
WiFi (which was working perfectly well) now does not detect any networks.
For the moment this is not a big deal but I do need it to to upload graphs to storage space in my email account.
Lacking a printer, I print them in colour at the office.
2.
My screen resolution went from the pre-existent 1024*600 to 800*400.
This is a problem because it screws up visibility on the app's GUI.
So, I went to see what xandr had to say:
:~$ xrandr
xrandr: Failed to get size of gamma for output default
Screen =: minimum 800 x 600, current 800 x 600, maximum 800 x 600
default connected 800x600+0+0 0mm * 0mm
800x600 61.00*
I went looking for an xorg.conf in /etc/X11 but there is none.
So I downloaded and installed arandr to see if I could fix it.
:~$ arandr
/usr/lib/python2.7dist-packages/screenlayout/xrand.py:58 UserWarning: XRandR wrote to stderr, but did not report an error (Message was: 'xrandr: Failed to get size of gamma for output default\n')
warnings.warn("XRandR: wrote to stderr, but did not report an error (Message was: %)"%err)
The screen layout editor does pop up but Outputs -> default -> Resolution only shows the option for 800x600.
EDIT:Additional data
This is the xrandr output from the default installation:
:~$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 129mm
1024x600 60.00*+ 65.00
800x600 60.32 56.25
640x480 59.94
VGA1 disconnected (normal left inverted right x axis y axis)
:~$ xrandr
This is the graphics hardware on the netbook.
root@vuudo:/home/vuudo# discover | grep Graphics
Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller
Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller
Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller
Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller
Intel Corporation Mobile 945GSE Express Integrated Graphics Controller
Intel Corporation Mobile 945GME Express Integrated Graphics Controller
root@vuudo:/home/vuudo#
Question:
Other than the easy (MS) way of reinstalling Vuu-do on the card and not updating it afterwards, is there a way to fix this?
Thanks in advance.
A.
(BTW: greenpants -> this is a really great re-spin.)
Hello:
... the menu label.
... should be unique.
I would seem so.
If you have two with the same name, the one that shows up on the screen is the first one on the list.
... change them to HDD and SD to keep them short ...
I wanted to do something like that but I had the idea that it would muck up someting.
Easy to remember and hard to forget is the way here.
You've been most helpful.
I can now run my Linux based app off a lightweight distro in a netbook by just booting from an SD Card and keeping all settings in the HDD.
And should the SD Card goe south for any reason, installing the same distro in the same manner on any other SD Card should get things back to normal.
A dog with with two tails. =-)
Thanks a lot.
Cheers,
A.
Hello:
The default is to use "persistence" as the label. If you use a different label ...
Yes ...
persistence-label=livedata
But I was referring to the first line:
label persistence <------------------------- this one
menu label vuudo+HDD persistence
kernel /vuudo/live/vmlinuz
append initrd=/vuudo/live/initrd.img boot=live union=aufs persistence persistence-label=livedata live-media-path=/vuudo/live
Cheers,
A.
Hello:
I'm not very clear on your setup ...
Sorry ...
HDD in a XP setup with an ext4 partition labeled 'livedata'.
SD Card with an ext4 partiton labeled 'persistence'.
This is /syslinux/live.cfg
label persistence
menu label vuudo+HDD persistence
kernel /vuudo/live/vmlinuz
append initrd=/vuudo/live/initrd.img boot=live union=aufs persistence persistence-label=livedata live-media-path=/vuudo/live
label persistence
menu label vuudo+SDCard persistence
kernel /vuudo/live/vmlinuz
append initrd=/vuudo/live/initrd.img boot=live union=aufs persistence persistence-media=removable-usb live-media-path=/vuudo/live
label vuudo
menu label vuudo
kernel /vuudo/live/vmlinuz
append initrd=/vuudo/live/initrd.img boot=live union=aufs live-media-path=/vuudo/live
label memtest
menu label Memory test
kernel /live/memtest86+.bin
... should be able to boot without persistence, mount both persistent partitions and copy from one to the other ...
Right!
That did the trick. =-)
Mounting without persistence enabled me to mount both media/vuudo/persistence and media/vuudo/livedata and then run rsync.
I am aware that having two 'persistence' labels has the effect on not showing the second one as a choice at boot time.
Not that I need it, but just to know: does the label have to be persistence?
Thanks a lot for your help.
Best,
A.
Hello:
I'll try the perisitence on the HDD and see how it goes.
It took me a while but it's done.
The problem I now have is that I need to copy everything in the 'persistence' partition in the SD Card to the 'peristence-label=livedata" 50Gb. partition I created in the netbook's HDD so I don't have to setup/install everything over again.
I cannot seem to get around getting it done: I cannot copy (as root) directly from the mounted partition to a directory on a USB drive (filesystem does not support hard links) and I cannot zip up everything to move just the zip file (some other error) and then unzip it in its destination.
Please excuse my Linux ignorance ...
How can I get this done?
Thanks in advance.
A.
Hello:
Thanks for the fast reply. 8^)
Yes, the persistent volume does not have to be on the same disk as the operating system.
Live-boot will look for the "persistence" label (or other label if you specify it in the boot command) ...
OK.
Good to know.
... don't think you can set up the persistent partition with refracta2usb, because it will only let you choose usb ...
Yes ...
I noticed that.
Good 'insurance'.
Create the partition, give it a label (use e2label command), add persistence.conf, edit your boot menu (mount the sd card to edit syslinux/live.cfg)
I guess I can also create and label the partition on the netbook's HDD with GParted. (?)
... know why devuan and miyo wouldn't work for you. They should. I've used both of them on live-usb.
I think it may be something related to my using a Asus eeePC netbook?
With MIYO-i3 Jessie (I liked the WM GUI) it worked but there was something wrong with X and it would freeze and be unresponsive.
Something about init: Id"X" respawning too fast: disabled for 5 minutes.
With Devuan it would not boot but I only tried it a couple of times and gave up, not too much patience these days.
On a separate note: I think there may be something going on with syslinux (different versions?) and the success may also be tied to the OS used to run refracta2usb.
For example, one of my attempts was installing and running refracta2usb from my PCLinuxOS rig (not in the PCLinuxOS repo) and not from my Devuan rig.
The process was properly completed but it would not boot and I saw that the syslinux legend on screen said PCLinuxOS.
The Vuudo image was installed from within my Devuan rig and everything seems to work properly.
I'll try the perisitence on the HDD and see how it goes.
Thanks for your input.
Cheers,
A.
Hello:
... read a little about persistence in the refract2usb help ...
OK ...
Thanks, I'll have a look.
I have managed to set up my bare bones Devuan-Live in a 4.0 Gb SD Card using refracta2usb but with a Vuudo *.iso.
The application I need to use installed correctly but I still have to test it.
Before that, I tried with Devuan-Jesse, MIYO-Jesse, MIYO-i3 and even PCLinuxOS without much luck.
But the setup I am pointing to does not have being portable as a goal.
I would like to boot a light Linux installation to run a dedicated application from a netbook that (for the time being) has an XP installation on it's 500Gb HDD.
The HDD could share some space (100Gb) by means of a separate (inaccessible to XP) ext4 partition which would hold absolutely everything that needs to be persistent.
Could that be done?
I got this idea when I recalled once booting into a W2000 installation with a botched bootloader using a 3.5" diskette with the right files on it.
Thanks in advance.
A.
Hello:
I remember hearing about issues with rufus.
Yes ...
There's also something going on WRT syslinux versions not being compatible.
Bear in mind that the problem I posted about cropped up only when I resized the SD Card.
Up to that point, everything was perfectly well (apparently).
The thing is that Refracta gave me no joy either, at least with the Devuan *.iso I've used.
But I was able to use Refracta to set up a Miyo-Extra-ascii on the SD Card.
Persistance seems to be an issue still so I'll have to try again.
Any ideas?
TIA
A.
Hello:
I don't think you can resize FAT partitions with gparted. I'm surprised you didn't get an error message ...
No error message.
But I had checked, just in case:
This is on GParted 0.31.0 from my PCLinuxOS.
... make the fat32 the right size to begin with. If rufus won't let you ...
No. Rufus formats the whole card either as FAT or FAT32.
... use refracta2usb.
... a little larger than the iso file, so there's room ...
I was thinking about that.
But still, this should not be happening.
I would like to know why.
Thanks for your input.
A.