32-bit systeem netjes afleggen (SSD inhoud bewaren)

[aawe mwan]

Ik heb een 32-bit computer onder Ubuntu 18.04.3 LTS. Hij is zo'n 15 jaar oud maar ziet er nog als nieuw uit en doet het eigenlijk nog prima, voor zover dat mogelijk is met 2GB geheugen (meer kan er niet in).

Maar ik wil hem nu toch maar gaan "archiveren".
Ik zou de 120GB SSD die er in zit dan willen hergebruiken.

Ik heb een 64GB SSB voor het systeem, zodat ik hem in de toekomst nog wel af toe een keer kan opstarten. Normaal zou ik een verse installatie doen op de nieuwe schijf en dan de gebruikersbestanden overzetten van de oude op de nieuwe schijf, maar dit is een 32-bit systeem en dat ondersteunt Ubuntu niet meer.

Ik dacht dat het ook wel leerzaam zou zijn om het een keer "anders" te doen. Daarom heb ik met cp -afvx alle bestanden overgezet van de oude op de nieuwe drive en in /etc/fstab het schijf-ID aangepast, maar dit werkte niet: hij wilde gewoon niet opstarten van de 64GB drive.

Heb ik het verkeerd gedaan? Is er een andere gemakkelijke manier om naar een kleinere opstartdrive over te stappen? Of is een 32-bit systeem zelfs dit beetje moeite niet meer waard?

[HollowGamer]

Ik snap je vraag niet, wat werkt dan precies niet? Waarom heb je niet iets als rsync of beter backup-programma's gebruikt? En waarom zou je geen verse installatie uitvoeren?

Komt die andere SSD toevallig uit een 64-bit systeem en werkt deze met MBR? Dan moet je ook de bootloader (grub) opnieuw installeren. Maar beide vind ik minder netter dan een clean install.

Er zijn trouwens varianten van Ubuntu en andere distro's die 32-bit blijven ondersteunen. Er zijn (helaas) genoeg die de voordelen van 64-bit niet kennen.

[FoxLenny]

Waarom zou je het nog willen als back-up systeem? Ben je niet een oplossing voor een probleem aan het zoeken wat eigenlijk geen probleem is? M'n telefoon heeft tegenwoordig al twee keer zoveel geheugen als dat oude ding...
Ik neem aan dat alle persoonlijke bestanden/data al is over gezet naar een nieuw systeem? Of moet dat nog gebeuren?
Dan gewoon oude systeem weg doen en SSD van 120 GB die je wil hergebruiken formatteren en klaar....

[Hackus]

@aawe mwan releases.ubuntu.com/16.04/ubuntu-16.04.6-desktop-i386.iso.torrent
16.04.6 LTS ondersteund nog tot 2021. of Kubuntu 18.04.3 LTS

[ Voor 9% gewijzigd door Hackus op 19-01-2020 12:26 ]

[aawe mwan]

Intussen is het meer een oefening geworden, om te zien of het me lukt om een opstartschijf te kopieren.
Ik denk dat ik over het hoofd gezien heb dat dit systeem nog draait met een swappartitie in plaats van een swapfile, dus dat ga ik aanpassen en het daarna nog een keer proberen.

Verder heb ik de 64GB SSD ooit gebruikt als FAT, dus waarschijnlijk heeft hij MBR. Dat zal ik ook moeten fixen.

Maar daarna ga ik waarschijnlijk sowieso Kubuntu vers installeren, dan weet ik ook zeker dat er geen persoonlijke informatie achterblijft.

[ Voor 11% gewijzigd door aawe mwan op 19-01-2020 13:50 ]

[The Eagle]

Was het niet veel makkelijker geweest om ff clonezilla aan te slingeren en de hele bende met een image over te zetten?

[aawe mwan]

Dat was wel fijn geweest, maar de Clonezilla pagina zegt "The destination partition must be equal or larger than the source one".

[Hero of Time]

Je bent 1 stap vergeten en dat heeft niets met swap of wat dan ook te maken. Je bent de MBR vergeten. Heb je namelijk na de kopieslag nog wel een 'grub-install /dev/sdx' gedaan, waar x staat voor je 64 GB schijf?

Hoe lang wil je het systeem 'archiveren' eigenlijk? Ga je 'm nog met enige regelmaat opstarten of kan het zijn dat 'ie een jaar of langer in een hoekje staat stof te verzamelen? Want een SSD moet namelijk regelmatig spanning krijgen om z'n data te behouden. De cellen verliezen anders hun gegevens en dan heb je niets meer.

[aawe mwan]

De tip van grub-install is terecht, maar ik had de kopie-schijf al met "boot repair" opstartbaar gemaakt. Voor de zekerheid heb ik nog grub-install en grub-update gebruikt, maar dat maakt voor het doorstarten geen verschil.

Wat er bij opstarten gebeurt is dat het scherm met het ubuntu logo verschijnt en de 5 puntjes die tussen rood en wit wisselen, maar dat dit scherm blijft. Als je op de pijltjestoetsen drukt, rollen er honderden logregels over het scherm, met als essentie dat diverse services niet gestart konden worden.

Ik ben op de logregel "Gave up waiting for suspend/resume device" gaan zoeken en kwam zodoende bij het bestand /etc/initramfs-tools/conf.d/resume waar inderdaad een UUID van een niet-bestaande partitie staat. Na deze vervangen te hebben door RESUME=none en update-initramfs draaien zijn alle meldingen tijdens het opstarten weg. Maar start hij nog steeds niet door.

Enfin, zometeen ga ik dan toch maar gewoon Kubuntu proberen.

De Samsung SSD die ik ga hergebruiken is er trouwens eentje uit een serie die een firmware bug had, waardoor stationaire data niet automatisch herschreven werd. Dat merkte je doordat de schijf na een paar jaar steeds trager werd (bij het lezen van oude data). Hij heeft natuurlijk wel een firmware update gehad intussen.

[Hero of Time]

Ah, als grub e.d. wel komt, bewerk dan de opstartregel in Grub en haal 'quiet splash' weg. Dan krijg je alle informatie bij het opstarten te zien en daarmee kunnen we je verder helpen. Maar je eerste punt over het missen van een UUID is al een hint naar eventuele andere zaken waar een UUID wordt genoemd voor een partitie die er niet meer is. Denk bijvoorbeeld aan andere plaatsen waar je swap wordt genoemd.

[GuntherDW]

Dit gaat vrij dom klinken maar ik wil het maar uitsluiten voordat we iets te high level gaan denken.

Hoe heb je de copy afgehandeld. Je hebt toch de partities welke "temporary" of meer specifiek zijn zoals /dev/shm, /dev zelf, /proc, /tmp e.d. niet mee copied? Best maak je die folders dan zelf aan op de nieuwe disk zodat er geen rare dingen voorvallen met scripts die een lege folder verwachten en dan een al gevulde folder vinden.

systemd wat al even in ubuntu zit trouwens is héél gevoelig voor fouten in fstab (een van de numerous redenen waarom ik het niet draai ), wees absoluut zeker dat die correct zijn.

[aawe mwan]

GuntherDW schreef op zondag 9 februari 2020 @ 05:11:
Je hebt toch de partities welke "temporary" of meer specifiek zijn zoals /dev/shm, /dev zelf, /proc, /tmp e.d. niet mee copied?

Daar heb je misschien een punt, want daar heb ik niet zo goed op gelet omdat ik aannam dat die toch wel achter de mount zouden verdwijnen. Intussen heb ik Kubuntu vers geinstalleerd op de 64GB disk, dus ik kan niet meer zien of dit het probleem opgelost zou hebben.

Later las ik ergens als vuistregel voor Ubuntu dat je de directories /run /sys /proc en /dev leeg moet aanmaken en de rest moet kopieren. Maar die lijst is natuurlijk niet compleet, alleen al vanwege /tmp.

Al met al blijkt het handmatig kopieren van een opstartschijf best ingewikkeld te zijn.

[Hero of Time]

Nou is /tmp niet zo erg als je die niet hebt uitgesloten. Zolang de rechten erop goed staan zal het na een reboot gewoon leeg zijn. Daar zorgt systemd dan wel voor (of andere processen). Een hele enkele keer heb ik gezien dat /tmp na reboot niet werd opgeruimd, wat ook geen ramp was voor wat er op draaide.