Hello:

Aha !

That's for sure ...  =-/

OK

I don't think I have anything 2.1 installed.

My HD install started off as jessie more than two years ago and my VM is the one I mentioned in my OP.

I see.

What Synaptic is telling me is that it is installed in my system, not that it is available in the repository.
Sounds like something that could be added to the UI.

The Installed (local or obsolete) Status list shows only two:

refracta2usb 2.3.6
refractasnapshot-gui 10.0.2.

The Installed (manual) Status list shows all five:

refracta2usb 2.3.6
refractainstaller-base 9.5.3
refractainstaller-gui 9.5.3
refractasnapshot-base 10.1.1
refractasnapshot-gui 10.0.2

OK.

Thanks for the knowledge shared. 

Cheers,

A.

Hello:

Thanks for the input.  =-)

But I gave up on the Alien-OS live distribution, has too many unknowns for my liking and has not been updated for the past two years.
Also, some unknown (have to see if it reproduces later on) was borking up the USBs filesystem and cause for it to not be recognised at boot by the Ultra24's BIOS.

I heeded fsmithred's sound advice and went for the Devuan ASCII vbox image to which I am adding the basic applications I need to make a very slim live *.iso of my own.
This way I know where it came from and how it got to be.

So there'll be no surprises save those due to my own incompetence. =^)

Cheers,

A.

Hello:

I managed to (sort of) fix things.

I was able to drop to a shell and by means of sudo su become root.
Then I gave root a new password and added a user with his own password.

So, now I was able to log-in both as root with administrative privileges and as user.

Certain that I could log-in under both IDs, I tried to get rid of user alien-os, whose password I did not know and name I did not like.

Unfortunately, that was not possible as it was working with some process.

Alien-OS@root╺─╸[~]  userdel alien-os
userdel: user alien-os is currently used by process 2890
Alien-OS@root╺─╸[~]  

So I figured I could keep it in lieu of the newly created user which I would then remove.
No big deal ....

So, as root, changed alien-os' password and the problem would be solved.

Alien-OS@root╺─╸[~]  passwd alien-os
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Alien-OS@root╺─╸[~]  

I then rebooted and when I logged in as user alien-os with the new password, instead of bringing up the desktop or saying that the password was not valid, LightDM came back like if nothing had happened: I typed the password at least ten times and it came back without logging me in every time.

I logged on as root again to see what was going on ie: see what users were in the system.
It was a surprise of sorts:

 Alien-OS@root╺─╸[~]  users
alien-os alien-os alien-os alien-os alien-os alien-os root
» Alien-OS@root╺─╸[~]  

I installed members and used it with groups try to see who was what:

Alien-OS@root╺─╸[~]  groups alien-os
alien-os : alien-os cdrom floppy audio dip video plugdev netdev bluetooth
Alien-OS@root╺─╸[~]  

Alien-OS@root╺─╸[~]  members alien-os
alien-os
Alien-OS@root╺─╸[~]  

I have always read/been told that users have unique names ie: there could only be one user with alien-os for a name.

But (unless I am missing something) in this case we are in front of six users sharing the same name.

This is where I stop and ask if anyone can shed some light into this.

Thanks in advance,

A.

Hello:

Yes, that did it.

I think this was probably some sort of BIOS glitch.
The rig is a Sun Ultra24, excellent hardware and way ahead of its time.
But the BIOS is absolute crap.

Then Oracle came along...
But I digress.

I assume that it could have been a BIOS glitch because when the problem cropped up, the boot screen (which rolls by fast but you can catch it) did not list a Kingston DataTraveller storage device like it usually did.

And then, having pressed F8 to get at the Boot Menu, when it came up it showed me a USB: USB Flash Drive as the first option instead of showing me a USB: Kingston DataTraveller.

Shutting down, unplugging and plugging it in again (on an external port just in case I had to do something) set things right: at reboot the Boot Menu option was the correct one ie: USB: Kingston DataTraveller.

Thanks for your input.

Best,

A.

Hello:

This morning I went ahead and booted the live *.iso with persistence and then ran Synaptic.
The update took a long time, probably because the *.iso is from two years ago, the list was huge and included linux-image-3.16.0-10-amd64.

When it finished, I shut down and rebooted the live *.iso with persistence, expecting to see it updated.

But alas, something strange happened on the way to persistence ....   =^o !

Not only did the live *.iso not boot ie: on selection of the USB drive, it just proceeded to my usual grub screen.

I booted into my main Devuan and to see what had been written into the persistence partition /dev/sda is nowhere to be found.

It has absolutely dissapeared from the system.

- fdisk does not see it:

groucho@devuan:~$ sudo fdisk -l
[sudo] password for groucho: 
Disk /dev/sdb: 68.4 GiB, 73407488000 bytes, 143374000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004a8f4

Device     Boot     Start       End  Sectors  Size Id Type
/dev/sdb1            2048  40974335 40972288 19.6G 83 Linux
/dev/sdb2        40974336 139278335 98304000 46.9G  5 Extended
/dev/sdb3       139278336 143372287  4093952    2G 82 Linux swap / Solaris
/dev/sdb5        40976384  45072383  4096000    2G 83 Linux
/dev/sdb6        45074432 139278335 94203904 44.9G 83 Linux

Partition table entries are not in disk order.

Disk /dev/sdc: 279.4 GiB, 300000000000 bytes, 585937500 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x30830f4e

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdc1        2048 585936895 585934848 279.4G  5 Extended
/dev/sdc5        4096 585936895 585932800 279.4G 83 Linux

Disk /dev/sdd: 68.4 GiB, 73407488000 bytes, 143374000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x68017f5c

Device     Boot    Start       End  Sectors  Size Id Type
/dev/sdd1  *        2048  40962047 40960000 19.5G 83 Linux
/dev/sdd2       40962048  45058047  4096000    2G 82 Linux swap / Solaris
/dev/sdd3       45058048 143372287 98314240 46.9G  5 Extended
/dev/sdd5       45060096 143372287 98312192 46.9G 83 Linux

Disk /dev/sde: 232.9 GiB, 250056000000 bytes, 488390625 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x85188518

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sde1            2048 329396223 329394176 157.1G 83 Linux
/dev/sde2       329396224 488388607 158992384  75.8G 83 Linux
groucho@devuan:~$ 

- parted does not see it either:

groucho@devuan:~$ sudo parted
GNU Parted 3.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print devices                                                    
/dev/sdb (73.4GB)
/dev/sdc (300GB)
/dev/sdd (73.4GB)
/dev/sde (250GB)
(parted) quit                                                             
groucho@devuan:~$ 

Any idea as to what may have happened?

I find it strange that the device is not available ...

Edit:

... dmesg reports it ...

--- snip ---
[    3.584672] scsi 7:0:0:0: Direct-Access     USB      Flash Drive      2.00 PQ: 0 ANSI: 0
[    3.596655] sd 7:0:0:0: [sda] Attached SCSI removable disk
--- snip ---

... but says nothing of /sda2, which is where persistence is/was supposed to live.

lsblk does not see it either.

groucho@devuan:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb      8:16   0  68.4G  0 disk 
|-sdb1   8:17   0  19.6G  0 part /
|-sdb3   8:19   0     2G  0 part 
|-sdb5   8:21   0     2G  0 part /var/log
`-sdb6   8:22   0  44.9G  0 part /home
sdc      8:32   0 279.4G  0 disk 
|-sdc1   8:33   0     1K  0 part 
`-sdc5   8:37   0 279.4G  0 part 
sdd      8:48   0  68.4G  0 disk 
|-sdd1   8:49   0  19.5G  0 part 
|-sdd2   8:50   0     2G  0 part 
|-sdd3   8:51   0     1K  0 part 
`-sdd5   8:53   0  46.9G  0 part 
sde      8:64   0 232.9G  0 disk 
|-sde1   8:65   0 157.1G  0 part /media/backups
`-sde2   8:66   0  75.8G  0 part 
sr0     11:0    1  1024M  0 rom  
groucho@devuan:~$ 

lshw sees it:

groucho@devuan:~$ sudo lshw | grep logical
             logical name: eth0
                logical name: usb1
                logical name: usb2
                logical name: usb3
                logical name: usb9
                   logical name: scsi7

                      logical name: /dev/sda
                      configuration: logicalsectorsize=512 sectorsize=512
                         logical name: /dev/sda

                logical name: scsi8
                   logical name: /dev/sdb
                   configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=0004a8f4
                      logical name: /dev/sdb1
                      logical name: /
                    *-logicalvolume:0
                         logical name: /dev/sdb5
                         logical name: /var/log
                    *-logicalvolume:1
                         logical name: /dev/sdb6
                         logical name: /home
                      logical name: /dev/sdb3
                   logical name: /dev/sdc
                   configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=30830f4e
                      logical name: /dev/sdc1
                    *-logicalvolume
                         logical name: /dev/sdc5
                   logical name: /dev/sdd
                   configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=68017f5c
                      logical name: /dev/sdd1
                      logical name: /dev/sdd2
                      logical name: /dev/sdd3
                    *-logicalvolume
                         logical name: /dev/sdd5
                   logical name: /dev/sde
                   configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=85188518
                      logical name: /dev/sde1
                      logical name: /media/backups
                      logical name: /dev/sde2
                   logical name: usb7
                   logical name: usb8
                logical name: usb4
                logical name: usb5
                logical name: usb6
                logical name: usb10
          logical name: scsi1
             logical name: /dev/cdrom
             logical name: /dev/cdrw
             logical name: /dev/dvd
             logical name: /dev/dvdrw
             logical name: /dev/sr0
groucho@devuan:~$ 

Thanks in advance,

A.

Hello:

I was in my Devuan install and rebooted to alien-os to answer your post and ...

It works.
Go figure.

Alien-OS@alien-os╺─╸[~]  cat /proc/cmdline
BOOT_IMAGE=/live/vmlinuz initrd=/live/initrd.img boot=live persistence vga=795 username=alien-os  
Alien-OS@alien-os╺─╸[~]  

Stanzas persistence and vga=795 were added bz me after Tab to edit the boot command.
Otherwise it boots as a the std live *.iso. (?)

Alien-OS@alien-os╺─╸[~]  cat /persistence.conf
/ union
Alien-OS@alien-os╺─╸[~]  

Don't know what it uses, have to check/read up.
All I can say is that the DE keyboard (qwerz) layout + the darkish theme are a bitchy combination.  =-/

I saw alien-os mentioned here ...

http://dev1galaxy.org/viewtopic.php?id=1811
http://dev1galaxy.org/viewtopic.php?pid=3569#p3569

... and assumed it was Devuan based.

Apparently only 64-bit.

Yes, automagically created.

There is a website:
https://www.alien-os.de/

Every boot the installation says there are updates available (a nag) but it is a huge list which includes linux-image-3.16.0-10-amd64.
If I accept and go ahead, do these stay installed on reboot in persistence mode and then get carried on to the new *.iso?

Thanks in advance,

A.

Hello:

Had not though of that, did not occur to me that it could be done.
Thanks for the heads up.

But I am still having issues with the persistence setup.
Will start new thread.

Best,
A.

Hello:

Yes.
I think that may be the best and less complicated way to go around this.

But I once tried using an SD Card installaiton with persistence and hit a severe bump with respect to updating it.
Have to go back and see what it was about.

But first I have to get persistence working, something that is eluding me at the moment.

I'll start another thread for that.

Thanks for your input.

A.

Hello:

OK.

OK.

OK.

It's all rather over my head/pay grade.
Eventually, I guess ...

I computed them in a teminal so it would be hard to make a typo and checked the values twice.

A coincidence?
 
This isolinux.bin only came up because of my checking the installation media with the install's verification routine.
The *.iso file was intact after download and was correctly written to media.

But as you pointed out, the issue did not come up in the 2.0.0 *.isos because isolinux.bin was not in the respective md5sum.txt file. 
It was not scanned, ergo no error was computed.   =-)

Agreed ...
As I mentioned in my email, due to a USB stick with not enough space.

I suppose then that all is well?

Thanks for taking the time to look into this.

Best,

A.

Hello:

OK.

But if the isolinux.bin files are not (fsmithred says, I wouldn't know) arch specific, why is the 2.1_amd64 version different from the 2.1_i386?
ie: I'm assuming that they are different because they produce different md5sums but maybe functionally they are the same.

To top it off, neither of the md5sums they produce are the same md5sum in the md5sum.txt file.
Makes no sense ...

Sure ...
But I'd pull them from the servers asap to do some forensics on those two files to see just what happened.
Cannot be too careful.

No need.
You are the guys moving the Dev1 project along.

Cheers,

A.

Hello:

Thank you.

Yes, that's what seems (to me) odd.
I was expecting this to be just a bad download, but no.

Here's what I have.
I mounted the *.iso files with AcetoneISO and checked the respective isolinux.bin files.

---
devuan_ascii_2.1_amd64_netinst.iso - 21-Oct-2019 08:35 - 319.8 MB (319815680 bytes)
From https://ftp.nluug.nl/pub/os/Linux/distr … aller-iso/
---

groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
bdad948d65c1dea713e1698d04a4e75d  isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$

But the respective md5sum.txt says otherwise:

81d876d6234d3ca002390e7cb361bb61  ./isolinux/isolinux.bin

---
devuan_ascii_2.1_i386_netinst.iso - 22-Oct-2019 02:47 366.0 MB (365953024 bytes)
From: https://ftp.nluug.nl/pub/os/Linux/distr … aller-iso/
---

groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
3b36f20bc14cf4ad0f046962c4414221  isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$

But the respective md5sum.txt says otherwise:

81d876d6234d3ca002390e7cb361bb61  ./isolinux/isolinux.bin

Since the *.iso files are intact and the isolinux.bin files are not arch specific what I think we are seeing in the sample I am posting about is that there are (at least) two versions but none of them with the correct md5sum  ie:  81d876d6234d3ca002390e7cb361bb61  ./isolinux/isolinux.bin

I have not checked other sources as I expect they are mirrored.
Let me know if I can help out in any way.

Thanks in advance.

A.