You are not logged in.
I was recently given an old imac computer. It was running a very old mac os 10.6 and would not install a newer version. So I've decided to put devuan on it.
The CPU (an Intel Core 2 Duo) is indeed 64-bit capable. However, the computer refuses to boot devuan amd64 dvds. I've tried both ascii and beowulf, full desktop and netinstall; tried from both the internal drive and an external drive. It will not boot from these discs. What I have been able to do so far, is install from the i686 disc, then install an amd64 kernel and boot from it. I've been unable, at this point, to change all of the system packages over to amd64. I can mount and read the amd64 desktop installer dvd, but can't seem to start the installer from there without booting from it (?) I mainly want to use amd64 since it's required for most modern web browsers (most seemed to stop updating 32-bit versions several years ago). Any advice? I've read a few different "cross-grading" articles, but so far I've only managed to break apt/dpkg.
I use devuan ascii daily on my desktop, 3rd gen core i5 with 32gb ram, nvidia gtx650, dual monitor, 2tb + 250gb hdd
also on a raspberry pi 3b+ 16gb microsd
devuan jessie I use twice a week on laptop, it's got some amd cpu from around 2010-2012, 8gb ram and a 250gb hdd
also devuan jessie once a week on a very old desktop (actually planning to replace it with a newer desktop soon), pentium 4 with 512mb ram and a 40gb hdd
also considering to replace debian 8 with devuan ascii on a remote server (or two) that I manage for work
I think this is missing a part.
While parted does show the new size:
(parted) print
Model: SD SC16G (sd/mmc)
Disk /dev/mmcblk0: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 135MB 134MB primary fat16 lba
2 135MB 15.9GB 15.8GB primary ext4
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 14.9G 0 disk
|-mmcblk0p1 179:1 0 128M 0 part /boot
`-mmcblk0p2 179:2 0 14.7G 0 part /however ... the filesystem doesn't seem quite right:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1743136 777240 859300 48% /
devtmpfs 438328 0 438328 0% /dev
tmpfs 88764 1200 87564 2% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 177520 0 177520 0% /run/shm
/dev/mmcblk0p1 130798 35754 95044 28% /boot/dev/root size should be much larger, it is only reporting 1,743,136 KB (~1.7 GB).
To reply to my self (or is it preferred to edit the original post):
Apparently this didn't begin with the Ascii upgrade (which I did 2 weeks ago) -- /var/log/pm-suspend.log has a date of Fri Jun 29 (morning wakeup time). There's no record of Fri Jun 29 (night sleep time) or Sat Jun 30, Sun Jul 1 in /var/log/pm-suspend.log at all. This is likely when the suspend/resume hooks stopped running. This seems strange to me. I have rebooted in the meantime, which did not correct the issue. On Jun 29 I did remove mono and a bunch of things along with it... I'll see if any of that is related. So at this point it seems less likely a bug and more likely something I've done to my own system.
[Mon Jul 2 AM edit]
So last night I directly ran /usr/sbin/pm-suspend instead of /usr/bin/xfce4-session-logout --suspend
The result was the hooks were called on suspend/resume, /var/log/pm-suspend.log was updated, screen was not locked on resume (of course).
I suppose I could change my suspend routine to call /usr/bin/xflock4 then run /usr/sbin/pm-suspend, after granting my user account the ability to run /usr/sbin/pm-suspend . Still unclear as to what changed with xfce4-session-logout .
In Jessie this worked:
/usr/bin/xfce4-session-logout --suspend
before suspending, the system would call
/etc/pm.d/sleep/50_unmount
which I have unmount certain things...
Now in Ascii, the /etc/pm.d/sleep/50_unmount is no longer called when suspending.
In fact, none of the files in /etc/pm.d/sleep are called when resuming from suspend, either.
Is this a bug or intentional change, or do I have something else misconfigured?
I can work around this, but just wondering what has changed or if /etc/pm.d/sleep/* has been abandoned for some other way of calling scripts on suspend/hibernate/thaw/resume.
First ran on a (backed-up) virtual machine. The only "major" problem was with wicd, a missing file /etc/dbus-1/system.conf -- I copied from my host system and resumed the upgrade... it finished, rebooted, all seems to be okay.
Then backed up my "baremetal" system. Some other errors (depencencies?) partway through, had to run a "apt-get --fix-broken install" then resume the dist-upgrade. Same issue with wicd, copied system.conf from most recent backup and resumed upgrade. Rebooted, no gui. Reinstalled nvidia driver, rebooted, all seems okay. Remmina was uninstalled. Opened synaptic to some error, had to run "dpkg --configure -a", now synaptic works. Had to force specific remmina version (something about backports?), now it is okay. Had to redo some other minor tweaks, but overall a rather painless experience. Just kind of curious about that wicd thing, it seems the system.conf is deleted too early in the upgrade process?
I know this is supposed to work, in theory, but is it recommended to try debian 8 -> devuan ascii upgrade on a remote (ssh) machine? Will I lose ssh connectivity during the upgrade process, what other things should I be aware of before attempting it?
Again, thanks to the developers for their work in this project, and the people who provide forum support / other chat.