Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #257358 > unrolled thread
| Started by | Default User <hunguponcontent@gmail.com> |
|---|---|
| First post | 2023-04-18 17:00 +0200 |
| Last post | 2023-04-19 22:40 +0200 |
| Articles | 20 on this page of 81 — 19 participants |
Back to article view | Back to linux.debian.user
/etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 17:00 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-18 17:40 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-18 19:00 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-18 21:10 +0200
Re: /etc/fstab question (problem)? Tom Furie <tom@furie.org.uk> - 2023-04-18 23:20 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-19 06:40 +0200
tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 08:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 08:40 +0200
Re: tmp on tmpfs Nicolas George <george@nsup.org> - 2023-04-19 09:00 +0200
Re: tmp on tmpfs tomas@tuxteam.de - 2023-04-19 10:00 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-24 19:10 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 19:40 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 20:10 +0200
Re: tmp on tmpfs songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 16:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 17:20 +0200
Re: tmp on tmpfs Jeffrey Walton <noloader@gmail.com> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:40 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-18 18:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-18 22:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 23:50 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-19 00:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 02:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 03:20 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-19 04:50 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 05:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 05:10 +0200
Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-19 05:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 11:20 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:10 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? davidson <davidson@freevolt.org> - 2023-04-20 01:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? rhkramer@gmail.com - 2023-04-21 11:10 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-21 13:20 +0200
gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 22:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-21 01:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 19:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-22 08:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 22:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-21 04:40 +0200
Re: /etc/fstab question (problem)? Dan Ritter <dsr@randomstring.org> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:10 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:20 +0200
[SOLVED] Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 02:30 +0200
Re: [SOLVED] Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 03:00 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-21 17:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-22 00:50 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-22 17:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 04:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-23 06:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 10:20 +0200
Re: /etc/fstab question (problem)? Celejar <celejar@gmail.com> - 2023-04-24 18:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-25 15:00 +0200
old memory sticks (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-23 17:20 +0200
[SOLVED]: old memory sticks songbird <songbird@anthive.com> - 2023-04-24 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:20 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-21 06:30 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-21 06:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 16:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:40 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-04-20 16:30 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmDsl-3jpR-13@gated-at.bofh.it> |
| In reply to | #257434 |
On Thu, Apr 20, 2023 at 10:14 AM Vincent Lefevre <vincent@vinc17.net> wrote: > > On 2023-04-19 08:34:50 +0200, tomas@tuxteam.de wrote: > > There is one downside to /tmp on tmpfs: it eats RAM. You gotta > > have some of it (currently I've 9G free on / and 16G RAM). > > True, and when I used tmpfs in the past (in 2012), I got many failures > due to lack of space (because of limited RAM). That makes me want to cringe. It brings back memories of Solaris constantly running out of RAM when trying to run the SunCC compiler. (Solaris does not over commit memory. You need boatloads of RAM). Who would want to torture themselves like that? Jeff
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-20 16:40 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmDC2-3jtc-13@gated-at.bofh.it> |
| In reply to | #257437 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Apr 20, 2023 at 10:29:04AM -0400, Jeffrey Walton wrote: > On Thu, Apr 20, 2023 at 10:14 AM Vincent Lefevre <vincent@vinc17.net> wrote: > > > > On 2023-04-19 08:34:50 +0200, tomas@tuxteam.de wrote: > > > There is one downside to /tmp on tmpfs: it eats RAM. You gotta > > > have some of it (currently I've 9G free on / and 16G RAM). > > > > True, and when I used tmpfs in the past (in 2012), I got many failures > > due to lack of space (because of limited RAM). > > That makes me want to cringe. It brings back memories of Solaris > constantly running out of RAM when trying to run the SunCC compiler. > (Solaris does not over commit memory. You need boatloads of RAM). > > Who would want to torture themselves like that? These were other times. My current lowly laptop's RAM is quite possibly bigger than your whole hard disk back then. And -- with one exception (firefox, I'm looking at you!) -- software's hunger hasn't been able to keep up with that. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-18 18:00 +0200 |
| Message-ID | <GlVUl-2SWQ-1@gated-at.bofh.it> |
| In reply to | #257358 |
Default User wrote: ... > What to do? if the tmp partition exists then put it back in your fstab and see if you can mount it manually. it may or may not mount. if it doesn't you can reboot and it should then mount. of course, make sure you have the mount point defined. > And if further information is needed, please let me know, and I will > try to get it for you. > > Thanks! songbird
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-18 22:10 +0200 |
| Message-ID | <GlZOh-2VD6-7@gated-at.bofh.it> |
| In reply to | #257358 |
On 4/18/23 07:59, Default User wrote: > Hey, I have a strange situation! > > I just realized that my /tmp partition is not being mounted at startup. > Instead, I think the filesystem may be allocating space in another > partition (maybe /root?) for tmp stuff. > > I would like to return to the prior setup, where the /tmp partition is > mounted at startup, and is used for the tmp stuff. > > Can I do so without trashing my system, and having to reinstall from > scratch. > > Note: I have current system bakups using Timeshift, and current data > (/home/[user]) backups using Borgbackup. > > And I can image the ssd with Clonezilla, or even dd, if I have to. But > I would prefer not to go through the hassle of doing so, if it is not > really needed. > > I am running Debian 11 Stable (Bullseye). > My computer has a single internal 256 Gb ssd. > I am using Gnome Version 3.38.5 as my desktop environment. > > uname -a: > Linux [host name] 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux > > mount: > sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) > proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) > udev on /dev type devtmpfs > (rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64) > devpts on /dev/pts type devpts > (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > tmpfs on /run type tmpfs > (rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64) > /dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro) > securityfs on /sys/kernel/security type securityfs > (rw,nosuid,nodev,noexec,relatime) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64) > tmpfs on /run/lock type tmpfs > (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64) > cgroup2 on /sys/fs/cgroup type cgroup2 > (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) > pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) > efivarfs on /sys/firmware/efi/efivars type efivarfs > (rw,nosuid,nodev,noexec,relatime) > bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) > systemd-1 on /proc/sys/fs/binfmt_misc type autofs > (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_i > no=786) > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) > mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) > debugfs on /sys/kernel/debug type debugfs > (rw,nosuid,nodev,noexec,relatime) > tracefs on /sys/kernel/tracing type tracefs > (rw,nosuid,nodev,noexec,relatime) > configfs on /sys/kernel/config type configfs > (rw,nosuid,nodev,noexec,relatime) > fusectl on /sys/fs/fuse/connections type fusectl > (rw,nosuid,nodev,noexec,relatime) > /dev/nvme0n1p3 on /var type ext4 (rw,relatime) > /dev/nvme0n1p6 on /home type ext4 (rw,relatime) > /dev/nvme0n1p1 on /boot/efi type vfat > (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortna > me=mixed,utf8,errors=remount-ro) > tmpfs on /run/user/1000 type tmpfs > (rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,uid=10 > 00,gid=1000,inode64) > gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse > (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) > portal on /run/user/1000/doc type fuse.portal > (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) > > Current /etc/fstab: > # <file system> <mount point> <type> <options> <dump> <pass> > > UUID=4fdd4399-6267-404a-a292- > cdc7761df3c9 / ext4 errors=remount-ro 0 1 > UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1 > UUID=00f0c2db-0490-4354-b949- > f9af11a7f001 /home ext4 defaults 0 2 > UUID=8bfeee23-9c09-45b7-a73e- > bd2ff43e207c /var ext4 defaults 0 2 > UUID=e2a56ec3-99d4-4b40-9aa4- > 24975143cdc7 none swap sw 0 0 > > Original /etc/fstab: > # /etc/fstab: static file system information. > # > # Use 'blkid' to print the universally unique identifier for a > # device; this may be used with UUID= as a more robust way to name > devices > # that works even if disks are added and removed. See fstab(5). > # > # systemd generates mount units based on this file, see > systemd.mount(5). > # Please run 'systemctl daemon-reload' after making changes here. > # > # <file system> <mount point> <type> <options> <dump> <pass> > # / was on /dev/nvme0n1p2 during installation > UUID=4fdd4399-6267-404a-a292-cdc7761df3c9 / ext4 > errors=remount-ro 0 1 > # /boot/efi was on /dev/nvme0n1p1 during installation > UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1 > # /home was on /dev/nvme0n1p6 during installation > UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home ext4 > defaults 0 2 > # /tmp was on /dev/nvme0n1p5 during installation > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 > defaults 0 2 > # /var was on /dev/nvme0n1p3 during installation > UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /var ext4 > defaults 0 2 > # swap was on /dev/nvme0n1p4 during installation > UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 none swap sw > 0 0 > > ls -lahFi /etc/fstab: > 522243 -rw-r--r-- 1 root root 368 Apr 3 17:01 /etc/fstab > > ls -lahFi /etc/fstab.original: > 522547 -rw-r--r-- 1 root root 1.3K Mar 11 12:02 /etc/fstab.original > > lsblk: > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > nvme0n1 259:0 0 238.5G 0 disk > ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi > ├─nvme0n1p2 259:2 0 23.3G 0 part / > ├─nvme0n1p3 259:3 0 9.3G 0 part /var > ├─nvme0n1p4 259:4 0 977M 0 part [SWAP] > ├─nvme0n1p5 259:5 0 1.9G 0 part > └─nvme0n1p6 259:6 0 202.6G 0 part /home > > blkid: > /dev/nvme0n1p1: UUID="26EE-0EF5" BLOCK_SIZE="512" TYPE="vfat" > PARTUUID="c0b4b1bb-bdf3-4066-b75a-f3cf56186e27" > /dev/nvme0n1p2: UUID="4fdd4399-6267-404a-a292-cdc7761df3c9" > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="706ab20c-ea65-4c25-a632- > b7858550f966" > /dev/nvme0n1p3: UUID="8bfeee23-9c09-45b7-a73e-bd2ff43e207c" > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0831f4bf-98fc-4189-a3cb- > fc2781e580fb" > /dev/nvme0n1p4: UUID="e2a56ec3-99d4-4b40-9aa4-24975143cdc7" TYPE="swap" > PARTUUID="b32e1385-6518-4d1d-9181-66d31929c7ab" > /dev/nvme0n1p5: UUID="6a105a72-f5d5-441b-b926-1e405151ee84" > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="834502f5-08b3-42ad-a322- > cf86732f8155" > /dev/nvme0n1p6: UUID="00f0c2db-0490-4354-b949-f9af11a7f001" > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="40721dda-02ba-49a1-abfc- > b624fc739d9f" > > What to do? > > And if further information is needed, please let me know, and I will > try to get it for you. > > Thanks! I have a 2.5" SATA SSD with an installation of debian-11.6.0-amd64-netinst via Debian GNU/Linux UEFI Installer menu -> Install. I tried to KISS and OOTB: 2023-04-18 12:42:22 root@taz ~ # cat /etc/debian_version ; uname -a 11.6 Linux taz 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux Our kernels are different. Did you install a backports kernel? 2023-04-18 12:52:49 root@taz ~ # mount | grep tmp udev on /dev type devtmpfs (rw,nosuid,relatime,size=16328088k,nr_inodes=4082022,mode=755) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3271028k,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/user/13250 type tmpfs (rw,nosuid,nodev,relatime,size=3271024k,nr_inodes=817756,mode=700,uid=13250,gid=13250) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=3271024k,nr_inodes=817756,mode=700) 2023-04-18 12:53:32 root@taz ~ # grep tmp /etc/fstab 2023-04-18 12:53:50 root@taz ~ # My / (root) and /tmp directories are on the same file system -- the root filesystem: 2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com # stat -c %d / /tmp 65024 65024 Your root filesystem is on the NVMe drive, and your /tmp appears to be on the root filesystem. Run 'stat -c %d / /tmp' to confirm. I would leave /tmp where it is, unless you have some specific need (such as a server or application than uses /tmp heavily). That said, I keep my FOSS OS images small enough to fit onto a "16 GB" device -- typically an SSD, but also HDD or USB flash drive. When I want to do audio/ video editing and the SSD has leftover space, I frequently create a "scratch" partition and filesystem in the free space and configure the app to use that for temporary files. David
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-18 23:50 +0200 |
| Message-ID | <Gm1n3-2Wru-1@gated-at.bofh.it> |
| In reply to | #257376 |
On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote:
> On 4/18/23 07:59, Default User wrote:
> > Hey, I have a strange situation!
> >
> > I just realized that my /tmp partition is not being mounted at
> > startup.
> > Instead, I think the filesystem may be allocating space in another
> > partition (maybe /root?) for tmp stuff.
> >
> > I would like to return to the prior setup, where the /tmp partition
> > is
> > mounted at startup, and is used for the tmp stuff.
> >
> > Can I do so without trashing my system, and having to reinstall
> > from
> > scratch.
> >
> > Note: I have current system bakups using Timeshift, and current
> > data
> > (/home/[user]) backups using Borgbackup.
> >
> > And I can image the ssd with Clonezilla, or even dd, if I have to.
> > But
> > I would prefer not to go through the hassle of doing so, if it is
> > not
> > really needed.
> >
> > I am running Debian 11 Stable (Bullseye).
> > My computer has a single internal 256 Gb ssd.
> > I am using Gnome Version 3.38.5 as my desktop environment.
> >
> > uname -a:
> > Linux [host name] 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC
> > Debian
> > 6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux
> >
> > mount:
> > sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> > proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> > udev on /dev type devtmpfs
> > (rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64
> > )
> > devpts on /dev/pts type devpts
> > (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> > tmpfs on /run type tmpfs
> > (rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64)
> > /dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)
> > securityfs on /sys/kernel/security type securityfs
> > (rw,nosuid,nodev,noexec,relatime)
> > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
> > tmpfs on /run/lock type tmpfs
> > (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
> > cgroup2 on /sys/fs/cgroup type cgroup2
> > (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
> > pstore on /sys/fs/pstore type pstore
> > (rw,nosuid,nodev,noexec,relatime)
> > efivarfs on /sys/firmware/efi/efivars type efivarfs
> > (rw,nosuid,nodev,noexec,relatime)
> > bpf on /sys/fs/bpf type bpf
> > (rw,nosuid,nodev,noexec,relatime,mode=700)
> > systemd-1 on /proc/sys/fs/binfmt_misc type autofs
> > (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pi
> > pe_i
> > no=786)
> > hugetlbfs on /dev/hugepages type hugetlbfs
> > (rw,relatime,pagesize=2M)
> > mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
> > debugfs on /sys/kernel/debug type debugfs
> > (rw,nosuid,nodev,noexec,relatime)
> > tracefs on /sys/kernel/tracing type tracefs
> > (rw,nosuid,nodev,noexec,relatime)
> > configfs on /sys/kernel/config type configfs
> > (rw,nosuid,nodev,noexec,relatime)
> > fusectl on /sys/fs/fuse/connections type fusectl
> > (rw,nosuid,nodev,noexec,relatime)
> > /dev/nvme0n1p3 on /var type ext4 (rw,relatime)
> > /dev/nvme0n1p6 on /home type ext4 (rw,relatime)
> > /dev/nvme0n1p1 on /boot/efi type vfat
> > (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,sho
> > rtna
> > me=mixed,utf8,errors=remount-ro)
> > tmpfs on /run/user/1000 type tmpfs
> > (rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,ui
> > d=10
> > 00,gid=1000,inode64)
> > gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
> > (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> > portal on /run/user/1000/doc type fuse.portal
> > (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> >
> > Current /etc/fstab:
> > # <file system> <mount point> <type> <options> <dump> <pass>
> >
> > UUID=4fdd4399-6267-404a-a292-
> > cdc7761df3c9 / ext4 errors=remount-ro 0 1
> > UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1
> > UUID=00f0c2db-0490-4354-b949-
> > f9af11a7f001 /home ext4 defaults 0 2
> > UUID=8bfeee23-9c09-45b7-a73e-
> > bd2ff43e207c /var ext4 defaults 0 2
> > UUID=e2a56ec3-99d4-4b40-9aa4-
> > 24975143cdc7 none swap sw 0 0
> >
> > Original /etc/fstab:
> > # /etc/fstab: static file system information.
> > #
> > # Use 'blkid' to print the universally unique identifier for a
> > # device; this may be used with UUID= as a more robust way to name
> > devices
> > # that works even if disks are added and removed. See fstab(5).
> > #
> > # systemd generates mount units based on this file, see
> > systemd.mount(5).
> > # Please run 'systemctl daemon-reload' after making changes here.
> > #
> > # <file system> <mount point> <type> <options> <dump>
> > <pass>
> > # / was on /dev/nvme0n1p2 during installation
> > UUID=4fdd4399-6267-404a-a292-cdc7761df3c9 / ext4
> > errors=remount-ro 0 1
> > # /boot/efi was on /dev/nvme0n1p1 during installation
> > UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1
> > # /home was on /dev/nvme0n1p6 during installation
> > UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home ext4
> > defaults 0 2
> > # /tmp was on /dev/nvme0n1p5 during installation
> > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4
> > defaults 0 2
> > # /var was on /dev/nvme0n1p3 during installation
> > UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /var ext4
> > defaults 0 2
> > # swap was on /dev/nvme0n1p4 during installation
> > UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 none swap
> > sw
> > 0 0
> >
> > ls -lahFi /etc/fstab:
> > 522243 -rw-r--r-- 1 root root 368 Apr 3 17:01 /etc/fstab
> >
> > ls -lahFi /etc/fstab.original:
> > 522547 -rw-r--r-- 1 root root 1.3K Mar 11 12:02 /etc/fstab.original
> >
> > lsblk:
> > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > nvme0n1 259:0 0 238.5G 0 disk
> > ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
> > ├─nvme0n1p2 259:2 0 23.3G 0 part /
> > ├─nvme0n1p3 259:3 0 9.3G 0 part /var
> > ├─nvme0n1p4 259:4 0 977M 0 part [SWAP]
> > ├─nvme0n1p5 259:5 0 1.9G 0 part
> > └─nvme0n1p6 259:6 0 202.6G 0 part /home
> >
> > blkid:
> > /dev/nvme0n1p1: UUID="26EE-0EF5" BLOCK_SIZE="512" TYPE="vfat"
> > PARTUUID="c0b4b1bb-bdf3-4066-b75a-f3cf56186e27"
> > /dev/nvme0n1p2: UUID="4fdd4399-6267-404a-a292-cdc7761df3c9"
> > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="706ab20c-ea65-4c25-a632-
> > b7858550f966"
> > /dev/nvme0n1p3: UUID="8bfeee23-9c09-45b7-a73e-bd2ff43e207c"
> > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0831f4bf-98fc-4189-a3cb-
> > fc2781e580fb"
> > /dev/nvme0n1p4: UUID="e2a56ec3-99d4-4b40-9aa4-24975143cdc7"
> > TYPE="swap"
> > PARTUUID="b32e1385-6518-4d1d-9181-66d31929c7ab"
> > /dev/nvme0n1p5: UUID="6a105a72-f5d5-441b-b926-1e405151ee84"
> > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="834502f5-08b3-42ad-a322-
> > cf86732f8155"
> > /dev/nvme0n1p6: UUID="00f0c2db-0490-4354-b949-f9af11a7f001"
> > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="40721dda-02ba-49a1-abfc-
> > b624fc739d9f"
> >
> > What to do?
> >
> > And if further information is needed, please let me know, and I
> > will
> > try to get it for you.
> >
> > Thanks!
>
>
> I have a 2.5" SATA SSD with an installation of
> debian-11.6.0-amd64-netinst via Debian GNU/Linux UEFI Installer menu
> ->
> Install. I tried to KISS and OOTB:
>
> 2023-04-18 12:42:22 root@taz ~
> # cat /etc/debian_version ; uname -a
> 11.6
> Linux taz 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21)
> x86_64
> GNU/Linux
>
>
> Our kernels are different. Did you install a backports kernel?
>
>
> 2023-04-18 12:52:49 root@taz ~
> # mount | grep tmp
> udev on /dev type devtmpfs
> (rw,nosuid,relatime,size=16328088k,nr_inodes=4082022,mode=755)
> tmpfs on /run type tmpfs
> (rw,nosuid,nodev,noexec,relatime,size=3271028k,mode=755)
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
> tmpfs on /run/lock type tmpfs
> (rw,nosuid,nodev,noexec,relatime,size=5120k)
> tmpfs on /run/user/13250 type tmpfs
> (rw,nosuid,nodev,relatime,size=3271024k,nr_inodes=817756,mode=700,uid
> =13250,gid=13250)
> tmpfs on /run/user/0 type tmpfs
> (rw,nosuid,nodev,relatime,size=3271024k,nr_inodes=817756,mode=700)
>
> 2023-04-18 12:53:32 root@taz ~
> # grep tmp /etc/fstab
>
> 2023-04-18 12:53:50 root@taz ~
> #
>
>
> My / (root) and /tmp directories are on the same file system -- the
> root
> filesystem:
>
> 2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com
> # stat -c %d / /tmp
> 65024
> 65024
>
>
> Your root filesystem is on the NVMe drive, and your /tmp appears to
> be
> on the root filesystem. Run 'stat -c %d / /tmp' to confirm.
>
>
> I would leave /tmp where it is, unless you have some specific need
> (such
> as a server or application than uses /tmp heavily).
>
>
> That said, I keep my FOSS OS images small enough to fit onto a "16
> GB"
> device -- typically an SSD, but also HDD or USB flash drive. When I
> want to do audio/ video editing and the SSD has leftover space, I
> frequently create a "scratch" partition and filesystem in the free
> space
> and configure the app to use that for temporary files.
>
>
> David
>
I did indeed install a kernel from backports, since the sound would not
work on my computer running any earlier kernel. Otherwise, the system
is an updated Debian Stable 11.6 (Bullseye).
>From Ls -lahFi /boot:
total 121M
1305601 drwxr-xr-x 4 root root 4.0K Feb 20 11:51 ./
2 drwxr-xr-x 19 root root 4.0K Feb 19 11:06 ../
1 drwx------ 3 root root 4.0K Dec 31 1969 efi/
1318571 drwxr-xr-x 5 root root 4.0K Apr 17 11:53 grub/
1306753 -rw-r--r-- 1 root root 231K Jan 21 09:35 config-5.10.0-21-
amd64
1318578 -rw-r--r-- 1 root root 252K Dec 19 09:14 config-6.0.0-
0.deb11.6-amd64
1318434 -rw-r--r-- 1 root root 45M Feb 19 09:35 initrd.img-5.10.0-21-
amd64
1318576 -rw-r--r-- 1 root root 61M Feb 19 11:06 initrd.img-6.0.0-
0.deb11.6-amd64
1306752 -rw-r--r-- 1 root root 83 Jan 21 09:35 System.map-5.10.0-21-
amd64
1318577 -rw-r--r-- 1 root root 83 Dec 19 09:14 System.map-6.0.0-
0.deb11.6-amd64
1306754 -rw-r--r-- 1 root root 6.7M Jan 21 09:35 vmlinuz-5.10.0-21-
amd64
1318579 -rw-r--r-- 1 root root 7.4M Dec 19 09:14 vmlinuz-6.0.0-
0.deb11.6-amd64
And this is from the (current) ls -lahFi /tmp:
total 80K
130561 drwxrwxrwt 16 root root 4.0K Apr 18 16:46 ./
2 drwxr-xr-x 19 root root 4.0K Feb 19 11:06 ../
402051 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .font-
unix/
399211 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .ICE-
unix/
402078 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-colord.service-51WIZe/
402064 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-ModemManager.service-fdBA5h/
402060 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-switcheroo-control.service-
el9DGh/
402062 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-systemd-logind.service-sIXjpi/
402055 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-systemd-timesyncd.service-
UtAMlf/
402072 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-upower.service-yLsogf/
402052 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .Test-
unix/
402080 drwx------ 2 [user] [user] 4.0K Apr 18 14:44 tracker-
extract-files.1000/
402071 drwx------ 2 Debian-gdm Debian-gdm 4.0K Apr 18 14:44 tracker-
extract-files.116/
399209 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .X11-
unix/
402049 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .XIM-
unix/
136530 srwxrwxrwx 1 root root 0 Apr 18 14:55 dbus-
3cgiNF1x8f=
136016 srwxrwxrwx 1 root root 0 Apr 18 14:55 dbus-
9nSrGDn5m4=
136531 srwxrwxrwx 1 [user] [user] 0 Apr 18 14:44 dbus-
ZLiotP4WWe=
136532 -r--r--r-- 1 [user] [user] 11 Apr 18 14:44 .X0-lock
136017 -r--r--r-- 1 Debian-gdm Debian-gdm 11 Apr 18 14:44 .X1024-
lock
136018 -r--r--r-- 1 Debian-gdm Debian-gdm 11 Apr 18 14:44 .X1025-
lock
136533 -r--r--r-- 1 [user] [user] 11 Apr 18 14:44 .X1-lock
And . . .
cat /etc/debian_version ; uname -a
11.6
Linux dogen 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-
1~bpo11+1 (2022-12-19) x86_64 GNU/Linux
mount | grep tmp:
udev on /dev type devtmpfs
(rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64)
tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,uid=10
00,gid=1000,inode64)
stat -c %d / /tmp
66306
66306
(I am not sure what that means - is that saying that /tmp is mounted
under / on the / partition?)
(And BTW, the current /etc/fstab must have been written by some
program, not manually by me. I would never have edited /etc/fstab to
look like that!) My best guess is that I may have done a system restore
using Timeshift on 2023-04-03, to back out of some unremembered
problem, and the current /etc/fstab results from that.
I COULD just continue as is with the current setup, but I would REALLY
prefer not to!
Maybe I should just start by using Clonezilla to do a full image of the
drive. Actual data of course, not the entire 256 Gb!
More later . . .
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-04-19 00:00 +0200 |
| Message-ID | <Gm1wJ-2WuP-5@gated-at.bofh.it> |
| In reply to | #257378 |
On Tue, Apr 18, 2023 at 05:42:52PM -0400, Default User wrote: > stat -c %d / /tmp > 66306 > 66306 > (I am not sure what that means - is that saying that /tmp is mounted > under / on the / partition?) Yes. And by the way, "df /tmp" is a much more intuitive way to get that same answer. unicorn:~$ df /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda7 23854928 20508268 2109568 91% / On my system, just like yours, /tmp is simply a plain ol' directory in the root file system.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-19 02:00 +0200 |
| Message-ID | <Gm3oR-2XAt-7@gated-at.bofh.it> |
| In reply to | #257378 |
On 4/18/23 14:42, Default User wrote: > On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote: >> On 4/18/23 07:59, Default User wrote: >>> Hey, I have a strange situation! >>> >>> I just realized that my /tmp partition is not being mounted at >>> startup. >>> Instead, I think the filesystem may be allocating space in another >>> partition (maybe /root?) for tmp stuff. >> My / (root) and /tmp directories are on the same file system -- the >> root >> filesystem: >> >> 2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com >> # stat -c %d / /tmp >> 65024 >> 65024 > stat -c %d / /tmp > 66306 > 66306 > (I am not sure what that means - is that saying that /tmp is mounted > under / on the / partition?) stat(1) is saying that the file system entries "/" and "/tmp" have the same "device number". Device numbers should be unique for the various file systems that are mounted on one computer: # mount | perl -ane '$_=$F[2];$dev=(stat)[0];print"$dev $_\n"' | sort -n /run/user/13250/doc 5 /dev 6 /sys/kernel/security 7 /sys/kernel/debug 11 /sys/kernel/tracing 19 /dev/mqueue 20 /sys 21 /proc 22 /dev/pts 23 /run 26 /dev/shm 27 /run/lock 28 /sys/fs/cgroup 29 /sys/fs/pstore 30 /sys/firmware/efi/efivars 31 /sys/fs/bpf 32 /proc/sys/fs/binfmt_misc 33 /dev/hugepages 34 /sys/fs/fuse/connections 35 /sys/kernel/config 39 /samba/dpchrist 40 /samba/groupshare 42 /run/user/13250 50 /run/user/0 2049 /boot/efi 2050 /boot 65024 / 65026 /scratch That said, I think I prefer the df(1) solution posted by Greg Wooledge. > (And BTW, the current /etc/fstab must have been written by some > program, not manually by me. I would never have edited /etc/fstab to > look like that!) My best guess is that I may have done a system restore > using Timeshift on 2023-04-03, to back out of some unremembered > problem, and the current /etc/fstab results from that. Backing up system configuration files is good. I use a version control system (CVS), create a project for each host, and check in every system configuration file I create, update, or delete. I also keep a log.txt file for each system, write notes to myself, save console sessions, etc., for when I do need to remember what I did, when, and why. Rather than restoring entire system configuration files, I typically use an editor and restore specific settings. > I COULD just continue as is with the current setup, but I would REALLY > prefer not to! Why not? > Maybe I should just start by using Clonezilla to do a full image of the > drive. Actual data of course, not the entire 256 Gb! Putting your data on a different device than your OS allows you to optimize device usage and backup, restore, archive, imaging, etc., procedures. > More later . . . David
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-19 03:20 +0200 |
| Message-ID | <Gm4Eh-2Yu3-1@gated-at.bofh.it> |
| In reply to | #257380 |
On Tue, 2023-04-18 at 16:53 -0700, David Christensen wrote: > On 4/18/23 14:42, Default User wrote: > > On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote: > > > On 4/18/23 07:59, Default User wrote: > > > > Hey, I have a strange situation! > > > > > > > > I just realized that my /tmp partition is not being mounted at > > > > startup. > > > > Instead, I think the filesystem may be allocating space in > > > > another > > > > partition (maybe /root?) for tmp stuff. > > > > My / (root) and /tmp directories are on the same file system -- > > > the > > > root > > > filesystem: > > > > > > 2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com > > > # stat -c %d / /tmp > > > 65024 > > > 65024 > > > stat -c %d / /tmp > > 66306 > > 66306 > > (I am not sure what that means - is that saying that /tmp is > > mounted > > under / on the / partition?) > > > stat(1) is saying that the file system entries "/" and "/tmp" have > the > same "device number". Device numbers should be unique for the > various > file systems that are mounted on one computer: > > # mount | perl -ane '$_=$F[2];$dev=(stat)[0];print"$dev $_\n"' | sort > -n > /run/user/13250/doc > 5 /dev > 6 /sys/kernel/security > 7 /sys/kernel/debug > 11 /sys/kernel/tracing > 19 /dev/mqueue > 20 /sys > 21 /proc > 22 /dev/pts > 23 /run > 26 /dev/shm > 27 /run/lock > 28 /sys/fs/cgroup > 29 /sys/fs/pstore > 30 /sys/firmware/efi/efivars > 31 /sys/fs/bpf > 32 /proc/sys/fs/binfmt_misc > 33 /dev/hugepages > 34 /sys/fs/fuse/connections > 35 /sys/kernel/config > 39 /samba/dpchrist > 40 /samba/groupshare > 42 /run/user/13250 > 50 /run/user/0 > 2049 /boot/efi > 2050 /boot > 65024 / > 65026 /scratch > > > That said, I think I prefer the df(1) solution posted by Greg > Wooledge. > > > > (And BTW, the current /etc/fstab must have been written by some > > program, not manually by me. I would never have edited /etc/fstab > > to > > look like that!) My best guess is that I may have done a system > > restore > > using Timeshift on 2023-04-03, to back out of some unremembered > > problem, and the current /etc/fstab results from that. > > > Backing up system configuration files is good. > > > I use a version control system (CVS), create a project for each host, > and check in every system configuration file I create, update, or > delete. I also keep a log.txt file for each system, write notes to > myself, save console sessions, etc., for when I do need to remember > what > I did, when, and why. Rather than restoring entire system > configuration > files, I typically use an editor and restore specific settings. > > > > I COULD just continue as is with the current setup, but I would > > REALLY > > prefer not to! > > > Why not? > > > > Maybe I should just start by using Clonezilla to do a full image of > > the > > drive. Actual data of course, not the entire 256 Gb! > > > Putting your data on a different device than your OS allows you to > optimize device usage and backup, restore, archive, imaging, etc., > procedures. > > > > More later . . . > > > David > I have made 2 backups of the ssd, using Clonezilla. 1) a full disk backup,from which the whole disk can be restored. 2) a partitions backup, from which any or all of the individual partitions can be restored. Both have been checked by Clonezilla to be restorable. (Not so) fun fact: Clonezilla always refuses to back up swap partitions. I don't know why. FWIW: df /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/nvme0n1p2 23854928 5841496 16776340 26% / Several different approaches to solve the problem have been suggested. I think I will wait until tomorrow and ponder the options, before performing "surgery". Note: It was asked why I don't just use the current setup, with no /tmp partition. I guess it goes back to years ago, when I used OpenBSD for a while. They really pushed the idea of having at least /, /tmp, /var, swap, and /home partitions. I think the idea is that if something happens to one partition, it won't affect the others. Like if a process unexpectedly fills up one partition (/tmp /var, etc.) it probably won't send the whole system crashing down. Finally, after the current situation is resolved, I would still like to know what caused the problem in the first place. I would really like to not have it happen again!
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2023-04-19 04:50 +0200 |
| Message-ID | <Gm63o-2Zhg-7@gated-at.bofh.it> |
| In reply to | #257381 |
On Tue, 18 Apr 2023 21:12:33 -0400 Default User <hunguponcontent@gmail.com> wrote: > (Not so) fun fact: Clonezilla always refuses to back up swap > partitions. I don't know why. Because there is no reason to do so. It has nothing in it of any value, except possibly to a cracker, and even that is stale. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-19 05:00 +0200 |
| Message-ID | <Gm6d3-2ZkE-1@gated-at.bofh.it> |
| In reply to | #257381 |
On 4/18/23 18:12, Default User wrote: >>>> On 4/18/23 07:59, Default User wrote: >>>>> I just realized that my /tmp partition is not being mounted at >>>>> startup. > Finally, after the current situation is resolved, I would still like to > know what caused the problem in the first place. Looking back at previous posts: On 4/18/23 07:59, Default User wrote: > Current /etc/fstab: > # <file system> <mount point> <type> <options> <dump> <pass> > > UUID=4fdd4399-6267-404a-a292- > cdc7761df3c9 / ext4 errors=remount-ro 0 1 > UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1 > UUID=00f0c2db-0490-4354-b949- > f9af11a7f001 /home ext4 defaults 0 2 > UUID=8bfeee23-9c09-45b7-a73e- > bd2ff43e207c /var ext4 defaults 0 2 > UUID=e2a56ec3-99d4-4b40-9aa4- > 24975143cdc7 none swap sw 0 0 > Original /etc/fstab: > # /tmp was on /dev/nvme0n1p5 during installation > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 > defaults 0 2 It appears that the fstab(5) entry for /etc was dropped when: On 4/18/23 14:42, Default User wrote: > My best guess is that I may have done a system restore > using Timeshift on 2023-04-03, to back out of some unremembered > problem, and the current /etc/fstab results from that. I would try adding the fstab(5) entry for /tmp from the original /etc/fstab to the current /etc/fstab, and then rebooting. (If this works, the contents of the /tmp directory of the root file system will be overlaid by the /tmp file system. To reclaim space on the root file system, I would boot the system using a live drive or the d-i rescue shell, mount the root file system at /mnt, and then remove the contents of /mnt/tmp. Note that you do not want to remove the /mnt/tmp directory, because it is the mount point for the /tmp file system.) David
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-04-19 05:10 +0200 |
| Message-ID | <Gm6mJ-2ZCV-1@gated-at.bofh.it> |
| In reply to | #257381 |
On Tue 18 Apr 2023 at 21:12:33 (-0400), Default User wrote: > > (Not so) fun fact: Clonezilla always refuses to back up swap > partitions. I don't know why. It's not clear to me how you could restore the entire rest of the system to the state it was in when you made your backup of swap. So the backup copy becomes instantly useless except for forensics or theft, ie scanning for fragments of text, passwords etc. That's why I encrypt my swap partitions with a random key. > Several different approaches to solve the problem have been suggested. > I think I will wait until tomorrow and ponder the options, before > performing "surgery". If you're prepared to reboot, it should be straightforward, but there is one factor I haven't seen mentioned, and that's to do with cleaning. If you add the "lost line" back into fstab: UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 then when the system starts up, partition 5 will be mounted onto /tmp in the root filesystem, and then it'll be cleaned of any files left over from the last time it was used. It might be a long, long time since you used it so there could conceivably be files that you want to check out. So, I would mount partition 5 on /mnt and look it over. Yes, you've backed up the partition, but you might never look at that, whereas this is something you can do straightaway. That aspect was already mentioned by DbB. But there is one further point to make. AIUI, cleaning will be carried out on /tmp after the partition (5) has been mounted. It wouldn't make sense otherwise. But look at your usage of /tmp now—that is, the /tmp in the root partition. If it contains some large files when you shut down in preparation to change fstab, then those files, sitting on /, will never get cleaned. They'll be hidden by mounting partition 5 on top of them, and use disk space for ever. So—I would clean /tmp as best you can before you close down, then boot in single user mode, clean anything still remaining in /tmp, edit your fstab, and then reboot. > Finally, after the current situation is resolved, I would still like to > know what caused the problem in the first place. I would really like to > not have it happen again! It looks as if someone edited the entries with tabs to make it line up neatly, removed the installers comments, and accidentally removed the /tmp line too. I don't know of any software that would do that to fstab. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2023-04-19 05:20 +0200 |
| Message-ID | <Gm6wp-2ZG2-1@gated-at.bofh.it> |
| In reply to | #257384 |
> So—I would clean /tmp as best you can before you close down, then
> boot in single user mode, clean anything still remaining in /tmp,
> edit your fstab, and then reboot.
You can also do
mount --bind / /mnt
and then look at /mnt/tmp.
No need to reboot into single-user mode for that.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-19 11:20 +0200 |
| Message-ID | <Gmc8N-334y-1@gated-at.bofh.it> |
| In reply to | #257386 |
On 4/18/23 20:16, Stefan Monnier wrote: > You can also do > > mount --bind / /mnt > > and then look at /mnt/tmp. > No need to reboot into single-user mode for that. +1 I like that better than the reboot/ live drive idea I posted. David
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-19 13:10 +0200 |
| Message-ID | <GmdRf-347G-3@gated-at.bofh.it> |
| In reply to | #257392 |
On 19/04/2023 16:16, David Christensen wrote: > On 4/18/23 20:16, Stefan Monnier wrote: > >> You can also do >> >> mount --bind / /mnt >> >> and then look at /mnt/tmp. >> No need to reboot into single-user mode for that. > > +1 I like that better than the reboot/ live drive idea I posted. I think, it is the case when reboot is safer. Open file descriptors remain on the original partition. However I do not expect that single user mode or booting from live image is required. Just restore original /etc/fstab and reboot. Perhaps update-initramfs is necessary after restoring of /etc/fstab in any chosen approach.
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-19 22:10 +0200 |
| Message-ID | <GmmhP-394m-17@gated-at.bofh.it> |
| In reply to | #257395 |
On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: > On 19/04/2023 16:16, David Christensen wrote: > > On 4/18/23 20:16, Stefan Monnier wrote: > > > > > You can also do > > > > > > mount --bind / /mnt > > > > > > and then look at /mnt/tmp. > > > No need to reboot into single-user mode for that. > > > > +1 I like that better than the reboot/ live drive idea I posted. > > I think, it is the case when reboot is safer. Open file descriptors > remain on the original partition. However I do not expect that single > user mode or booting from live image is required. Just restore > original > /etc/fstab and reboot. > > Perhaps update-initramfs is necessary after restoring of /etc/fstab > in > any chosen approach. > > Well, now I am totally confused. I had hoped for, and really expected, an easy, obvious, intuitive solution. But I guess that may be a distant memory of the good old days, before [insert string of four-letter words here] like dbus, systemd, and Gnome 3. And when partitions were named /dev/hda5, not 6a105a72-f5d5-441b-b926-1e405151ee84. Sigh. Anyway, here is where I am at: I have two Clonezilla backups. 1) a full disk backup. 2) a "partitions" backup. So, if things really go bad, I can theoretically revert to the setup as of 2023-04-18, when this thread was started. I also have a backup of the current /tmp directory (from under the / directory). And I have a backup of the old tmp partition. Both of these tmp backups were made using a Debian Stable 11.6 Live/install usb thumb drive, as root user. All of these backups are on an external usb hdd. Here is what was in the (root) tmp directory: _root_partition/tmp total 32K 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker-extract- files.116/ 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ And here is what was in the old tmp partition: total 48K 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font-unix/ 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE-unix/ 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 lost+found/ 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test-unix/ 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- extract-files.1000/ 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- extract-files.116/ 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024-lock 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025-lock 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11-unix/ 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM-unix/ As far as I can tell, there is nothing crucial in either tmp backup. BTW, I know nothing about bind or mount --bind. I looked them up briefly, and decided that they are too difficult and maybe dangerous to try to learn and use under the current circumstances. So here is what I am thinking of doing: While running from within the Debian Stable 11.6 Live/install usb thumb drive, as root user: 1) On the computer's internal ssd, delete the /tmp directory and its contents. 2) On the computer's internal ssd, delete the contents of the old tmp partition, but not the partition itself. 3) On the computer's internal ssd, replace /etc/fstab with /etc/fstab.original, renaming it /etc/fstab. I have already made a copy of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. The UUIDs of all partitions on computer's internal ssd seem to be the same as in /etc/fstab.original. (Note: in /etc/fstab.original, it states "Please run 'systemctl daemon- reload' after making changes here." Since I am doing all this from a live usb, I do not think that applies, so I would skip that.) Then I would shut down, remove the usb thumb drive, and boot into the Debian system on the computer's internal ssd. I hope that from then on, the system would mount the old tmp partition on the computer's internal ssd as /tmp, re-populating it automatically, and use it as such from then on. Does that seem reasonable? Or am I missing something, obvious or not.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-04-19 22:40 +0200 |
| Message-ID | <GmmKR-39dH-5@gated-at.bofh.it> |
| In reply to | #257400 |
On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > Anyway, here is where I am at: > > I have two Clonezilla backups. > 1) a full disk backup. > 2) a "partitions" backup. > So, if things really go bad, I can theoretically revert to the setup as > of 2023-04-18, when this thread was started. > > I also have a backup of the current /tmp directory (from under the / > directory). > And I have a backup of the old tmp partition. > > Both of these tmp backups were made using a Debian Stable 11.6 > Live/install usb thumb drive, as root user. > > All of these backups are on an external usb hdd. > > Here is what was in the (root) tmp directory: > > _root_partition/tmp > total 32K > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ > 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker-extract- > files.116/ > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ > > And here is what was in the old tmp partition: > > total 48K > 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font-unix/ > 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE-unix/ > 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 lost+found/ > 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test-unix/ > 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > extract-files.1000/ > 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > extract-files.116/ > 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024-lock > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025-lock > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11-unix/ > 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM-unix/ > > As far as I can tell, there is nothing crucial in either tmp backup. > > BTW, I know nothing about bind or mount --bind. I looked them up > briefly, and decided that they are too difficult and maybe dangerous to > try to learn and use under the current circumstances. > > So here is what I am thinking of doing: > > While running from within the Debian Stable 11.6 Live/install usb thumb > drive, as root user: > > 1) On the computer's internal ssd, delete the /tmp directory and its > contents. > > 2) On the computer's internal ssd, delete the contents of the old tmp > partition, but not the partition itself. > > 3) On the computer's internal ssd, replace /etc/fstab with > /etc/fstab.original, renaming it /etc/fstab. I have already made a copy > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. > > The UUIDs of all partitions on computer's internal ssd seem to be the > same as in /etc/fstab.original. > > (Note: in /etc/fstab.original, it states "Please run 'systemctl daemon- > reload' after making changes here." Since I am doing all this from a > live usb, I do not think that applies, so I would skip that.) > > Then I would shut down, remove the usb thumb drive, and boot into the > Debian system on the computer's internal ssd. > > I hope that from then on, the system would mount the old tmp partition > on the computer's internal ssd as /tmp, re-populating it automatically, > and use it as such from then on. > > Does that seem reasonable? > > Or am I missing something, obvious or not. I see nothing unreasonable. The only oddity to me is that the listings you give (which are from the backups, I assume) have today's date, which means that the backup method is not preserving the file metadata. (If you've not used partition 5 for a while, the dates should be old.) It doesn't affect what you're doing now, as all the originals are heading into oblivion, but I'd be reading the backup spec sometime to see if I could improve that. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-19 23:00 +0200 |
| Message-ID | <Gmn4d-39kc-7@gated-at.bofh.it> |
| In reply to | #257403 |
On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: > On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > > > Anyway, here is where I am at: > > > > I have two Clonezilla backups. > > 1) a full disk backup. > > 2) a "partitions" backup. > > So, if things really go bad, I can theoretically revert to the > > setup as > > of 2023-04-18, when this thread was started. > > > > I also have a backup of the current /tmp directory (from under the > > / > > directory). > > And I have a backup of the old tmp partition. > > > > Both of these tmp backups were made using a Debian Stable 11.6 > > Live/install usb thumb drive, as root user. > > > > All of these backups are on an external usb hdd. > > > > Here is what was in the (root) tmp directory: > > > > _root_partition/tmp > > total 32K > > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ > > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ > > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ > > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ > > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ > > 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker- > > extract- > > files.116/ > > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ > > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ > > > > And here is what was in the old tmp partition: > > > > total 48K > > 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ > > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > > 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font- > > unix/ > > 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE-unix/ > > 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 > > lost+found/ > > 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test- > > unix/ > > 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > extract-files.1000/ > > 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > extract-files.116/ > > 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024- > > lock > > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025- > > lock > > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11-unix/ > > 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM-unix/ > > > > As far as I can tell, there is nothing crucial in either tmp > > backup. > > > > BTW, I know nothing about bind or mount --bind. I looked them up > > briefly, and decided that they are too difficult and maybe > > dangerous to > > try to learn and use under the current circumstances. > > > > So here is what I am thinking of doing: > > > > While running from within the Debian Stable 11.6 Live/install usb > > thumb > > drive, as root user: > > > > 1) On the computer's internal ssd, delete the /tmp directory and > > its > > contents. > > > > 2) On the computer's internal ssd, delete the contents of the old > > tmp > > partition, but not the partition itself. > > > > 3) On the computer's internal ssd, replace /etc/fstab with > > /etc/fstab.original, renaming it /etc/fstab. I have already made a > > copy > > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. > > > > The UUIDs of all partitions on computer's internal ssd seem to be > > the > > same as in /etc/fstab.original. > > > > (Note: in /etc/fstab.original, it states "Please run 'systemctl > > daemon- > > reload' after making changes here." Since I am doing all this from > > a > > live usb, I do not think that applies, so I would skip that.) > > > > Then I would shut down, remove the usb thumb drive, and boot into > > the > > Debian system on the computer's internal ssd. > > > > I hope that from then on, the system would mount the old tmp > > partition > > on the computer's internal ssd as /tmp, re-populating it > > automatically, > > and use it as such from then on. > > > > Does that seem reasonable? > > > > Or am I missing something, obvious or not. > > I see nothing unreasonable. The only oddity to me is that the > listings > you give (which are from the backups, I assume) have today's date, > which means that the backup method is not preserving the file > metadata. > (If you've not used partition 5 for a while, the dates should be > old.) > It doesn't affect what you're doing now, as all the originals are > heading into oblivion, but I'd be reading the backup spec sometime > to see if I could improve that. > > Cheers, > David. > IIRC, I just did: sudo <source> <destination> from the live usb. I didn't think about the changed times. Perhaps I should have used rsync . . . Grrr . . .
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-19 23:10 +0200 |
| Message-ID | <GmndT-39D9-27@gated-at.bofh.it> |
| In reply to | #257407 |
On Wed, 2023-04-19 at 16:56 -0400, Default User wrote: > On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: > > On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > > > > > Anyway, here is where I am at: > > > > > > I have two Clonezilla backups. > > > 1) a full disk backup. > > > 2) a "partitions" backup. > > > So, if things really go bad, I can theoretically revert to the > > > setup as > > > of 2023-04-18, when this thread was started. > > > > > > I also have a backup of the current /tmp directory (from under > > > the > > > / > > > directory). > > > And I have a backup of the old tmp partition. > > > > > > Both of these tmp backups were made using a Debian Stable 11.6 > > > Live/install usb thumb drive, as root user. > > > > > > All of these backups are on an external usb hdd. > > > > > > Here is what was in the (root) tmp directory: > > > > > > _root_partition/tmp > > > total 32K > > > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ > > > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ > > > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ > > > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ > > > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ > > > 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker- > > > extract- > > > files.116/ > > > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ > > > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ > > > > > > And here is what was in the old tmp partition: > > > > > > total 48K > > > 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ > > > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > > > 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font- > > > unix/ > > > 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE- > > > unix/ > > > 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 > > > lost+found/ > > > 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test- > > > unix/ > > > 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > > extract-files.1000/ > > > 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > > extract-files.116/ > > > 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024- > > > lock > > > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025- > > > lock > > > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11- > > > unix/ > > > 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM- > > > unix/ > > > > > > As far as I can tell, there is nothing crucial in either tmp > > > backup. > > > > > > BTW, I know nothing about bind or mount --bind. I looked them up > > > briefly, and decided that they are too difficult and maybe > > > dangerous to > > > try to learn and use under the current circumstances. > > > > > > So here is what I am thinking of doing: > > > > > > While running from within the Debian Stable 11.6 Live/install usb > > > thumb > > > drive, as root user: > > > > > > 1) On the computer's internal ssd, delete the /tmp directory and > > > its > > > contents. > > > > > > 2) On the computer's internal ssd, delete the contents of the old > > > tmp > > > partition, but not the partition itself. > > > > > > 3) On the computer's internal ssd, replace /etc/fstab with > > > /etc/fstab.original, renaming it /etc/fstab. I have already made > > > a > > > copy > > > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. > > > > > > The UUIDs of all partitions on computer's internal ssd seem to be > > > the > > > same as in /etc/fstab.original. > > > > > > (Note: in /etc/fstab.original, it states "Please run 'systemctl > > > daemon- > > > reload' after making changes here." Since I am doing all this > > > from > > > a > > > live usb, I do not think that applies, so I would skip that.) > > > > > > Then I would shut down, remove the usb thumb drive, and boot into > > > the > > > Debian system on the computer's internal ssd. > > > > > > I hope that from then on, the system would mount the old tmp > > > partition > > > on the computer's internal ssd as /tmp, re-populating it > > > automatically, > > > and use it as such from then on. > > > > > > Does that seem reasonable? > > > > > > Or am I missing something, obvious or not. > > > > I see nothing unreasonable. The only oddity to me is that the > > listings > > you give (which are from the backups, I assume) have today's date, > > which means that the backup method is not preserving the file > > metadata. > > (If you've not used partition 5 for a while, the dates should be > > old.) > > It doesn't affect what you're doing now, as all the originals are > > heading into oblivion, but I'd be reading the backup spec sometime > > to see if I could improve that. > > > > Cheers, > > David. > > > > > IIRC, I just did: > > sudo <source> <destination> from the live usb. > > I didn't think about the changed times. > > Perhaps I should have used rsync . . . > > Grrr . . . > > > Sorry! That should have been: sudo cp -r <source> <destination> from the live usb. "The Times regrets the error." :)
[toc] | [prev] | [next] | [standalone]
| From | davidson <davidson@freevolt.org> |
|---|---|
| Date | 2023-04-20 01:50 +0200 |
| Message-ID | <GmpIJ-3b0O-1@gated-at.bofh.it> |
| In reply to | #257409 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, 19 Apr 2023 Default User wrote: > On Wed, 2023-04-19 at 16:56 -0400, Default User wrote: >> On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: >>> On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: >>> >>>> Anyway, here is where I am at: >>>> >>>> I have two Clonezilla backups. >>>> 1) a full disk backup. >>>> 2) a "partitions" backup. >>>> So, if things really go bad, I can theoretically revert to the >>>> setup as >>>> of 2023-04-18, when this thread was started. >>>> >>>> I also have a backup of the current /tmp directory (from under >>>> the >>>> / >>>> directory). >>>> And I have a backup of the old tmp partition. >>>> >>>> Both of these tmp backups were made using a Debian Stable 11.6 >>>> Live/install usb thumb drive, as root user. >>>> >>>> All of these backups are on an external usb hdd. >>>> >>>> Here is what was in the (root) tmp directory: >>>> >>>> _root_partition/tmp >>>> total 32K >>>> 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ >>>> 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ >>>> 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ >>>> 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ >>>> 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ >>>> 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker- >>>> extract- >>>> files.116/ >>>> 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ >>>> 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ >>>> >>>> And here is what was in the old tmp partition: >>>> >>>> total 48K >>>> 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ >>>> 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ >>>> 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font- >>>> unix/ >>>> 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE- >>>> unix/ >>>> 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 >>>> lost+found/ >>>> 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test- >>>> unix/ >>>> 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- >>>> extract-files.1000/ >>>> 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- >>>> extract-files.116/ >>>> 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024- >>>> lock >>>> 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025- >>>> lock >>>> 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11- >>>> unix/ >>>> 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM- >>>> unix/ >>>> >>>> As far as I can tell, there is nothing crucial in either tmp >>>> backup. >>>> >>>> BTW, I know nothing about bind or mount --bind. I looked them up >>>> briefly, and decided that they are too difficult and maybe >>>> dangerous to >>>> try to learn and use under the current circumstances. >>>> >>>> So here is what I am thinking of doing: >>>> >>>> While running from within the Debian Stable 11.6 Live/install usb >>>> thumb >>>> drive, as root user: >>>> >>>> 1) On the computer's internal ssd, delete the /tmp directory and >>>> its >>>> contents. >>>> >>>> 2) On the computer's internal ssd, delete the contents of the old >>>> tmp >>>> partition, but not the partition itself. >>>> >>>> 3) On the computer's internal ssd, replace /etc/fstab with >>>> /etc/fstab.original, renaming it /etc/fstab. I have already made >>>> a >>>> copy >>>> of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. >>>> >>>> The UUIDs of all partitions on computer's internal ssd seem to be >>>> the >>>> same as in /etc/fstab.original. >>>> >>>> (Note: in /etc/fstab.original, it states "Please run 'systemctl >>>> daemon- >>>> reload' after making changes here." Since I am doing all this >>>> from >>>> a >>>> live usb, I do not think that applies, so I would skip that.) >>>> >>>> Then I would shut down, remove the usb thumb drive, and boot into >>>> the >>>> Debian system on the computer's internal ssd. >>>> >>>> I hope that from then on, the system would mount the old tmp >>>> partition >>>> on the computer's internal ssd as /tmp, re-populating it >>>> automatically, >>>> and use it as such from then on. >>>> >>>> Does that seem reasonable? >>>> >>>> Or am I missing something, obvious or not. >>> >>> I see nothing unreasonable. The only oddity to me is that the >>> listings >>> you give (which are from the backups, I assume) have today's date, >>> which means that the backup method is not preserving the file >>> metadata. >>> (If you've not used partition 5 for a while, the dates should be >>> old.) >>> It doesn't affect what you're doing now, as all the originals are >>> heading into oblivion, but I'd be reading the backup spec sometime >>> to see if I could improve that. >>> >>> Cheers, >>> David. >>> >> >> >> IIRC, I just did: >> >> sudo <source> <destination> from the live usb. >> >> I didn't think about the changed times. >> >> Perhaps I should have used rsync . . . >> >> Grrr . . . >> >> >> > > > Sorry! That should have been: > > sudo cp -r <source> <destination> from the live usb. Consider the -a option to cp for backup/backdown operations, to preserve all attributes (including timestamps), recursively copy directories, and more. Read the manual for details. -- Hackers are free people. They are like artists. If they are in a good mood, they get up in the morning and begin painting their pictures. -- Vladimir Putin
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-20 03:50 +0200 |
| Message-ID | <GmrAR-3c6M-1@gated-at.bofh.it> |
| In reply to | #257413 |
On Wed, 2023-04-19 at 23:40 +0000, davidson wrote: > On Wed, 19 Apr 2023 Default User wrote: > > On Wed, 2023-04-19 at 16:56 -0400, Default User wrote: > > > On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: > > > > On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > > > > > > > > > Anyway, here is where I am at: > > > > > > > > > > I have two Clonezilla backups. > > > > > 1) a full disk backup. > > > > > 2) a "partitions" backup. > > > > > So, if things really go bad, I can theoretically revert to > > > > > the > > > > > setup as > > > > > of 2023-04-18, when this thread was started. > > > > > > > > > > I also have a backup of the current /tmp directory (from > > > > > under > > > > > the > > > > > / > > > > > directory). > > > > > And I have a backup of the old tmp partition. > > > > > > > > > > Both of these tmp backups were made using a Debian Stable > > > > > 11.6 > > > > > Live/install usb thumb drive, as root user. > > > > > > > > > > All of these backups are on an external usb hdd. > > > > > > > > > > Here is what was in the (root) tmp directory: > > > > > > > > > > _root_partition/tmp > > > > > total 32K > > > > > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ > > > > > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ > > > > > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font- > > > > > unix/ > > > > > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE- > > > > > unix/ > > > > > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test- > > > > > unix/ > > > > > 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 > > > > > tracker- > > > > > extract- > > > > > files.116/ > > > > > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11- > > > > > unix/ > > > > > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM- > > > > > unix/ > > > > > > > > > > And here is what was in the old tmp partition: > > > > > > > > > > total 48K > > > > > 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ > > > > > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > > > > > 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 > > > > > .font- > > > > > unix/ > > > > > 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 > > > > > .ICE- > > > > > unix/ > > > > > 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 > > > > > lost+found/ > > > > > 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 > > > > > .Test- > > > > > unix/ > > > > > 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 > > > > > tracker- > > > > > extract-files.1000/ > > > > > 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 > > > > > tracker- > > > > > extract-files.116/ > > > > > 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 > > > > > .X1024- > > > > > lock > > > > > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 > > > > > .X1025- > > > > > lock > > > > > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 > > > > > .X11- > > > > > unix/ > > > > > 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 > > > > > .XIM- > > > > > unix/ > > > > > > > > > > As far as I can tell, there is nothing crucial in either tmp > > > > > backup. > > > > > > > > > > BTW, I know nothing about bind or mount --bind. I looked them > > > > > up > > > > > briefly, and decided that they are too difficult and maybe > > > > > dangerous to > > > > > try to learn and use under the current circumstances. > > > > > > > > > > So here is what I am thinking of doing: > > > > > > > > > > While running from within the Debian Stable 11.6 Live/install > > > > > usb > > > > > thumb > > > > > drive, as root user: > > > > > > > > > > 1) On the computer's internal ssd, delete the /tmp directory > > > > > and > > > > > its > > > > > contents. > > > > > > > > > > 2) On the computer's internal ssd, delete the contents of the > > > > > old > > > > > tmp > > > > > partition, but not the partition itself. > > > > > > > > > > 3) On the computer's internal ssd, replace /etc/fstab with > > > > > /etc/fstab.original, renaming it /etc/fstab. I have already > > > > > made > > > > > a > > > > > copy > > > > > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. > > > > > > > > > > The UUIDs of all partitions on computer's internal ssd seem > > > > > to be > > > > > the > > > > > same as in /etc/fstab.original. > > > > > > > > > > (Note: in /etc/fstab.original, it states "Please run > > > > > 'systemctl > > > > > daemon- > > > > > reload' after making changes here." Since I am doing all this > > > > > from > > > > > a > > > > > live usb, I do not think that applies, so I would skip that.) > > > > > > > > > > Then I would shut down, remove the usb thumb drive, and boot > > > > > into > > > > > the > > > > > Debian system on the computer's internal ssd. > > > > > > > > > > I hope that from then on, the system would mount the old tmp > > > > > partition > > > > > on the computer's internal ssd as /tmp, re-populating it > > > > > automatically, > > > > > and use it as such from then on. > > > > > > > > > > Does that seem reasonable? > > > > > > > > > > Or am I missing something, obvious or not. > > > > > > > > I see nothing unreasonable. The only oddity to me is that the > > > > listings > > > > you give (which are from the backups, I assume) have today's > > > > date, > > > > which means that the backup method is not preserving the file > > > > metadata. > > > > (If you've not used partition 5 for a while, the dates should > > > > be > > > > old.) > > > > It doesn't affect what you're doing now, as all the originals > > > > are > > > > heading into oblivion, but I'd be reading the backup spec > > > > sometime > > > > to see if I could improve that. > > > > > > > > Cheers, > > > > David. > > > > > > > > > > > > > IIRC, I just did: > > > > > > sudo <source> <destination> from the live usb. > > > > > > I didn't think about the changed times. > > > > > > Perhaps I should have used rsync . . . > > > > > > Grrr . . . > > > > > > > > > > > > > > > Sorry! That should have been: > > > > sudo cp -r <source> <destination> from the live usb. > > Consider the -a option to cp for backup/backdown operations, to > preserve all attributes (including timestamps), recursively copy > directories, and more. Read the manual for details. > Actually, I did it again, using: sudo rsync -avv I don't use cp very often, so I didn't recall the -a option. Thanks for the info. Don't know why I didn't use rsync before . . .
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web