You are not logged in.
- Topics: Active | Unanswered
#1751 Re: Installation » Problems configuring persistence » 2019-11-23 21:04:19
Hello:
... take out the USB ...
... reboot and see what happens when I plug it into one of the external ports ...
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.
#1752 Re: Installation » Problems configuring persistence » 2019-11-23 20:12:58
Hello:
... did it include reinstalling grub?
... grub even installed in the live system?
I don't think so. (?)
Mounting the live *.iso image using AcetoneISO shows me three folders:
- isolinux
- live
- pkglist_Alien-OS MNML-20170610_1259
The pkglist includes:
grub-common
grub-pc
grub-pc-bin
grub2-common
... computer boot without the usb stick?
Yes.
No problems with that.
Maybe the flash drive is dying.
I don't think so ...
It's a new/almost no use Kingston DTSE9.
... a reboot will fix it.
Been there, tried that.
... pulling the stick out and plugging it back ...
... probably be /dev/sdf if you do this
Was about to try that after my afternoon espresso.
I have the impression/idea that somehow/for some reason the file system went south.
But no idea how that could have happened.
It is my understanding that whatever was being written to the drive was getting written to /sda2 and there were 3.0Gb available for that.
I'll take out the USB, which lives inside the box in its own socket on the motherboard, reboot and see what happens when I plug it into one of the external ports and then post back.
Thanks for your input.
Best,
A.
#1753 Re: Installation » Problems configuring persistence » 2019-11-23 15:04:03
Hello:
... 'persistence' in the boot command and the filesystem label on the persistent partition ...
... enough space in the persistent partition to hold a big upgrade.
... boot with persistence when you make the snapshot, it will copy the upgraded (running) system.
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.
#1754 Re: Installation » Problems configuring persistence » 2019-11-23 01:11:46
Hello:
... 'persistence' in the boot command and the filesystem label on the persistent partition ...
... enough space in the persistent partition to hold a big upgrade.
... boot with persistence when you make the snapshot, it will copy the upgraded (running) system.
Good.
Thanks a lot for your help. =-)
Best,
A.
#1755 Re: Installation » Problems configuring persistence » 2019-11-22 23:51:03
Hello:
I was in my Devuan install and rebooted to alien-os to answer your post and ...
It works.
Go figure.
What does your boot command look like? cat /proc/cmdline
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. (?)
What is in persistence.conf?
Alien-OS@alien-os╺─╸[~] cat /persistence.conf
/ union
Alien-OS@alien-os╺─╸[~] ... don't know Alien-OS.
... a debian-based distro and it uses live-boot and live-config. Is that correct?
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.
Is the OS 32-bit or 64-bit?
Apparently only 64-bit.
... system directories on the persistent partition ...
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.
#1756 Installation » Problems configuring persistence » 2019-11-22 21:50:12
- Altoid
- Replies: 8
Hello:
I am attempting to set up alien-os with persistence so as to change a few things and maybe slim it down a bit further to then burn a new *.iso with the changes.
I am using an 8gb pen drive which I have partitioned in this manner:
500Mib for the *.iso image
3,00Gib for the persistence partition
3,78Gib of unallocated space
Alien-OS@alien-os╺─╸[~] sudo fdisk -l
Disk /dev/sda: 7.2 GiB, 7757398016 bytes, 15151168 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: 0x062ec9ea
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 64 921599 921536 450M 17 Hidden HPFS/NTFS
/dev/sda2 921600 7219199 6297600 3G 83 Linux
Alien-OS@alien-os╺─╸[~] These are the mount points:
Alien-OS@alien-os╺─╸[~] mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=813044k,mode=755)
/dev/sda1 on /lib/live/mount/medium type iso9660 (ro,noatime)
/dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs (ro,noatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,noatime,mode=755)
aufs on / type aufs (rw,noatime,si=4d6addd750f80fe7,noxino)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
pstore on /sys/fs/pstore type pstore (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1012409,mode=755)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1626080k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
gvfsd-fuse on /home/alien-os/.gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda2 on /media/alien-os/persistence type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
» Alien-OS@alien-os╺─╸[~] The persistence partition has (apparently) all that it has to have:
Alien-OS@alien-os╺─╸[~] ls /media/alien-os/persistence
etc home lib lost+found persistence.conf tmp var
Alien-OS@alien-os╺─╸[~] But I think (?) there is probably something wrong with the mount point as persistence is not working.
What did I miss?
Thanks in advance,
A.
#1757 Re: Installation » *.iso file / live distribution modification. » 2019-11-22 21:31:38
Hello:
I find it easier to build a new system in a virtual machine ...
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.
#1758 Re: Installation » *.iso file / live distribution modification. » 2019-11-22 11:31:47
Hello:
... package selections, system configs and desktop configs will all be copied into the snapshot.
Yes.
I suppose that is as long as I do not reboot or enable presistence. (?)
... shouldn't need to change any of those once you have it the way you want.
Yes, that's the idea.
Generate a new live *.iso starting off from yes another (in this case Alien-OS) which has most of what I need and then modify it to incorporate what it does not.
... a shortcut for that. (explained a little later)
Thanks.
I'll have to see about how that works later.
I still have to get persistence working. =-/
Thanks for your input.
Best,
A.
#1759 Re: Installation » *.iso file / live distribution modification. » 2019-11-22 11:09:40
Hello:
Maybe creating a live usb with persistence ...
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.
#1760 Re: Installation » *.iso file / live distribution modification. » 2019-11-21 13:55:56
Hello:
You probably want to point out the errors ....
No ...
Not refracta errors at all.
I'm sorry, my command of the english language is rather lacking. =-/
I am referring to my own *trial and error* process, where I need to/want to change things one way or another till I get it all working as I want.
I'd like to avoid having to make a snap-shot -> mount it -> change it -> make another snap-shot -> and so on ...
Am I making sense here?
Thanks for your input.
A.
#1761 Installation » *.iso file / live distribution modification. » 2019-11-21 13:19:15
- Altoid
- Replies: 9
Hello:
I am needing to modify a live distribution which meets *most* of my needs wrt a small footprint and all the maintenance/emergency tools.
I know I can make all the mods/changes and then do a refracta-snaphot to produce another *.iso file.
But as the process of modifying it is a bit drawn out, sort of trial and error/rinse and repeat, I was wondering if there was a way to save the changes temporarily till the final thing was made up and only then take the snapshot.
Thanks in advance.
A.
#1762 Re: Installation » Problem with *.iso file » 2019-11-20 20:00:50
Hello:
... to start with a minimal install ...
Same here.
... verifying the check sum seemed to match ...
It has to match exacly.
Seemed won't do.
Just pulling your leg ... =-D
Not sure what went wrong.
In my limited experience, the first check you do is on the *.iso file you downloaded.
Then you do a check on ther file burned on the CD/DVD or USB.
I found a way to do this here:
https://askubuntu.com/questions/547332/ … -boot-disk
To check the integrity of a usb boot disk, first find the size of the iso image with
stat -c '%s' imagename.isoThis will output an image size which you can enter in place of <imagesize> in the command below.
The next command sends (through a pipe) all bytes corresponding to the size of the image to the md5sum command:sudo head -c <imagesize> /dev/sdb1 | md5sumYou can compare this with the md5sum of your .iso file.
md5sum imagename.iso
If md5sums are different then there was an issue while copying the data.
If md5sums are the same, you have successfully checked data integrity on your usb disk!
The third and final step is to boot the installaiton *.iso and run a check on the installation media itself with the tool available in the menu.
Although, as we have seen in this thread, it can sometimes give a false positive.
Cheers,
A.
#1763 Re: Installation » Problem with *.iso file » 2019-11-19 15:44:32
Hello:
... 2.1 minimal-live isos both have the same isolinux.bin.
OK.
... amd64 and i386 are both built using the same xorriso/mkisofs command.
OK.
... desktop-live i386 and amd64 use slightly different commands ...
OK.
It's all rather over my head/pay grade.
Eventually, I guess ...
... surprised that the isolinux.bin in the 2.1 minimal-lives are the same as the 2.0.0 you posted.
f03d6ecc57dad4524a0cab76b7afab41
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. =-)
... problem with installing software is not related to isolinux.bin. Sometimes the installer fails ...
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.
#1764 Re: Installation » Problem with *.iso file » 2019-11-19 10:14:57
Hello:
... took the easy way out and excluded isolinux.bin from the md5sum.txt file.
Maybe not the easy way out.
It probably slipped past them.
Now it has to get fixed, somehow.
Has it been the same with previous versions?
... one way to avoid a false negative
Indeed ... 8^* !
That with respect to the 2.0.0 *.isos.
But with respect to the 2.1 *.isos, if the 2.1_amd64 version is supposed to be the same (?) as the 2.1_i386 version, why are they different? (ie: produce different md5sums)
ie: I'm assuming that they are the *exact* same file because they are not arch specific, as fsmithred pointed out earlier.
This would imply (?) that whatever happened to the original source file was affected differently when going through the process of compiling the respective *.iso.
Am I making sense here?
The plot seems to thicken ...
---
Edit:
This is the data I have wrt some ascii 2.0.0 isos I have in storage:
ascii_2.0.0_i386_netinst.iso
groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
b6838c8e3c68b64b813cfab7ea0a200e isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$devuan_ascii_2.0.0_i386_minimal-live.iso
groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
f03d6ecc57dad4524a0cab76b7afab41 isolinux.bin
groucho@devuan:~/virtual-drives/2/isolinux$devuan_ascii_2.0.0_i386_dvd-1.iso
groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
4709734ad535226a10bef3ece43ed9d4 isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$devuan_ascii_2.0.0_i386_desktop-live.iso
groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
4709734ad535226a10bef3ece43ed9d4 isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$Note that devuan_ascii_2.0.0_i386_dvd-1.iso and devuan_ascii_2.0.0_i386_desktop-live.iso
seem to share the same isolinux.bin file.
---
Best,
A.
#1765 Re: Installation » Problem with *.iso file » 2019-11-19 00:51:45
Hello:
... ISO sets of 2.0.0 and 2.1 where produced in different ways ...
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 ...
A re-release of the latter would indeed be a good thing.
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.
thanks ...
No need.
You are the guys moving the Dev1 project along.
Cheers,
A.
#1766 Re: Installation » Problem with *.iso file » 2019-11-18 23:21:23
Hello:
... that mkisofs does something to the first 64 bytes on transfer from disk to CD/DVD image, i.e. when the .iso is created.
I have seen this in the ascii 2.1 netinstall *.iso files only.
The ascii 2.0.0 netinstall *.iso files don't seem to have this problem.
ie: media verification using the tool available within the 2.0.0 netinstall media does not fail and the isolinux.bin file produces the correct md5sum.
Best,
A.
#1767 Re: Installation » Problem with *.iso file » 2019-11-18 19:34:38
Hello:
I'm looking into this.
Thank you.
... some collected md5sums on isolinux.bin that I have in various places.
... sha256sums on the netinstall isos and they are correct.
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.
#1768 Re: Devuan Derivatives » ThomOS - the new outrageous devuan-based switchblade OS » 2019-11-15 19:28:41
Hello:
... install pcmanfm or remove its non-working menu entry?
... other menu items failed.
Has anything else happened with this Derivative?
It looks really great (reminds me of my favourite # !) but to be a switchblade OS it needs to have a fully functional file manager (or at least MC installed) and some sort of auto network configuration or scripts to get things running.
Otherwise it's sort of crippled.
Any news?
Thanks in advance,
O.
#1769 Installation » Problem with *.iso file » 2019-11-14 01:13:43
- Altoid
- Replies: 25
Hello:
I'm trying to put together a very small Devuan install to replace a TCCore installation which lacks the Nouveau drivers I need for my NVidia cards.
To do that, I downloaded the devuan_ascii_2.1_i386_netinst.iso file and once I checked the SHA256SUM, burned it with Xfburn and attempted to install.
The installation failed toward the end with a pop-up notice about not being able to install the software.
To me, it was rather obvious the DVD was at fault and with Xfburn having no integrity check, I booted up the DVD again to check the its integrity and yes, it turned out to be bad.
The isolinux file was compromised.
So I just burned another DVD, this time checking that the DVD drive was clean and burning the *.iso file at a lower speed.
This time I checked the integrity of the DVD before attempting the installation and it also also turned out to be bad but ...
It was bad at the same point: the isolinux file was compromised.
Fearing the worse (a new $ATA DVD burner) I decidec to dd the *.iso file on to a USB stick to install from there.
devuan:~$ sudo dd bs=4M if=devuan_ascii_2.1_i386_netinst.iso of=/dev/sdbJust in case, this time I booted up and checked the DVD's integrity first.
Guess what?
It also failed the test and with the same issue: a compromised isolinux file.
---
Edit I:
The compromised /isolinux file is ./isolinux/isolinux.bin.
This is from the *.iso file dd'd to a USB stick.
According to md5sum.txt, this it should compute thus:
81d876d6234d3ca002390e7cb361bb61 ./isolinux/isolinux.bin
But File -> Properties -> Digests says it is 3b36f20bc14cf4ad0f046962c4414221.
The specific *.iso file is timestamped as Devuan GNU/Linux 2.1 (ascii) i386 NETINSTALL - 2019-10-21 23:05:54 UTC
---
Edit II:
If I directly mount the downloaded and verified *.iso file with Acetone ISO and check ./isolinux/isolinux.bin with Properties -> Digests, it also says it computes as 3b36f20bc14cf4ad0f046962c4414221 instead of what md5sum.txt states.
ie: 81d876d6234d3ca002390e7cb361bb61, so it would not seem to be an issue with the download, its dd'ing to the USB stick or burning to a DVD.
Could it possibly be a compromised file within the *.iso?
---
I've never come across something like this before: it has always been a bad *.iso file or a bad burn due to the drive, the media or the software/speed.
But a bad dd?
Any help with this will be appreciated.
Thanks in advance,
A.
#1770 Re: Hardware & System Configuration » dmesg WARNING: CPU and WARN_ON(!connector->state->crtc) messages » 2019-10-06 14:31:26
Hello:
Hello:
I have not seen any indication of its being assigned.
I'm running the last available Devuan 4.9.0.11-686-pae SMP Debian 4.9.189-3+deb9u1 (2089-09-20) i686 and the problem subsists.
Will this ever get fixed or will it end up as part of the 'won't fix' crud that ends up accumulating inside the code because it is not considered worth correcting?
A.
#1771 Re: Other Issues » 32bit packages on a 64bit system » 2019-09-22 00:27:38
Hello:
Wine can be rather a PITA.
Have you tried the alternative of setting up VirtualBox?
You run all your MS applications in a VM.
XPSP3, for example.
Cheers,
A.
#1772 Re: Desktop and Multimedia » Thunar -> Send To -> Any Folder? » 2019-07-11 19:43:57
Hello:
is that what you're looking for?
No ...
That's not it.
What I need/want (and opine that any FM should have) is the function MS had/has in Windows Explorer: the Right Click -> Send To -> Any Folder action.
You can select either Copy or Move and then Browse, where you get another window to quickly find where you wanted the file to go.
You can then easily repeat the same action faster as the different destinations stay cached and show up in a drop down box.
Cheers,
A.
#1773 Re: Hardware & System Configuration » [Solved] Disk access monitor for ASCII » 2019-07-11 19:25:52
Hello:
I had a similar symptom once, and in my case ...
Thanks for the heads up. =-)
I will check anyhow.
I finally found an applicable case. See: https://superuser.com/questions/363337/ … -processes
It solves a similar case with a Conky variable I had overlooked: top_io. See: http://conky.sourceforge.net/variables.html
${top_io name 1} ${top_io io_perc 1} ${top_io cpu 1} ${top_io mem 1}top_io takes arguments in the form: top_io (name) (number).
Processes are sorted by the amount of I/O the process has done during the update interval, which is what (number) represents.
The types are: "name", "pid", "cpu", "mem", "mem_res", "mem_vsize", "time", "uid", "user", "io_perc", "io_read" and "io_write".
There can be a max of 10 processes listed.
I used it with just NAME, CPU and MEM, which is just the information I needed.
Four processes is probably too many for my use and I'll trim it eventually:
Disk I/O
${hr 2}
NAME${alignr}CPU MEM
${top_io name 1}${alignr}${top_io cpu 1} ${top_io mem 1}
${top_io name 2}${alignr}${top_io cpu 2} ${top_io mem 2}
${top_io name 3}${alignr}${top_io cpu 3} ${top_io mem 3}
${top_io name 4}${alignr}${top_io cpu 4} ${top_io mem 4}Cheers,
A.
#1774 Re: Hardware & System Configuration » [Solved] Disk access monitor for ASCII » 2019-07-11 15:52:24
Hello:
So is conky really, you are only going to get information on the event as it happens ...
Indeed, which is more or less what I want to do.
Just check out that it is nothing that looks out of the ordinary/expected, so to speak.
If it were, I'd then go on to check the usual files in /var/log to see what was going on.
... logging the event you have some real data to go on that may help you figure out the issue.
Yes, you are quite right there. =-)
But unless my rig's configuration has gone astray, I do not really expect unusual stuff.
What got me asking about this is that the process, which I expect is BackInTime or TimeShift related, is not getting shown in conky (don't know why).
It happened this morning about an hour past my boot-time and I ran iotop to see what was working.
In this particular case it was BackInTime cleaning up excess/older snapsots (actually it was rsync).
Thnaks a lot for your input.
Best,
A.
#1775 Re: Hardware & System Configuration » [Solved] Disk access monitor for ASCII » 2019-07-11 15:33:45
... might be what you are looking for.
https://www.binarytides.com/monitor-disk-io-iotop-cron/
Thanks.
I'll have a look.
But logging IOTOP is sort of after the fact.
Best,
A.
Board footer
